The Problem
Three weeks ago, an enterprise ML platform team discovered they could not produce a regulatory audit trail for agent actions that would satisfy both their internal security review and external compliance audit. Their agents ran on MCP. Their compliance requirement came from NIST AI RMF. Their incident response team wanted proof of authorization chains. And they had no single format to hand to auditors that proved all three.
So they built one. In-house. Using a combination of external logging adapters, custom middleware, and manually maintained audit logs. It works. It also cannot interoperate with the next company's homegrown receipt system, or with the tooling the next protocol (A2A, ACP) might eventually ship. When that company's agent calls another company's agent—a scenario increasingly common in financial services and healthcare—the audit trail breaks. No one owns the receipt format. No one is coordinating around one.
This is a verification gap with teeth. NIST's AI Risk Management Framework, published in January 2025, requires that organizations "maintain continuous audit trails and logs of all agentic actions" and "formally classify agent capabilities and delegation authority." The framework does not specify a format. The three emerging agent protocols—MCP (Anthropic), A2A/AP2 (Google), and ACP (emerging standard backed by multiple vendors)—each treat audit logging differently. MCP has no native standard; teams add external logging layers, according to ByteBridge's Medium analysis and Red Hat's public guidance on MCP compliance. A2A added cryptographic receipts in its payment extension, AP2, but that format is scoped to settlement transactions, not authorization governance. ACP recognizes that "clear record of capability issuance and usage" is required (GitHub ACP Discussions #122) but has not published a receipt specification.
The market has noticed. Witness AI, a compliance monitoring vendor, ships audit logging for agents—but their format is proprietary to their platform. Teams that want to switch vendors or integrate multiple compliance systems face data lock-in. Regulators have not mandated a format, so teams do not have to converge. But the cost of not converging is growing: every new agent integration requires new audit adapter code; every cross-protocol delegation chain creates a gap in the trail; every compliance audit becomes a manual reconciliation task.
The stakes are not abstract. A regulatory agency auditing an agent that made a financial decision or a healthcare recommendation will ask for the receipt: proof of what the agent did, what it was authorized to do, and why it made that choice. If that receipt cannot be cryptographically verified, or if the format is unique to one company's internal system, the auditor will either reject it or demand manual documentation. For financial services and healthcare, that is a material compliance risk.
Why This Gap Exists
The gap persists because standardizing a receipt format requires solving three separate problems simultaneously—and the protocols are not yet coordinated enough to do it together.
First: technical complexity with no obvious correct answer. A receipt for an agent action is not a simple data structure. It must include what the agent did (the action or tool call), who authorized it (the delegation chain), with what constraints (scope, time window, revocation status), when it happened, and cryptographic proof that all of this is tamper-proof and can be verified offline. Different use cases weight these differently. A financial audit needs cryptographic signatures and a complete delegation chain. A healthcare compliance review needs the data inputs and model version. A security incident response team needs the exact call stack and environment. There is no single schema that satisfies all three equally well. This is why MCP dropped the problem: adding a mandatory receipt format to the protocol would mean choosing winners and losers among these use cases. Easier to leave it to the ecosystem.
Second: regulatory requirements are emerging faster than solutions. NIST AI RMF published audit requirements in January 2025. But NIST itself does not mandate a specific format; it leaves that to implementation. The SEC has not weighed in on agent audit requirements yet, but compliance teams are not waiting—they are reading NIST as a mandate and building compliance controls today. This creates a fog: vendors do not know if they should build for NIST, SEC, EU AI Act, or something else. So they build for their own system. A standardized receipt format would need to satisfy at least three major regulatory frameworks simultaneously, and those frameworks do not yet agree on what "adequate audit trail" means.
Third: no single protocol owns the problem space. MCP was designed for tool use within a single session; it does not assume delegation across protocol boundaries. A2A was designed for agent-to-agent communication; Google added AP2 (Agent Payments Protocol) to handle settlement, but payment receipts are not the same as action receipts. ACP is being positioned as a general-purpose agent capability protocol, but it is still in discussion phase on GitHub. No protocol team has claimed ownership of "standardized receipt format for cross-protocol delegation." Until one does, each team ships what makes sense for their scope—and the gaps stay.
Fourth: the compliance vendors have not yet coordinated around a standard. Witness AI generates audit logs. Other compliance platforms (Zenity, emerging tools in this space) do the same. But these vendors benefit from lock-in: if your audit trail is locked into their platform, you cannot easily switch. A standardized receipt format would be good for enterprises and regulators, but it would reduce switching costs for those enterprises. Vendors have weak incentives to standardize.
The closest the ecosystem has come to a common format is Google's AP2, which includes "cryptographic receipts and verifiable event logs" for payment settlement. But AP2 is scoped narrowly to agent payment transactions. It does not cover authorization governance, tool use verification, or capability delegation chains. It is also not yet published as a standard that other protocols can adopt.
What's Actually Happening Right Now
In the absence of a standard, practitioners are doing what practitioners always do when coordination is missing: they are building workarounds, fragmenting the solution space, and waiting for someone to solve it properly.
Custom receipt systems are emerging at the margins. Teams that need receipts are building them. Some are wrapping MCP with external logging adapters—middleware that sits between the agent and the protocol, captures every action, and writes it to a tamper-proof log. This works within a single organization's boundary but does not travel across protocol boundaries. Some teams are experimenting with embedding receipt data directly into MCP tool call responses, treating the receipt as just another part of the tool output. Others are building verification layers on top of MCP using external notarization services—sending action data to a third-party notary (like a blockchain timestamp service) to generate a cryptographic proof. None of these are standardized. None interoperate.
Compliance teams are writing custom adapters for each protocol. A financial services company using MCP needs an audit trail. They write an MCP compliance adapter. When they later add agents using A2A, they write another adapter. When they integrate with an ACP-based system, they write a third. Each adapter maps the protocol's native logging to their internal audit schema. Each one is hand-maintained. This is workable at three protocols. It becomes unsustainable at ten. And it becomes a risk: if the adapters do not all capture the same fields, audit coverage has blind spots.
Regulatory guidance is still vague enough that teams have room to interpret. NIST AI RMF says audit trails are required. It does not say what a receipt must contain or how to cryptographically verify it. This gives enterprises breathing room—they can implement what makes sense for their risk profile and claim compliance. But it also means there is no forcing function toward standardization. A regulatory mandate would immediately solve the coordination problem. Until that mandate exists, the incentive to standardize is weaker than the incentive to build something custom that works for your current system.
The protocols themselves are still discussing what the receipt should contain. GitHub issue #2404 in the MCP repository is explicitly titled "Proposal: Agent Identity and Delegation for MCP Tool Calls" and explicitly identifies delegation chains and verification mechanisms as open problems. The discussion thread shows that the MCP team recognizes the gap but has not yet settled on a solution that fits MCP's design philosophy (lightweight, single-session, tool-focused). ACP discussions on GitHub (issue #122) name audit trails as a requirement but do not yet include a published specification. Neither protocol team has committed to a standard that other protocols could adopt or build on.
The result is a widening gap between what regulators require and what tools provide. Teams are shipping production agents without a standard receipt format. Compliance reviews are happening against one-off audit systems. And the first time a regulatory agency specifically demands a standardized, cross-protocol agent receipt, the entire industry will scramble to retrofit the infrastructure.
The Build Opportunity
A team that ships a standardized receipt format—one that is protocol-agnostic, cryptographically verifiable, and satisfies NIST/SEC compliance requirements—owns a critical piece of agent infrastructure. Here is what needs to be built, where it lives, and why it is harder than it sounds.
What it needs to contain. A minimum viable agent receipt must include: (1) the action or tool call that was executed, with full parameters and context; (2) the delegation chain that authorized it (who called the agent, who called their caller, down to the human or automated source); (3) the scope constraints (what tools was the agent authorized to call, under what conditions); (4) the timestamp and cryptographic signature (proof that this receipt has not been tampered with since creation); (5) the agent's identity and version (which agent, which version of its model or logic, which set of capabilities); (6) the outcome (did it succeed, what did it return, any errors or side effects). Regulatory compliance requires that at least items 1, 2, 4, and 6 be present and verifiable. Technical incident response requires 5. Audit trails require all seven. A single schema needs to satisfy all three without forcing teams to carry unused fields.
Where it lives. This is not a change to MCP, A2A, or ACP themselves—those protocols will keep their current designs and will not agree to embed a mandatory receipt format. Instead, this is a receipt transport and verification layer that lives above the protocols. It is a standardized schema (probably a JSON or Protocol Buffer format with clear versioning), a set of cryptographic signing and verification routines, and a set of adapters that allow each protocol to generate receipts in the standard format. Think of it as "Protocol Buffer for agent audit trails"—a language-neutral, versioned, serializable format that can be generated by MCP agents, A2A agents, ACP agents, and legacy enterprise systems, and verified by any compliance platform.
Starting points and known hard problems. The closest existing work is Google's AP2 cryptographic receipts—the team building this should study that design and consider whether it can be generalized beyond payment settlement. There is also prior art in the security and cryptography communities around "verifiable event logs" and "tamper-proof audit trails" (e.g., Certificate Transparency, Trillian); a new agent receipt format could borrow cryptographic primitives from those systems. The known hard problems are: (1) balancing detail with brevity—receipts need enough information to satisfy auditors but not so much that they become unwieldy to store and transmit; (2) delegation chain representation—representing a chain of agents calling other agents, possibly across protocol boundaries, in a way that is unambiguous and cryptographically verifiable; (3) compatibility with existing compliance platforms—the receipt format needs to be translatable into audit log formats that Witness AI, Zenity, and other compliance vendors use, or those vendors need to commit to consuming the standard; (4) revocation and time-window semantics—if an agent's authorization is revoked mid-action, or if a delegation chain includes a time-limited grant, the receipt needs to capture that the action was compliant at the moment it executed even if it would not be compliant now.
Positioning for adoption. The builder has two strategic choices. Build as an independent standard (like OpenTelemetry for observability—a vendor-neutral schema that all protocols adopt) or build it as an extension to one of the existing protocols (embed it in ACP's emerging standard, make it an MCP RFC, extend A2A). The independent route has more adoption potential but higher coordination cost. The embedded route has faster initial adoption but locks the standard to one protocol's roadmap. Given that all three protocols are still evolving, the independent route is probably stronger—design the receipt format first, prove it works across multiple protocols, then pitch it to each protocol team as "your agents can generate standard receipts without modifying your protocol."