LOGS · REDACT BEFORE EMISSION
Agent logs: redact sensitive fields before emission
Five structured agent log records carry an e-mail, a bearer token, a card number in free text and a nested phone number; choose where and how they are redacted.
Your experiment
The agent logs a tool call with the user’s e-mail, an HTTP record with an authorization header, a prompt that contains a card number, a tool result with a nested phone number and a latency record. Start with a top-level denylist applied in the collector, then switch to an allowlist, scrub free text and move redaction into the process.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Teaching model with five fictional records. The denylist matches top-level field names only, as many simple filters do; the scrubber uses two patterns (16-digit card numbers and e-mail addresses), which would miss other formats. A value counts as having left the process when it is present in the record handed to the log pipeline.
A denylist in the collector
The agent writes five structured records: L1 a tool call with the user’s e-mail, L2 an HTTP record whose authorization header holds a bearer token, L3 a prompt that contains a card number, L4 a tool result with a phone number nested under customer.contact, and L5 a latency record. The opening policy removes named top-level fields in the log collector. It removes the e-mail from L1, but the header, the card number and the nested phone are stored: SENSITIVE DATA STORED, 3 stored, and all 4 sensitive values left the process before anything was removed.
Emit only what you need
Set Field policy to Emit only allowlisted fields and run redaction in the agent process. Headers and the nested customer object are never emitted because they are not on the list. One value still reaches the store: the card number inside the prompt text, because text is allowlisted for debugging. A denylist has to anticipate every sensitive field name and nesting; an allowlist only has to name the useful ones.
Free text needs its own treatment
Choose Mask card numbers and e-mail addresses: the prompt is kept with [card] in place of the number and nothing sensitive is stored or leaves the process: REDACTED BEFORE EMISSION, with all 12 useful fields kept. Drop it is also safe but loses the prompt, 11 of 12 fields. With the denylist, scrubbing removes the card number but still stores the header and the phone: 2 stored.
Where redaction runs
Choose In the log collector with the allowlist and scrubbing: the store ends up clean, but the raw records with all four sensitive values were handed to the log pipeline first, where buffers, agents and network hops can keep or expose them: REDACTED TOO LATE. Redaction belongs before emission, in the process that knows which fields are sensitive.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through each record as stored and the review across sixty seconds; the table records which sensitive field each record carries, whether it left the process, whether it was stored and how many useful fields survived. The scrubber knows two patterns only; real redaction needs tested detectors, field-level schemas and a policy for traces and metrics as well as logs.