PII Redaction for AI Agent Logs: Keep Audit Detail Without Leaks

To redact personal data from agent logs, apply redaction at the point where events are written, not in a cleanup step after export. Replace personal values with typed placeholders that keep their meaning, such as customer_phone or order_owner, so each event still shows what happened. Keep any mapping back to the original values in a separate, restricted store, and test the whole pipeline with fake personal data planted in realistic places.

Key takeaways

• Redact at write time, before data reaches traces, queues, caches, vendor debug stores or backups.
• Replace values with typed placeholders so events stay readable for reviewers who never see the raw data.
• Store any re-identification map separately, with its own access rules and its own log.
• Test redaction with planted synthetic identifiers across every write path, and repeat the test after every change.
• Decide retention and access for agent logs before the first incident, not during it.

Why redacting exports after the fact leaves gaps

A common first attempt is a script that scrubs names, emails and phone numbers from a log export each night. It looks reasonable, but it only covers the file someone exported. Agent systems write to many places: the model prompt and response, tool arguments, tool results, retrieved documents, memory entries, error messages, job queues and tracing systems. Personal data can sit in any of them at once, and some of those copies are never exported at all.

Tool arguments are a frequent source of leaks. When an agent looks up a customer, the lookup call often contains the full name or phone number, and the returned record often contains an address. Error handlers add another risk, because stack traces and validation messages frequently echo the input that caused the failure. A scrubbed export does not clean the trace collector that stored the same error an hour earlier.

Observability tooling makes this easier to reason about. The OpenTelemetry project treats traces, logs and metrics as separate signals, each carrying its own attributes and each needing its own handling. Apply the same thinking to agent logs: list every signal your agent emits, then decide what each one may contain before any value is written.

What an audit or incident review actually needs

Before choosing placeholders, define the questions the log must answer. Most audits and incident reviews ask some version of the same things: which agent acted, under which version and configuration, which tool it called, against which record identifier, at what time, with what outcome, and whether a human approved the step when approval was required.

Most reviews do not need the full text of a customer's message, a payment identifier, a health detail or a complete address. A reviewer usually needs to know that a customer record was read, that a reschedule was proposed, and that a staff member approved it. The content of the record is rarely part of the question. Writing this down early also makes it easier to justify the redaction rules to the people who will later ask why a detail is missing.

Keep the approval record as its own event. If the agent stopped to ask for approval, the log should show the request, the approver's role or identifier, the decision and the time. That single chain is often what an incident review needs most.

A step-by-step redaction plan

Use this sequence when you add redaction to an existing agent or design it for a new one:

• Step 1: Inventory every write path, including prompts, model outputs, tool calls, tool results, memory writes, error handlers, queues, traces and any vendor-side debug or evaluation storage.
• Step 2: Classify the data in each path into direct identifiers, indirect identifiers, sensitive categories and free text. Free text needs the strictest handling because people write unexpected things in it.
• Step 3: Define one placeholder per data type, such as customer_name, customer_phone or account_reference, and keep them consistent within a session so events can still be linked.
• Step 4: Apply redaction inside the logging layer, before serialization. Redacting in a dashboard leaves the raw value in storage.
• Step 5: Decide whether any re-identification is needed. If it is, create a token map with keyed tokens, encrypt it, restrict access and log every lookup.
• Step 6: Redact errors and stack traces, which often repeat input values.
• Step 7: Test with planted synthetic identifiers in every path, including inputs designed to make the agent repeat personal data.
• Step 8: Name an owner for the logging rules and set a review date, because tools, prompts and integrations change.

Where personal data hides in agent logs

Use this checklist during design and again after any integration change:

• Tool arguments that carry names, phone numbers, emails or record identifiers
• Tool results that return full records when the agent needed one field
• Retrieved documents and memory entries that include customer details
• Model outputs that restate a customer's message in full
• Error messages and stack traces that echo input values
• File names and attachment metadata, which often contain personal names
• Vendor debug logs, evaluation datasets and support copies
• Backups, snapshots and exports made for troubleshooting

The checklist is most useful when someone who did not build the agent reviews it. Builders tend to see the fields they expected, while a reviewer sees what the system actually writes.

Illustrative scenario: a rescheduling lookup

The following scenario is illustrative and does not describe a real client. A small field service company uses an agent to help customers reschedule visits. A customer writes in with a phone number and a request to move an appointment. The agent calls a lookup tool with the phone number, receives a record containing a name and street address, proposes a new time, and asks a staff member to approve it.

In the first version of the logs, the phone number appeared in the tool argument, the street address appeared in the tool result, and a validation error included the full name. After the redaction rules were applied at write time, the same event reads as a lookup using a customer_phone placeholder, a record reference that is a keyed token, a result status of found, a proposed change with a time window, and an approval event showing the staff role that approved it. The review can still answer what the agent did, when, under which approval, and what changed. The raw contact details were never written to the log, and the token map sits in a restricted store.

Keeping the trail without keeping the secret

A practical question is whether to hash or tokenize identifiers. A plain hash of a phone number is weak protection, because the space of possible phone numbers is small enough that someone can test candidates. Keyed tokens, produced with a secret key that is stored separately, are much harder to reverse. The same customer should map to the same token within a defined scope, so events remain linkable, but the key and any mapping table need strict control.

Decide who may resolve a token, under what circumstances, and how that access is recorded. In many companies the answer is a small set of people responsible for compliance or incident response, with a documented reason for each lookup. Keep the retention period for logs and for the token map written down, since a map kept longer than the logs it supports creates its own exposure. The article on retention rules for agent logs covers how to balance these periods against audit needs.

The same discipline applies to the agent's own memory. If the agent stores customer facts for later use, decide what it may keep, and make deletion possible. The guide on deleting agent memory on request describes how to find, remove and verify that deletion.

How Be Human handles this, and testing for blind spots

In a Be Human engagement, the logging scope is defined with the company during the first useful role, alongside the memory, tools, approval boundaries and success criterion for that role. Placeholder types, token rules and retention periods are written into the operating context, and redaction is implemented in the agent's logging layer rather than in a reporting tool. In managed operations, log coverage tests are part of recurring evaluations, and permission reviews check who can resolve tokens. When an incident happens, the written logging rules tell the response team what evidence exists and what has been kept out of it.

Testing is what turns a redaction design into a reliable one. Plant synthetic identifiers in test inputs, run the agent through normal and unusual requests, then search every write path for those identifiers. Include inputs that try to make the agent repeat data, because injected instructions can cause a model to copy sensitive text into a field nobody filtered. Review a sample of real events each month, and repeat the planted-identifier test after every change to a tool, prompt or integration. Treat any miss as a defect in the logging layer, and record the fix.

If you are not sure which of your agent workflows writes personal data to logs today, the free Be Human AI diagnostic can help you find the first task worth handing to an agent, with its logging rules defined from the start.

Frequently asked questions

Should we keep the original personal data in the logs at all? Usually not in the operational log itself. Keep the events, decisions and approvals in the log, and store any original values only where a documented business or legal need exists, in a separate restricted system with its own retention period. Many reviews are satisfied by placeholders and stable tokens alone.

Does redacting agent logs satisfy data protection law? Redaction reduces exposure, but it does not by itself settle your legal obligations. The rules depend on your country, your sector and the purposes for which you process personal data, so review them with qualified counsel. The article on LGPD and AI agents for Brazilian companies is a useful starting point for Brazilian operations.

How do we know the redaction is working? Test it with synthetic identifiers planted in every write path, including inputs designed to make the agent repeat personal data. Then sample real events on a recurring schedule and search them for patterns that should never appear. A passing test on one path does not prove the others are covered, so keep the test list current as tools and integrations change.

Who should be allowed to resolve a token back to the original value? Limit this to a small group with a defined reason, such as compliance review or incident response, and require a recorded justification for each lookup. Review that list on a schedule, and remove access when someone changes role. Logging every resolution is as important as restricting it, because it lets you see how the mapping was used.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.