Your AI agent traces are probably leaking secrets

AI agent traces are useful for debugging. They show you what the model saw, which tools it called, what those tools received, and what came back. But that same visibility can turn your observability stack into another place where secrets can leak.

A trace can quietly capture credentials alongside the data you meant to collect. Once that data reaches your observability system, it can be exported or viewed by anyone with access to those traces. And if you’re relying on redaction to catch everything, you may already be too late.

You’ll learn what an agent trace actually contains, how credentials can end up in trace payloads, and why redaction alone isn’t enough. You’ll also see how to keep authentication inside trusted application code, scope credentials to individual agent workloads, and audit your observability pipeline with a safe test value.

What an AI agent trace contains

Traditional Application Performance Monitoring (APM) tells you that a request happened, how long it took, and whether it failed. An AI agent trace needs to tell you more. To understand why an agent behaved the way it did, you need context around the model's decisions. That usually means recording what it received, which tool it selected, what the tool was given, what came back, and where things went wrong. Here is a simplified example of what a tool span might look like:

At first glance, this is useful for debugging. But from a security perspective, the same payload contains data the agent does not need to expose. The Authorization header includes the credential used for the request, while the response includes the customer's email address. Both are now part of the trace and may be stored or exported with the rest of the telemetry.

The same applies to other values you may not initially think of as trace data, including API keys, signed URLs, database connection strings, cookies, private keys, and credentials exposed in error messages. But how does all that information get into the trace in the first place? Let’s look at the most common paths.

How credentials reach trace payloads

Sensitive data can reach agent traces through three common paths: data flowing through the agent, errors and exceptions, and application state or context.

Data flowing through the agent

Agent traces commonly capture model inputs and outputs as well as tool arguments and results. This means sensitive information can become trace data simply by passing through the workflow. A retrieval tool might return a customer profile containing an email address and phone number, even though the agent only needs the customer's account status. A system prompt might also contain an internal identifier or a piece of sensitive configuration that gets captured with the model input. Once the data enters the workflow, the model can reproduce it in a response or pass it to another tool, causing it to appear in additional spans.

Errors and exceptions

Sensitive data can also surface when an operation fails. Depending on the client or SDK, an exception may include details from the request or response that caused the failure. A database error could expose part of a query or connection string. An HTTP error might include request headers or a response body. These details can end up in the trace even though they were never intended to be part of the agent's observable output.

Application state and context

The third path comes from the application state surrounding the agent run. Developers may attach objects to spans because having the full context makes debugging easier. That object could contain a user's session, an HTTP client's configuration, a memory store, or runtime configuration. Serializing it for telemetry can pull in values that were never meant to leave the application. A session object might contain a user's email address, while a configuration object could contain an API key.

Why redaction alone is not enough

Redaction is useful, but it should not be your security boundary. It can still fail in a few important ways:

• It only catches what you know to look for: A rule that removes Authorization headers may miss the same credential in a connection string, nested tool result, or unexpected error message.
• It may happen after the data has already left your environment: If an unredacted span reaches your observability provider before redaction, masking it in the dashboard does not undo that exposure.
• It does not limit what an exposed credential can do: Redacting a production key does not reduce its permissions or make it unusable. If the original value is exposed, it remains a risk until it is revoked or rotated.

Redaction adds another layer of protection, but keeping credentials out of trace payloads starts with how the application handles them.

How to keep credentials out of AI agent trace payloads

Protecting sensitive data in agent traces requires control over what gets captured and what happens if something slips through. Here’s how:

Inject secrets at runtime

Keep credentials out of source code and agent configuration files by injecting them at runtime. For example, the Doppler CLI can provide an agent with the secrets it needs when the process starts:

The application can then use those credentials to authenticate requests while keeping them outside the model’s context and tool arguments.

Use scoped credentials

Give each agent only the access it needs for its workload. An agent that only checks order status, for example, should not have permission to issue refunds or modify customer records. Where possible, use short-lived credentials to limit how long that access remains valid. This reduces the impact if a credential does end up in a trace. The fewer permissions it has and the shorter its lifetime, the less an exposed credential can be used for.

Avoid sensitive debug data

Be selective about what your application records. Attaching entire request objects, user records, configuration, or environment data to a span can expose sensitive values that were never needed for debugging.

Instead, record only the details needed to understand what happened. A file-processing tool, for example, might capture the file name, operation, and result without storing the file contents. An exception can record the error type and relevant context without including the full request or response.

Limit access and retention

Even when preventive controls are in place, traces should be treated as sensitive operational data. Restrict access to the people and systems that need it, including who can search, export, or replay traces. Keep full trace payloads only as long as they are useful for debugging.

Use redaction as an additional safeguard for sensitive values that still make it through. But it should complement these controls rather than serve as the primary security boundary.

Once you’ve put these controls in place, the final step is to audit your tracing pipeline and verify that they’re actually keeping sensitive data out of your telemetry.

Audit your tracing pipeline

In a test environment, use a clearly identifiable non-sensitive test value. Run it through the same paths a real credential might take. Then follow that value through your tracing pipeline. Check tool arguments and results, span metadata, exception data, collectors, observability backends, exports, and any other systems that receive trace data.

If the value appears somewhere it shouldn’t, find where it entered the pipeline, fix that path, and rerun the test. Additionally, verify that trace access and retention also match the limits you’ve set, including who can search, export, or replay trace data. Repeat the test when you add tools, change your instrumentation, or introduce a new telemetry destination.

Try a Doppler demo to see how you can inject agent credentials at runtime and keep them out of traceable data.