AI Agent Audit Trail: What MCP and A2A Cannot Log

An MCP tool call leaves almost nothing behind. The protocol tells your agent what a tool does and how to call it. It does not define a record of who invoked it, on whose authority, with which arguments, or what came back. That gap is not an oversight in one implementation. A June 2026 gap analysis found it across five agent protocols, and the July MCP revision made the one partial answer weaker.

What can an MCP or A2A call actually prove afterwards?

An agent asked an MCP server to look up a customer. Six weeks later someone asks which customer records that agent touched in August, on whose behalf, and whether the answer it gave came from the record it says it read.

You can probably answer that from your application logs, if someone thought to write them. You cannot answer it from the protocol. MCP defines Tools, Resources and Prompts, and a request/response shape for invoking them. A2A defines Agent Cards, task delegation and message exchange. Neither defines an event record, an integrity guarantee, or a replay format.

What did the June 2026 gap analysis find?

In Governance Gaps in Agent Interoperability Protocols, published on arXiv on 30 June 2026, Richard Kang and Yudho Diponegoro tested five protocols against a six-dimension governance taxonomy: membership, deliberation, voting, dissent preservation, human escalation, and audit/replay. They scored each protocol dimension as Supported, Partial or Absent, on what the specification encodes rather than what could be built on top.

The matrix is bleak and consistent. Voting, dissent preservation and human escalation are Absent in all five protocols examined (MCP, A2A, ACP, ANP and ERC-8004). MCP scored 1 point out of a possible 12, A2A the same, ACP and ERC-8004 two each, ANP zero. The points that exist are partial credit: Agent Cards approximate membership, ACP's propose/accept/reject pattern approximates deliberation, ERC-8004 inherits tamper-evidence from its blockchain.

MCP's single point was for audit, and the authors were careful about why. They credited two things: sessions maintaining connection state, and tool calls producing structured responses with metadata. Then they wrote the sentence that matters: there is no tamper-evident event log, no hash chain and no replay guarantee, so audit depends on implementation, not on the specification.

The paper's conclusion is the part worth carrying into an architecture review. Governance is not a missing feature inside these protocols. It is a missing layer above them.

Why did the 2026-07-28 spec make MCP's audit story weaker?

Here is the part the paper could not have seen.

The paper assessed MCP against the November 2025 schema. On 28 July 2026 the 2026-07-28 specification shipped, and it retired the initialize/initialized handshake and the Mcp-Session-Id header outright. Every request now carries its own protocol version, client identity and capabilities in _meta, so any call can land on any server instance behind a round-robin load balancer. But one of the two constructs the paper credited for MCP's only governance point no longer exists.

In the same release, Roots, Sampling and Logging are deprecated under SEP-2577. They keep working for at least twelve months, and new implementations should not adopt them. MCP's logging utility was never an audit log: it is a diagnostic channel with no integrity guarantee and no retention semantics. But it was the only log-shaped primitive in the protocol, and it is now on a twelve-month clock.

So between the paper and the ink drying on the spec, MCP's audit coverage went from thin to thinner. Those four weeks are an argument for re-reading a specification-level analysis against the next release rather than citing it as a standing fact.

The same release handed the work somewhere else. Mcp-Method and Mcp-Name became mandatory on Streamable HTTP under SEP-2243, which is what lets an edge component route and meter without reading the body; we covered the migration mechanics separately. Authorization hardened too: RFC 9207 issuer validation, credentials bound to the issuer that minted them, and Dynamic Client Registration deprecated in favour of Client ID Metadata Documents.

Treat those headers as routing hints rather than as evidence. They are client-supplied, a stateless proxy has no schema to validate them against, and the spec requires a server to reject a request whose headers and body disagree. An edge decision on headers is a filter; the authorisation itself still belongs where the body is read. The Agentic AI Foundation's own Governance as Infrastructure note, published days after the spec, makes that point and goes further: the transport changes are governance primitives in infrastructure clothing, and the trace context is now the audit spine.

So MCP did not build an audit trail. It moved the audit trail out to the infrastructure, and the body that hosts MCP agrees that is where it belongs.

Does the Agentic AI Foundation change this?

Not on its own.

MCP, goose and AGENTS.md anchored the Linux Foundation's Agentic AI Foundation at launch. agentgateway, Solo.io's Rust proxy for MCP, A2A, LLM, HTTP and gRPC traffic, joined as a hosted project on 4 June 2026. A2A was accepted as a Growth Stage project in August 2026, backed by more than 150 organisations. On 14 September the foundation launched MCPA, the first MCP certification.

Neutral governance is good news if you worry about one vendor's roadmap. It adds no governance primitive to either protocol. What it does tell you is where the answer is expected to live: the foundation now hosts both the protocols and a gateway, and the gateway is where the policy, the authorisation and the access logging sit.

Which log does a Dutch SME actually owe today?

This is where most vendor writing on MCP gateways overreaches.

The EU AI Act's logging duties are narrower and later than the marketing suggests. Article 12 requires high-risk AI systems to allow automatic recording of events over the system's lifetime. Article 19 requires providers to keep those logs for at least six months. Both apply to high-risk systems only, and per Article 113 they come into force on 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I. A customer-service agent or an internal research assistant at a 30-person firm is almost certainly neither. If you are unsure which side of the line you sit on, our EU AI Act risk checker walks the Annex routes.

What does bite today is the AVG. Accountability under Article 5(2) means you must be able to demonstrate compliance, and you cannot demonstrate what you did not record. An agent that reads customer records through an MCP server is performing processing operations, and the register of processing activities under Article 30 has to describe them. The Commission has proposed raising the Article 30(5) exemption threshold from 250 to 750 employees under the Digital Omnibus, subject to financial criteria and a high-risk carve-out, but that is a proposal working through the legislature and not something to plan a 2026 architecture around. Accountability under Article 5(2) does not go away either way.

Then there is the trap. If your audit log records tool arguments and responses, and those contain personal data, the log is itself a processing operation with its own lawful basis, its own retention period and its own access control. Teams reach for "log everything" and quietly create a second, less governed copy of their customer database. The Dutch fiscal bewaarplicht pulls the other way for anything that is part of your administratie. Neither problem has a protocol answer.

What does an agent audit record have to contain?

Seven fields, and the protocol hands you one of them for free after July. The Agentic AI Foundation's own minimum record runs to eight; this is the cut for a firm that will never staff a platform team.

• Who asked. The human or system principal, not the service account the agent runs as. This is the field most implementations get wrong.
• Which agent. Agent identity and version, so a behaviour change can be attributed to a deployment.
• Which tool, on which server. Free from Mcp-Method and Mcp-Name at the gateway, provided you reconcile it against the body.
• With which arguments. Not free, and the field with the personal-data problem. Hash or redact by default; log in full only for the tool classes where you have decided you need it.
• What came back, or at minimum a hash of it, so you can later prove the answer matched the source.
• Under what authorisation. Which token, minted by which issuer, with which scopes. The RFC 9207 and issuer-binding changes make this recordable rather than guessable.
• When, in a sequence you can replay. A monotonic counter or a hash chain, because timestamps from three services do not order themselves.

Header-level logging gets you a usage record. Argument and response logging gets you an audit trail. Different products, different costs, different legal exposure: decide which one you are building before you turn anything on.

When is a gateway the right answer, and when is it over-engineering?

The enterprise pattern is settled: a gateway terminates and governs every agent-to-server call, and a registry records which servers exist and who may use them. Amazon, Microsoft, Kong and Solo.io all describe variants of the same shape, and for a firm running fifty MCP servers it is correct.

For a 20 to 50 person firm running three, it usually is not, yet. Our rule of thumb: put a gateway in when the third of these is true, not the first.

1. More than one agent uses the same MCP server, so per-agent logging inside the agent starts to disagree with itself.
2. A tool call can move money, send something to a customer, or write to a system of record.
3. Someone outside the build team, a controller, an auditor, a client's security questionnaire, needs an answer about what the agent did.

Below that, structured logging inside your own agent, written to somewhere append-only, is honest and sufficient. Above it, you are reimplementing a gateway badly. The failure mode we see most often at the 250 to 500 employee band is the opposite: a gateway bought early, logging headers only, presented internally as an audit trail it was never configured to be.

Put the decision in writing now. Retrofitting a record of who authorised what is the one thing you cannot do afterwards, and that question always arrives six weeks late. If you are scoping agent work and want the logging design settled before the build, that is what our AI agent development engagements start with, and the cost of a custom build is easier to judge once it is.

What this means if you are building on MCP this quarter

Three things, in order. Read the 2026-07-28 stateless changes against whatever your vendor has implemented, because a server still minting session identifiers is running last year's spec. Decide your seven fields and where they are written before the first tool ships, not after the first incident. And treat permissions and scoping as the same design conversation, because a log of an action nobody should have been able to take is evidence, not a control.

The protocols will probably close some of this. A2A's extension mechanism can express new state machines, and the gap paper notes that after more than six months of an active extension ecosystem, zero governance extensions had been proposed. Until one is, the layer is yours to build, and the honest version of that sentence is the one to put in your architecture document.

Last updated 22 September 2026.

Frequently asked questions