The Observability Trap: When Watching Your AI Agents Becomes the Leak

Every “AI agentic gone wrong” postmortem ends with the same recommendation: log more. Capture every tool call, every argument, every response, so the next incident is a query instead of a guessing game. It’s good advice. It’s also how a growing number of teams have quietly built a second, less defensible copy of their most sensitive data — sitting in an LLM observability platform, a trace store, or a support engineer’s log viewer, often with weaker access controls than the system it came from.

Observability was supposed to be the fix for agents gone wrong. Done carelessly, it becomes a new instance of the same problem: a system that holds credentials and private data, reachable by more people than the original one ever was.

How the audit trail turns into the leak

The failure mode isn’t exotic. It’s the default behavior of most tracing and logging tooling, applied to a new kind of workload:

• Full request/response capture. Debugging an agent that “did the wrong thing” is much easier with the complete tool-call payload in front of you — so teams turn on verbose logging, and the trace store ends up with the same API keys, session tokens, and customer PII that flow through the calls themselves.
• Third-party LLM observability platforms. Prompts, tool arguments, and raw responses routinely leave your infrastructure entirely, headed for a SaaS dashboard that was built for latency graphs and token counts, not for holding regulated data.
• Broad log access. An audit trail is only as private as who can read it. Support engineers, on-call responders, and anyone with dashboard access can usually see everything in a trace — which defeats the point of scoping the agent’s access carefully if the log of its actions isn’t scoped at all.
• Copy-paste debugging. A trace gets pasted into a ticket, a Slack thread, or a bug report to explain what an agent did — and the secret or customer record inside it goes wherever that ticket goes.

None of this requires an attacker. It’s what “good observability practice” looks like by default, and it directly contradicts the reason observability exists in the first place: to make agentic actions accountable, not to create a softer target holding the same data the agent was trusted with.

Login handshakes don’t cover this either

It’s worth being precise about what a strong login handshake — MCP’s OAuth flow, an A2A handshake between agents — actually proves: that the caller is who it claims to be, at connection time. It says nothing about what happens to the payload of a call after it’s authorized. An agent can pass every authentication check, use a properly scoped credential, and still have the response body it just received written verbatim into a trace that fifty people can query. The handshake and the leak live at completely different layers, which is exactly the pattern we’ve pointed at before with MCP tool poisoning and the lethal trifecta: a valid, well-authenticated call is not the same thing as a safe one.

What observability needs to capture — and what it doesn’t

The instinct to log everything comes from a real need: answering “which agent did what, when, and was it allowed?” has to be possible without reconstructing events from memory. But that question doesn’t require a raw copy of every payload. It requires:

• Who — the agent principal and the human or system it acted for.
• What — the tool, the upstream host, and enough to prove which call this was without storing its contents.
• Why it was allowed — the policy decision, and which credential reference was used, never the secret itself.
• Result — status, latency, success or failure.

Notice what’s missing: the argument values and the response body. A hash of the arguments gives you integrity and correlation — “was this the same request as that one?” — without turning the audit log into a second copy of whatever the agent just touched. That’s a design choice, not an oversight, and it’s the difference between an audit trail that makes agents accountable and one that makes them a bigger target.

The business case: an audit trail that can’t leak what it never stored

This is the same chokepoint argument we’ve made for scoped credentials and per-call policy: if every agent call already passes through a broker to get a credential, that broker is the right place to build observability that’s safe by construction, not observability you have to remember to lock down afterward.

• Metadata-first audit logging. Fullmakt’s cryptographically chained audit log records who, what, when, the policy decision, and a hash of the arguments — not the raw payload. You get a tamper-evident record you can query for forensics or compliance without that record becoming a second data store an attacker (or an overly curious teammate) would want to reach.
• Response sanitization before anything downstream sees it. Policy can mark fields as sensitive — an SSN, a card number, a secret — so the values are masked in the response before it reaches the agent’s own context, let alone a trace or a log. What never reaches the agent’s context can’t end up quoted back into a chat transcript, a ticket, or a third-party observability platform six steps later.
• Credential references, never credentials, in every trace. Every audit entry and every trace hop carries which credential reference was used to authorize a call — not the secret behind it. Reading the full history of what an agent did never requires exposing what it authenticated with.
• One place to scope who can query the trail. Because the broker is the single chokepoint for issuance and audit, access to “what did this agent do” is governed the same way access to the agent’s own credentials is — not left to whatever permissions happen to exist on a support dashboard or a SaaS trace viewer.
• Traceability across hops, without a copy at each one. When one agentic action triggers another agent or tool call, the chain of custody is reconstructable from broker-side metadata — you don’t need every hop to have independently logged and retained the full payload to answer “what caused this.”

None of that means “log less” in the sense of losing accountability — it means putting the record of that a call happened, who authorized it, and under what policy in a place designed to hold it safely, and keeping the sensitive contents of the call out of every place that doesn’t need them. It’s the same principle behind scoped, short-lived credentials, applied to the trail those credentials leave behind.

FAQ

Can an AI agent’s audit log itself be a data leak? Yes. Verbose logging and third-party LLM observability tools frequently capture full request/response payloads — including credentials and personal data — and store them with weaker access controls than the systems the agent was calling in the first place. The log meant to catch an incident can become the incident.

Does OAuth or an A2A handshake protect the data inside a logged call? No. A handshake proves identity at connection time. What an agent does with an authorized response — including whether it gets written verbatim into a trace — is a separate concern that authentication doesn’t touch.

What should an agent audit log actually store? Enough to answer who did what, when, and whether it was allowed: the principal, the tool and host, the policy decision, the credential reference used, the result, and a hash of the arguments for integrity and correlation. Raw argument values and response bodies don’t need to live there.

How does response sanitization help if the agent already saw the data? The point is to mask sensitive fields in the response before they reach the agent’s context at all, based on policy — not to redact after the fact. Data the agent’s context never held can’t later surface in a transcript, ticket, or downstream trace.

Doesn’t hashing arguments make debugging harder? It makes debugging safer, not blind — a hash still lets you confirm two calls were identical or correlate a call across systems. For genuine forensic need, that correlation, combined with the credential reference and policy decision on record, is usually enough to reconstruct what happened without a second copy of the sensitive payload sitting in a log store.

The instinct behind “log everything so we can catch agents gone wrong” is correct. The mistake is assuming more capture is always better observability. The trail that actually makes agentic AI accountable is the one built to answer what happened without becoming a second place the answer to what did this agent see leaks out of.