It's 10:40 pm and an on-call engineer is trying to figure out why your lending agent told a customer her application was "denied for insufficient income" when it was actually approved. She opens the trace for that session and the observability tool replays everything, step by step. The customer's name and address, pulled from the CRM. Her annual income and employer, from the loan origination system. Her credit score, from the bureau call. Her own words in the chat that she'd recently divorced and her income had changed. The model's reasoning about all of it, in plaintext, in order.

Ninety seconds later the engineer has found the bug to be a tool call that returned stale data. She has also just read a near-complete financial and personal profile of a woman she has never met and had no business reason to know.

Nothing was breached and no control failed. The engineer had exactly the permission her role grants: read traces. That's the problem.

‍

The wrong mental model

The conventional wisdom treats agent observability data as operational exhaust and protects it the way we've always protected logs. Mask a few fields, set a retention window, restrict the bucket, move on.

That instinct secures the wrong unit. A log describes the system. A trace describes a person. A log line tells you the payments API returned a 200 in 340 milliseconds. A trace stitches together everything the agent saw, retrieved, reasoned about, and said that for one individual, in one session, in sequence. Correlation around a person isn't a side effect of tracing. It is the entire point of tracing. Which means every trace of a customer-facing agent is, functionally, a dossier.

‍

Three things that make traces a different problem

Traces aggregate by individual. Before the agent existed, the CRM held her contact details, the loan system held her income, the bureau held her score, and each fragment sat behind its own access model. The trace joins all of them, plus her conversation, plus the model's inferences about her, into one record keyed to one person. The data-minimization work of two decades, undone by a debugging tool.

Traces are built to be read by humans. Logs are mostly grepped by machines. Traces are opened by people including engineers debugging, support staff investigating a complaint, QA reviewers checking agent quality and annotators scoring outputs for the next model version. Human review of agent behavior is exactly the oversight everyone is demanding: boards, regulators, your own risk team is demanding. And every one of those review sessions puts a specific customer's data in front of an employee.

Traces persist and travel. A conversation that lasts ninety seconds gets shipped to a third-party observability platform, copied into an eval pipeline, sampled into an annotation queue, and sometimes folded into a fine-tuning set. Each copy inherits everything embedded in the spans.

And to be clear: none of this means logs are solved. Agent logs capture full prompts and completions, so they carry the same raw material and deserve real protection: detection and masking of sensitive values at write time, tight retention, restricted access.. But log protection is field-level work. Trace governance is person-level work. Masking a card number in a log is table stakes; deciding which human, for which purpose, gets to see which person's trace, at what level of detail is a different question and the tooling we inherited from the logging era doesn't ask it.

‍

It's worse than it looks

Agents multiply this surface. Every autonomous step is another span; every span is another capture of context. Meanwhile, the people with the broadest trace access are precisely the people with the least business need to see identity: platform engineers, observability admins, your vendor's support team.

Regulators will not read a trace as telemetry. They will read it as a record about a data subject, which means access rights and deletion rights apply. Try honoring one person's deletion request across months of traces replicated into an observability vendor, an eval platform, and a training snapshot. If her identity is embedded in the spans, you can't.

And here's the part I'd underline: the more responsibly you monitor your agents, the more copies of customer data you put in front of humans. Human-in-the-loop was supposed to be the safety mechanism. Ungoverned, it becomes the exposure.

‍

What getting it right looks like

• De-identify before the trace is born. Tokenize sensitive values at capture, so traces carry references, not identities. The trace stays fully debuggable, with structure, sequence, tool calls, and latencies all intact, because the bug is almost never in the customer's name.
• Make re-identification contextual and purpose-bound. Reveal a real value only when role, purpose, and case line up from this ticket, this customer, these fields to these time-boxed, logged. In my view, that sentence is the working definition of contextual access.
• Apply the same source-level discipline to logs, but govern the right unit. Field-level masking for logs; person-level access decisions for traces.
• Make traces deletable per person. If identity is referenced rather than embedded, honoring a deletion request means severing one mapping, not rewriting every span in every downstream copy.
• Audit the observers. Keep a record of who opened whose trace, and why. Oversight of agents needs oversight of its own.

This is the approach we took at Skyflow: identity lives in a vault, traces and logs carry tokens, and detokenization is a governed, audited act tied to a purpose, not a standing privilege.

‍

The flag

Every enterprise deploying agents is about to build a human review layer over them. Regulation and common sense both demand it. The part I think defines the next few years is whether that review layer sees people, or sees references.

A log describes the system. A trace describes a person. Govern them accordingly.

‍