Disclosure: BlueBear sells a platform that records agent telemetry and audit evidence separately, so we have a commercial interest. The instrumentation policy below applies to any tracing stack, and most of it is a decision about what to capture rather than what to buy.
Nobody decides to do this
You instrument the agent because you need to know why a run failed. The instrumentation captures the tool call and its arguments, because a tool call without its arguments is not diagnostic. The arguments contain a customer identifier, a document, an address, an amount.
At no point does anyone decide to copy customer records into the tracing backend. It is a consequence of capturing what you need to debug. The result is a second copy of sensitive data in a system that was scoped as operational tooling.
Why the second copy is worse than the first
The original lives in a system with access controls, a retention policy, and a place in your data map. The trace store usually has wider read access, because engineers debug with it. It usually has a longer or vaguer retention setting, chosen for operational convenience. And it is often not in the data inventory at all, because it was classified as infrastructure.
The sharpest version of the problem is deletion. If a customer exercises a deletion right and the record is removed from the database while the trace containing it persists for another ninety days, the deletion did not happen. This is discovered late, and usually by someone external.
Capture the shape, not the content
The useful realisation is that most debugging questions do not need the values. They need the shape of what happened: which tool was called, against which kind of record, how many results came back, how long it took, whether it failed and how.
That is enough to answer why the run was slow, where it stopped, and which step behaved unexpectedly. It is not enough to reconstruct what the customer said, which is exactly the property you want. Where content genuinely matters, store a reference to the source record rather than the value, so the trace points at the data instead of duplicating it.
Keep telemetry and audit records apart
These get conflated because both look like logging, and the conflation harms both.
Telemetry answers what did the system do and how fast. It can be sampled, aggregated, and expired quickly. An audit record answers who was authorised to do what. It must be complete, and it must survive.
Trying to serve both from one store produces the worst of each: a trace backend too sensitive to retain comfortably, and an audit position that depends on sampled data. Separate them and each becomes simpler. The audit record holds identity, authorisation and outcome, with no payloads. The trace holds shape and timing, with a short life.
Four checks
- Take one trace from last week and read it. If you can reconstruct what a customer asked or which record was touched, that trace is customer data.
- Is the trace store in your data inventory? If it is filed as infrastructure, it is outside the review that governs the source.
- Compare retention against the source system. If the trace outlives the record, deletion is not being honoured.
- Who can read traces? Compare that list against who can read the underlying database. If it is wider, you have widened access to the data by instrumenting it.
What this costs
Changing what you capture is cheap and mostly a configuration decision, taken once, at the point where tool calls are recorded. Splitting audit from telemetry is a design choice that is easy at the start and awkward later. Retention alignment is free and usually just never assigned to anyone. The expensive path is the one where nothing is decided and the trace store quietly becomes the largest uninventoried copy of customer data you own.
The three places the copy actually lands
Knowing that traces hold sensitive data is not the same as knowing where it ends up. In practice there are three destinations, and they have different owners, different retention and different access lists — which is why fixing one rarely fixes the others.
The tracing backend. The obvious one. Spans carry tool arguments and, if you capture them, prompt and response bodies. Retention here is usually set for debugging convenience — thirty to ninety days — and read access is typically the whole engineering team.
The error tracker. The one people forget. When a tool call throws, most error reporters attach local variables and request context to the event. That means the arguments that caused the failure travel to the error tracker along with the stack trace, and error events are commonly retained longer than traces because they are treated as low volume.
The log aggregator. A generic logger.info("calling tool", args) is enough. This one is the hardest to audit because the offending line looks unremarkable in review, and log pipelines usually fan out to more destinations than traces do.
What to do first if you find all three
Do not start by changing what is captured, because that requires touching every call site and you will not finish. Start with retention on the trace store, because it is a single setting, it takes effect immediately, and it bounds the exposure of everything already collected.
Then change what is captured at the one place tool calls are recorded — usually a single wrapper — which fixes the future without a sweep. The error tracker comes third, and it is normally a scrubbing configuration rather than code.
The reason for that order is that the first step shrinks a growing problem while the other two are still being scheduled.
The question to settle before instrumenting the next agent
Decide, once, what a trace is allowed to contain — and make it a property of the wrapper every tool call goes through rather than a rule people are asked to remember. Rules that depend on each engineer recalling them at the moment they add a log line do not survive contact with a deadline.
The version that holds up is short: shapes and identifiers yes, content no, and where content genuinely helps debugging, a reference to the record rather than the value. Written into one wrapper, that decision applies to every agent you add afterwards without anyone thinking about it again.
Questions people actually search for
- does tracing an ai agent capture customer data
By default, usually yes. Agent tracing captures prompts, tool call arguments and responses, because those are what you need to debug a run. Prompts contain whatever the user typed, arguments contain record identifiers and often the records themselves, and responses contain the result. The trace is therefore a copy of the sensitive fields, sitting in a system that typically has broader access and longer retention than the source.
- what should you not log in ai agent telemetry
Raw prompt and response bodies, full tool arguments, and credentials. Capture the shape instead of the content: which tool, which record type, how many results, how long it took, whether it succeeded. That keeps a trace diagnostic while removing the part that makes it a second copy of the data. Where the content genuinely matters for debugging, store a reference to the source record rather than the value.
- do ai agent traces have to be deleted when the customer data is deleted
Yes, if the trace contains that data - and it usually does, because tool arguments carry record identifiers and prompts carry whatever the customer typed. This is the trap most teams miss: traces are retained on an operational schedule chosen for debugging convenience, while the data inside them is governed by a policy with a shorter clock. If the record is removed from the database and the trace containing it survives another ninety days, the deletion did not happen. It is usually discovered late, and by someone external.
- is an audit trail the same as telemetry for ai agents
No, and conflating them causes both problems. Telemetry answers what the system did and how fast, and can be sampled and expired. An audit record answers who was authorised to do what, and must be complete and durable. Trying to make one serve both produces a trace store that is too sensitive to keep and too incomplete to rely on.