Redact sensitive fields before sending context to a model

A support ticket can contain identifiers that a drafting model does not need. Before constructing model context, define the fields required for the task and build a new outbound object containing only those fields.

For a synthetic task that categorizes a ticket, the application may need a short issue description and product category. It may not need the customer's full account record, postal address or internal payment notes. Treat that decision as a product and data-handling requirement, not a cleanup step after the prompt is assembled.

A simple allowlist illustrates the boundary:

def outbound_ticket(ticket):
    return {
        "category": ticket["category"],
        "issue_summary": ticket["issue_summary"],
    }

sample = {
    "category": "export",
    "issue_summary": "Download expires before review.",
    "email": "person@example.test",
}
assert "email" not in outbound_ticket(sample)

The fixture uses invented data. The summary must itself follow a policy that excludes identifiers, since allowlisting a free-text field does not make its contents safe.

Allowlisting reduces outbound fields; free-text summaries still require a separate privacy check.

Inspect the serialized request

Validate the outbound object against a dedicated model and serialize that model deliberately. Pydantic's model documentation explains structured validation. Validation provides a shape check; the application still decides which information may leave the service.

Capture the exact outbound request in a local stub and review every field. Inspect attachments, quoted email threads and metadata added by middleware. A redacted visible prompt can coexist with an unredacted attachment or tracing payload.

Use realistic synthetic fixtures that place identifiers in unexpected locations. An email address may appear in a subject line, and a phone number can be written with spaces or words. A regular expression that catches one formatting convention cannot guarantee complete redaction.

Keep the redaction map local

If a workflow needs to restore a name later, replace it with a scoped placeholder and store the mapping inside the trusted application. A globally reused placeholder can create unintended connections across unrelated requests. Give mappings an explicit lifetime and access policy.

Redact before logging as well as before sending. Debug output, exception traces and replay fixtures can otherwise become an additional copy of the original ticket. Avoid recording raw failed payloads in public diagnostics.

Test missing required fields and malformed input before constructing context. If safe extraction fails, ask the user to provide a sanitized summary or use a manual workflow instead of forwarding the entire record.

This example demonstrates field minimization on a synthetic dictionary. It does not certify anonymization, infer a legal basis for processing, or establish a provider's retention behavior. Those questions require separate policy and integration review.