To evaluate an agent, you have to see what it did, so you capture its trajectory: every model call, every tool call and its arguments, every result, the whole context. The last few posts argued for exactly this, because you cannot improve what you cannot see.
Read that capture as a data-protection engineer. An agent's trace is a complete, structured copy of everything the agent handled, including the sensitive parts, and it usually flows to somewhere outside your application to be viewed. The thing that makes an agent debuggable is also a fresh copy of your most sensitive data, in a new place.
An agent trace is unusually complete
Ordinary application logs are sparse by habit: a request id, a status, a duration. An agent trace is the opposite, because usefulness demands detail. To debug why an agent did something, you need what it saw and what it produced at each step, which means the trace captures a great deal.
Look at what is in a full trace of a real task.
- The user's input, whatever they typed, which may be personal or confidential.
- Tool arguments, which routinely carry identifiers, account numbers, and sometimes credentials.
- Tool results, the retrieved documents, the database rows, the file contents the agent read.
- The model's reasoning and the context, which by this point in the run holds all of the above.
A single trace can therefore contain customer PII, internal figures, extracts of confidential documents, and the occasional secret that ended up in a tool argument, all together, all captured because you wanted to be able to evaluate the run.
An agent trace captures the input, tool arguments, retrieved documents and the full context, all in one record.
And then it leaves your application
Capture alone would be a contained risk. The trace does not stay put.
Observability works by exporting telemetry, often to a third-party backend where you actually view and query it. That export is a data flow: your traces, with everything in them, leaving your application and landing in someone else's system. It is the same boundary question as the sandbox-egress post, now for your logs. A trace full of customer data sent to an external observability vendor is customer data sent to an external processor, whatever the intent.
This is where the eval need and the data risk pull in the same direction and make things worse. Better evaluation wants more detail captured; data protection wants less sensitive data copied and exported. The natural instinct, "capture everything so we can debug anything", is precisely the instinct that fills your telemetry with data you did not mean to send anywhere.
The two old mistakes, in a new pipeline
None of this is novel as a class. Two long-standing mistakes just reappear in the telemetry path.
Secrets in logs. Credentials and tokens have always leaked into logs, because something got printed that should not have been. An agent widens the surface: any tool argument or result can carry a secret, and the trace captures them all by default.
Sending data to a processor without meaning to. Shipping personal data to a third party is a regulated act, with obligations about consent, location, and processing agreements. Doing it by accident, because your observability export happened to carry PII, does not make the obligations go away. It just means you are meeting them, or failing them, without having decided to.
Keeping the trace safe
The controls are data-minimisation and data-handling, applied to the telemetry pipeline.
| Control | What it changes |
|---|---|
| Redact sensitive fields before export | PII, credentials and secrets are masked in the trace, not shipped raw |
| Capture what you need to debug, not everything | Log the shape and the decision, not always the full raw content |
| Keep the sensitive detail in your own store | If a trace must hold raw data, it stays in a system you control, not a third-party backend |
| Treat the observability backend as a data processor | Same diligence as any vendor that handles your data: location, agreements, access |
| Set retention and access control on traces | Traces are deleted on a schedule and readable only by those who should |
| Scan telemetry for secrets, and rotate what leaks | A credential you find in a trace is a credential to rotate and stop capturing |
Redact before export, capture what you need not everything, and keep raw sensitive data in a store you control.
The first two rows carry most of the weight. Redaction at the point of export means the trace can be detailed enough to debug while masking the fields that must never leave, and capturing the decision rather than the full raw payload, "read a 40,000-token file", not the file, keeps a trace useful without making it a copy of the data. You can have observability and data minimisation at once; it just has to be designed in, not bolted on after the first audit finds customer records in a log aggregator.
What this touches
The cleanest lens here is data protection, not a single agentic threat code. The closest framework mapping is T3 Privilege Compromise, whose pack description covers misconfigurations, an over-broad telemetry pipeline that captures and exports more than it should is exactly that. The point is squarely a data-handling one, so the frameworks touch it only lightly.
On the regulatory side, and here framed as more than scope because it is the heart of the matter: data protection, confidentiality, data-minimisation, retention, and the use of third-party processors are core obligations across GCC rulebooks, and in many regimes the location of that data matters too. An agent's telemetry that copies personal and confidential data and exports it to an outside backend is precisely the kind of data flow those obligations govern, whether or not anyone decided to create it. Which obligations apply depends on your regulator and architecture, and that mapping is an advisory estimate until someone checks it properly.
The part worth keeping
Observability is not optional. Without traces you cannot evaluate, debug, or improve an agent, and this series spent a whole chapter arguing for capturing them well. Nothing here says log less and fly blind.
The point is that a trace is data, some of it your most sensitive, and it has to be handled as data. Redact before it leaves, capture the decision rather than the raw payload where you can, keep the sensitive detail in a store you control, and treat the backend as the processor it is. Do that and you get the observability you need without turning your debugging pipeline into an unplanned export of everything the agent ever touched.