An audit trail your agent can't tamper with
An agent runs overnight. By morning, a customer's production data is gone — the agent called a cleanup tool with the wrong scope and deleted records it was never meant to touch. The first question everyone asks is the simplest one: what exactly did it do, on whose authority, and with what inputs? You open the logs and find a single line — "maintenance task completed." Nothing about the destructive call. Nothing about who approved it. And no way to prove the log itself wasn't edited afterward.
This is the gap. Agents are taking real actions — deleting files, moving money, changing records — and the trail they leave is whatever they happened to write, in a place anyone with access can rewrite. When something goes wrong, "the agent did it" is not an answer your security team, your auditor, or your customer will accept.
Agent Receipts closes that gap. A separate daemon records a tamper-evident receipt for every tool call your agent makes. The signing keys and the receipt store live outside the agent process, so the audit trail holds up even if the agent is compromised.
Built for platform and security teams approving agentic deployments.
Start with a real agent workflow
Section titled “Start with a real agent workflow”If you want to try Agent Receipts in minutes, start with the MCP Proxy.
It sits in front of an MCP server you already use and gives you:
- Signed receipts for every tool call
- A tamper-evident audit chain
- Risk scoring and cryptographic receipts, without modifying the client or server
Best first paths
Section titled “Best first paths”What you will do
Section titled “What you will do”- Install the daemon and
mcp-proxy - Wrap one MCP server
- Make a few tool calls from your agent
- Inspect and verify the signed receipts
Conceptual overview. Signing and storage happen inside the agent-receipts daemon — the agent process sends events over a Unix socket and never touches the keys.
AI agents are increasingly acting on behalf of humans — sending emails, modifying documents, making purchases, managing files. Agent Receipts produces a tamper-evident record of those actions using the same Ed25519 and SHA-256 primitives the space already converged on, wrapped in the W3C Verifiable Credentials envelope — reusing standards, not authoring a new one. The EU AI Act mandates traceability for high-risk AI systems (Article 12); Agent Receipts produces a record that meets that bar. For how this fits alongside observability platforms, policy engines, and the other approaches teams are weighing, see the agent security tooling landscape.
What is an Agent Receipt?
Section titled “What is an Agent Receipt?”An Agent Receipt is a cryptographically signed record of a single action taken by an AI agent on behalf of a human. Each receipt is structured as a W3C Verifiable Credential with type AgentReceipt, signed with Ed25519, and hash-chained into a tamper-evident log.
Think of it as C2PA Content Credentials, but for agent actions instead of media assets. Where C2PA provides signed provenance manifests for photos, videos, and documents, Agent Receipts provide signed provenance records for things agents do.
What a receipt records
Section titled “What a receipt records”Every Agent Receipt captures:
- Who — the agent that acted and the human who authorized it
- What — the action type (from a standardized taxonomy) and its risk level
- When — timestamps, optionally backed by a trusted third-party timestamp authority
- Outcome — success, failure, or pending — and whether the action is reversible
- Chain position — a hash link to the previous receipt, forming a tamper-evident sequence
Parameters are hashed, not stored in plaintext. The operator controls what is disclosed. Sensitive data never appears in receipts.
Why the daemon matters
Section titled “Why the daemon matters”The signing keys and receipt store live in the agent-receipts daemon — a separate process that is the sole writer to the chain. The agent sends events over a Unix socket; keys and database handles never enter the agent process.
The daemon records caller peer credentials (pid, uid, executable path) at connect time — captured by the OS, not self-reported by the agent.
For the strongest tamper-evidence guarantee, deploy the daemon as a dedicated OS user so the key file is inaccessible to the agent's account. See Daemon Setup.
Design principles
Section titled “Design principles”The protocol is privacy-preserving by default, built on existing standards (W3C VCs, Ed25519, SHA-256, RFC 3161), agent-agnostic, and minimal by default with room for domain-specific extensions. See the Specification Overview for the full set of design principles.
Choose your next step
Section titled “Choose your next step”- Want the fastest hands-on experience? Start with the MCP Proxy overview.
- Want to create receipts directly in your app? Use the TypeScript SDK, Python SDK, or Go SDK.
- Want the protocol details first? Read the Specification Overview.