An incident happens. A record that should not have been touched was touched, and the request came through an agent. You pull the logs to answer the only question that matters in that moment. Who did this, on whose behalf, and under what authority. And the logs tell you it was a service account. Not the user. Not the agent acting for the user. Not the sub-agent the first agent handed the work to. A credential, doing a thing, with no chain behind it.
This is the sub-agent boundary problem, and it is where a lot of otherwise careful agent deployments quietly fail their first real audit. The trail is clean up to the point where one agent delegates to another, and then it goes dark. This guide is about why that happens, what a trail that survives delegation actually needs to record, and why the same design that enforces per-hop authorization is the one that produces the audit. It builds on our pillar on multi-hop delegation for AI agents.
What breaks at the sub-agent boundary?
The sub-agent boundary is the point where one agent hands part of a request to another agent or tool. The audit trail breaks there when the downstream system logs the immediate caller, the sub-agent or its service credential, rather than the full chain of who is acting for whom. The record shows what happened but not the delegation behind it, so you can see that a service read a record without being able to prove which user, through which agents, that read was on behalf of. The trail exists, but it stops answering the accountability question at exactly the hop where accountability gets complicated.
The information is not gone because it never existed. It is gone because nothing captured it at the transfer, and reconstructing it afterward from disconnected logs is guesswork.
Why the trail goes dark
The cause is the same anti-pattern that breaks per-hop authorization. When an agent forwards a bearer token unchanged or swaps the user's context for a broad service credential, the downstream logs record whatever identity actually arrived. If that is a service account, the logs show a service account. Reiner Mertens of KuppingerCole put the shape of this precisely at EIC Berlin 2026. When you try to write the audit record for an agent-initiated action, you want to capture the acting party, the user being represented, the policy that decided, and the outcome. His slide wrote it as the acting agent, then a question mark where the delegated user should be, then the policy and outcome. The question mark was the point. With today's common patterns, you cannot fill in the on-behalf-of field cleanly, because the delegation was never carried in a form the downstream system could log.
The MCP security guidance names the mechanism from the other direction. Token passthrough, forwarding a token that was not issued for the receiving server, is forbidden precisely because it lets a server act with an identity that is not really the caller's, which is a security problem and an audit problem at once. If the token lies about who is acting, the log inherits the lie.
What a replayable audit actually needs
A trail that survives delegation is not a matter of logging more. It is a matter of logging the right thing at the right place. At each hop, the record needs four things:
- The acting party, meaning the specific agent or workload making this call;
- The principal it is acting for, meaning the original user, carried intact from the top of the chain;
- The policy that produced the decision, including its version;
- And the outcome, allow or deny, with the context that was evaluated.
Capture those at every transfer and you have a record you can replay, one that reconstructs the whole chain back to the original user rather than stopping at the nearest service account.
The standards work is converging on exactly this. The IETF's Transaction Tokens draft is built so that the user's identity and authorization context are preserved and available to every workload in the call chain, and so that each workload can immutably assert that it was invoked as part of processing the request. That immutable assertion is the audit primitive. It means a downstream log entry is not just this service did this, but this service, invoked through this chain, on behalf of this user, did this. The delegation carried by Token Exchange is what makes the on-behalf-of field fillable.
Walking one incident back
Picture the incident. A customer record was exported that should never have left the system, and the export was triggered through an agent. The board wants to know who did it and under what authority, the regulator wants it documented, and legal wants it before the disclosure clock runs out.
With a broken trail, you start at the export and work backward. The database log shows a finance service account ran the query. Whose request was it. You check the finance tool's logs, which show a call from an internal service, which turns out to be a retrieval agent, whose logs show it was invoked by an assistant, whose logs, if they exist, might name a user, or might just show a session. Every step is a different team, a different log format, and an inference rather than a fact. Hours later you have a best guess, with caveats, which is exactly the thing you cannot put in a regulatory filing.
With a replayable trail, you run one query. The export decision is in the decision log, and its record names the acting workload, the user it was acting for, the full delegation chain that got there, the policy version that allowed it, and the context at the time. You do not walk it back, because it was never broken apart. The chain from the export to the original user is a single joined record, and the question that took hours to half-answer becomes a lookup you can hand to legal with confidence.
The difference is not diligence or tooling budget. It is where the record was written. A trail assembled from the enforcement points after the fact inherits every gap between them. A trail written by the system that made each decision has no gaps, because the decision already held every fact the record needs.
Multi-party accountability
There is a harder version of the question that the sub-agent boundary forces, and it is worth naming because regulators are starting to. When agent A delegates to agent B, which calls a tool, which touches data, who is accountable for the outcome. The user who made the original request. The team that owns agent A. The team that owns agent B. The tool. In a chain, accountability is distributed, and a trail that collapses to a single service account makes it impossible to apportion. A trail that records the full chain lets you answer it, because every action ties back through named parties to the original principal.
This is not a theoretical concern for much longer. Mertens noted at EIC that regulators are beginning to ask for exactly this kind of provenance, and the direction of AI regulation is toward traceability and explainability of automated decisions. A preprint circulated in early 2026 scanned around two thousand public MCP servers and found that all of them lacked authentication, which is a single-author preprint and should be read as a signal rather than a settled figure, but the signal is consistent with what everyone building this is seeing. The plumbing to verify and record who is acting is mostly not there yet, and the audit trail is the first place that absence shows up.
The trail is a byproduct of the decision
The reason to be optimistic is structural. You do not build the audit trail separately from the authorization. If a policy decision is made at every hop, with the acting party and the principal and the context as inputs, then logging that decision is the audit trail. The same architecture that enforces per-hop authorization produces the replayable record for free, because the decision already had to know everything the record needs to contain. Programs that treat audit as a bolt-on end up with gaps at exactly the hops where enforcement was also weak. Programs that decide at every hop get the trail as a consequence.
How Cerbos fits
Cerbos makes the decision at each hop, and logs it. When a service or agent calls the Cerbos PDP to authorize a delegated request, the decision is recorded with the acting party, the user named as the subject, the delegation chain carried in the token, the policy version that decided, the context, and the outcome. Because the decision is made at every hop, the log has an entry at every hop, and because each entry carries the full chain, the on-behalf-of field that most implementations leave as a question mark is populated.
Cerbos Hub holds that unified decision log across services, agents, and tools, so an audit becomes a query against evidence you already have rather than an attempt to stitch together disconnected service logs after the fact. This is the same reason audit logs generated by the decision system beat logs assembled from the enforcement points afterward. The record is complete because the system that made the decision wrote it.
When the incident happens, the question is always the same. Who did this, on whose behalf, and under what authority. A chain that decides and logs at every hop can answer it from the log. A chain that trusts the edge and forwards tokens can only tell you a service account was involved, which is the answer that ends careers and loses cases.
Try Cerbos to see a unified, per-hop decision log for agent chains, or book a call to walk through your audit requirements with the team.
Go deeper:
- Securing agentic AI in production (webinar) for the full agent authorization and audit pattern
- The Authorization Maturity Model: A CISO's Benchmark (eBook) for where audit evidence fits in a program
FAQ
Tagged in
