Every serious guide to running AI agents tells you to log everything: every tool call, approval, and block. That advice is correct — and incomplete. A log capturing full prompts, payloads, and outputs is also a second copy of the most sensitive data your agent touches — API keys, credentials, customer records — sitting in a system built for debugging, not for guarding secrets. This AI agent log redaction checklist resolves the tension: log claims and references, not raw content. Prove what happened, who allowed it, and what it cost — without writing the secret down.
The stakes are not hypothetical. Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by 2026, up from under 5% in 2025, so log volume grows with every agent deployed. And a documented runaway agent loop burned over $700 in API costs — the kind of incident you can only reconstruct if the trail exists. You need the trail. You just need it redacted by design.
The problem: your log is a second copy of everything sensitive¶
Application data gets the security attention: encryption, access control, retention limits. Logs inherit almost none of it by default. They are copied to aggregators, shipped to third-party observability tools, included in backups, and pasted into bug reports — a secret in a prompt can end up in five systems within a week.
That is why redaction is a write-time decision, not a cleanup job. Scrubbing after the fact means the raw secret already crossed every boundary the pipeline touches, and you are trusting every copy, cache, and backup got the memo. Redact before the record is written and there is only ever one version of the truth: the safe one.
What must never be written raw¶
Some values have no safe raw form in a log, whatever the debugging convenience:
- Credentials and secrets: passwords, API keys, access and refresh tokens, session cookies, private keys, and recovery codes.
- Payment data: full card numbers and bank details — anything that would let a log reader spend or move money.
- Personal identifiers the record does not need: full email addresses, phone numbers, and government IDs, when an internal ID identifies the record just as well.
- Authorization headers and signed URLs: they are credentials with better branding, and they leak the same way.
- Other people's private content in full: a message routed through your agent does not become safe to store just because the agent read it.
If a value would trigger a rotation or an incident report when exposed, it belongs on this list. When in doubt, treat it as never-log: a missing debug detail costs an afternoon; a leaked key costs a weekend.
What to log instead: claims, hashes, and references¶
Redaction does not mean logging less about the action — it means logging differently about the content. For almost every sensitive field, one of these substitutes preserves what an investigator needs:
- A hash of the value. A hash proves a specific payload was sent and has not changed since. Two records with the same hash carried the same content, without either revealing it.
- A pointer, not the payload. Record where the content lives in the system built to guard it — a record ID or object reference — and let authorised reviewers fetch it there.
- A data-class label. The record states what kind of data moved (“customer PII”, “payment reference”, “internal document”) without moving any of it into the log.
- A masked form, sparingly. The last few characters of an identifier can help support confirm the right account. Mask by default; show a fragment only when a named workflow needs it.
- Shape, not substance. Field names without values, counts, lengths, and types tell a debugger a lot: the payload had the expected fields, one field was empty, the output was ten times the usual size.
Hash-linked rows make this auditable rather than merely tidy. Each record carries its payload's hash and, in a hash-chained log, the previous record's hash — so a reviewer can verify the trail is complete and unedited while payloads stay in their guarded store, or nowhere at all.
The AI agent log redaction checklist, field by field¶
Assign every field of your audit record one treatment — keep, mask, hash, reference, or drop:
- Timestamp (keep): UTC, from a clock the agent does not control.
- Agent identity (keep): the stable, named identity from your registry, plus its version or configuration.
- Acting for (keep, as an ID): whose task the agent was executing — an internal ID, not a pasted email thread.
- Action and target (keep): what was attempted and the specific record or resource it touched, by reference.
- Decision (keep): allowed, blocked, or approved, with the policy rule or approval record behind it. Blocks are first-class entries, never silently skipped.
- Payload (hash + reference, never raw): the hash of what was sent, and a pointer to the guarded original if one legitimately exists.
- Data class (keep): the class declared in the plan bound, so the redaction rule applied is visible in the record.
- Outcome (keep): succeeded, failed, or partially applied, with the error class — summarised, not pasted with its embedded payload.
- Cost (keep): spend counted against the plan's cost ceiling, so anomalies show in the same trail.
Redaction rules follow the data class in the plan bound¶
Do not invent redaction rules inside the logger, field by field. Derive them from the plan bound — the approved record of what this run was allowed to do, which already declares the work's data class alongside scope, egress, storage, and cost ceiling. The logger's job is enforcement: for each declared class, a standing rule says what may be written.
- Credentials and secrets, any class: never written; the record notes a credential was used, by grant reference, and nothing more.
- Personal data: identifiers masked or replaced with internal IDs; content hashed or referenced, never quoted.
- Internal operational data: summarised in structured fields; free text dropped unless a named review workflow needs it.
- Public data: may be logged in full — the one class where full fidelity is safe, which is why the class must be declared, not assumed.
One rule covers the gaps: if the data class is missing or unclear, the strictest treatment applies. Fail closed on ambiguity, the same way a blocked action should produce a recorded block rather than a quiet pass.
Free text is where redaction goes to die¶
Structured fields are the easy half. The leaks live in free text: the prompt that quotes an account number, the tool output that echoes a database row, the error message that includes the request body, the model's summary that repeats the secret it was just handed. A blocklist of key formats catches the tidy leaks and misses all of these.
Treat free text as untrusted content at the logging boundary. Extract the structured facts you need — action, target, outcome, counts — and drop the prose, or store a hash and reference instead. Where a human needs the words later (an appeal, a dispute), keep the text in the guarded system of record and let the log point at it.
Test it with canaries, not hope¶
Redaction that is never tested is a hope, and agent systems change too fast for hope: a new tool, prompt, or model, and an unreviewed field starts flowing into the log. Make the test mechanical:
- Plant canary values — fake but realistic secrets and personal data with unique, searchable strings — throughout a staging run: prompts, tool outputs, error paths, user messages.
- Run the agent end to end, including failure and retry paths, where the sloppiest logging lives.
- Search the finished logs for every canary. Any hit, in any system the logs reached, fails the test and blocks release until the write path is fixed.
- Re-run after every prompt, tool, model, or logging change.
Retention and access: redacted is not the same as safe¶
A redacted log still describes who did what, when, and to which records — sensitive evidence in its own right. Give it the audit trail's discipline: named access (not “everyone in engineering”), a retention period set by risk tier with deletion that actually happens, and separation from anything that could undo the redaction. If a mapping table can re-identify masked values, it is a credential store: guard it separately — deleting it can make retained records permanently anonymous.
The 10-minute starter version¶
Full field-by-field treatment is the destination; this is the version a solo builder can ship today. Put a secret-pattern blocklist at the single write path every record passes through, so nothing is written unchecked. Swap raw payloads for hashes plus references. Add one canary string to a staging prompt and prove it never lands in the log. Three changes — and your trail stops being the easiest place to steal the keys it was meant to account for.
From there the work is systematic: declare data classes in the plan bound, map each class to its treatment, and let the canary test keep every future change honest — an audit trail that can answer hard questions without exposing the data it exists to protect.