integrity
app logs
Application logs are mutable — anyone with write access can edit or delete them after the fact.
a2a receipts
Ed25519-signed receipts. Altering any signed field breaks verification.
receipts, not logs
An AI agent audit trail you can actually prove.
Application logs tell you what an agent supposedly did — and anyone with write access can change them. a2a cloud signs and persists receipts for Agent API calls and public `/invoke` or standard MCP `tools/call` executions. Formal A2A routes and connector MCP jobs are outside coverage; only Agent API paid calls receive linked economics.
individually signed · independently verifiable · inspectable history
0
signed execution entry points
0
mutable log lines
retention floor (days)
the problem
Your audit trail is not evidence until it's verifiable.
Most 'agent audit trails' are application logs: a stream of text the agent's own process writes, stored somewhere it — or an attacker — can edit or delete. When a regulator, a customer, or an incident review asks what the agent did and under whose authority, mutable logs don't answer it. You're asking them to trust the record kept by the party being audited.
Logs are mutable — no way to prove a line wasn't edited or removed after the fact.
Shared API keys mean the record rarely shows which authority permitted an action.
Reconstructing a past run for an incident review is manual, slow, and often impossible.
Most agents stall before production. The blocker is governance and proof, not model quality.
the a2a way
Runs on the API, MCP, and /invoke entry points, signed into verifiable evidence records.
A receipt is a first-class primitive on a2a cloud, not a logging add-on. It signs who called, which skill ran, input evidence, verified grant IDs, outcome evidence, and timing. Optional activity fields are not populated by the current sealers unless separately instrumented.
Signed, not loggedIndividually verifiableCaller + authority boundSigned event historyPer-tool timingVerifiable outside the process
Signed, not logged
The control plane signs and persists authenticated Agent API executions. Public `/invoke` and standard MCP `tools/call` responses include gateway-signed evidence. Connector MCP and formal A2A message/task routes are outside this skill-execution coverage.
Individually verifiable
Changing any signed receipt field breaks Ed25519 verification. Each receipt record is tamper-evident on its own; retention and inventory controls establish whether the overall record set is complete.
Caller + authority bound
Each receipt records the caller identity or conservative classification and any verified grant IDs supplied to the sealing path. Referenced grants carry the audience, TTL, and scope needed to review supported delegated authority.
Signed event history
When a replay session is separately created, it provides signed ordered history for timeline inspection. Gateway replay is a minimal transport timeline, not a full internal trace; deterministic re-execution still requires replay doubles and seeded randomness.
Per-tool timing
The receipt schema can hold optional tool-call entries when an instrumented sealing path supplies them, but the current Agent API and gateway sealers do not populate them by default. Economics remain separate and Agent API paid-call only.
Verifiable outside the process
A receipt is verified by a party outside the agent runtime. Your auditor checks the signature — they don't have to trust the process that produced it.
side-by-side
Mutable logs vs. signed receipts.
completeness
app logs
You can't prove a log line wasn't removed. Absence of evidence isn't evidence of absence.
a2a receipts
Receipt signatures prove individual records; retention and inventory controls establish completeness.
authority
app logs
Logs rarely capture which credential or scope authorized the action — usually a shared API key.
a2a receipts
Receipts record the caller and the grants that authorized it; referenced grants hold audience, TTL, file, and tool scope.
reproducibility
app logs
Re-running a past action means reconstructing state by hand, if at all.
a2a receipts
Inspect the signed ordered event history; deterministic reruns require replay doubles and seeded randomness.
evidence
app logs
“Trust our logs.” The party being audited controls the record.
a2a receipts
The verifier checks the signature independently of the runtime that produced it.
dimension
app logs
a2a receipts
integrity
Application logs are mutable — anyone with write access can edit or delete them after the fact.
Ed25519-signed receipts. Altering any signed field breaks verification.
completeness
You can't prove a log line wasn't removed. Absence of evidence isn't evidence of absence.
Receipt signatures prove individual records; retention and inventory controls establish completeness.
authority
Logs rarely capture which credential or scope authorized the action — usually a shared API key.
Receipts record the caller and the grants that authorized it; referenced grants hold audience, TTL, file, and tool scope.
reproducibility
Re-running a past action means reconstructing state by hand, if at all.
Inspect the signed ordered event history; deterministic reruns require replay doubles and seeded randomness.
evidence
“Trust our logs.” The party being audited controls the record.
The verifier checks the signature independently of the runtime that produced it.
questions
Frequently asked.
What is an AI agent audit trail?
A signed record of a run—caller identity or classification, skill, input evidence, the grants that authorized it, outcome or result preview, and timing. The control plane persists Agent API evidence; trusted public `/invoke` and standard MCP ingress persists and returns gateway evidence. Only Agent API paid calls have separate economics.
How is a signed receipt different from a log?
A log is text an application may later edit. A receipt is an individually Ed25519-signed execution record. Changing caller, skill, input hash or bounded preview, verified grant IDs, outcome/result preview, timing, or another populated signed field breaks verification. The signature does not prove that no separate receipt was deleted.
Can I prove what an AI agent actually did?
Yes, for Agent API calls and public `/invoke` or standard MCP `tools/call` executions. A third party can verify populated signed fields independently. Only Agent API paid calls have linked economics; gateway receipts record zero. Completeness still depends on retention and inventory controls.
Does this help with SOC 2 and the EU AI Act?
Signed receipts provide independently verifiable per-run evidence, and a2a cloud also exposes decision records and enforces a retention floor. A full SOC 2 or EU AI Act evidence story still needs retention, inventory, access, and organizational controls; the signature proves each receipt's contents, not the completeness of the collection.
What does non-repudiation mean for agents?
Non-repudiation means a signer cannot credibly deny the contents it signed. Each receipt can be verified against the configured Ed25519 verifying key, providing strong evidence that its execution fields have not changed since signing. Attribution still depends on protecting and governing the signing key.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Trust the receipt.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — with managed Postgres, MCP and API surfaces, and a frontend. The control plane signs authenticated Agent API calls; trusted ingress signs public /invoke and standard MCP tools/call executions. Connector MCP and formal A2A task routes are outside that coverage.