Agent action receipts are signed, verifiable records of every action an AI agent attempts, captured by an independent enforcement point outside the agent's own runtime. Because they are generated at the network egress boundary rather than inside the agent process, they cannot be altered, suppressed, or forged by a compromised or prompt-injected agent, making them trustworthy audit evidence for security and compliance teams.
What are agent action receipts?
An agent action receipt is a structured, cryptographically attested record describing a single outbound action: the agent identity, the destination, the tool name, the arguments, the decision (allow, block, or escalate), and a timestamp. Think of it as a notarized statement of what the agent tried to do and what your policy did about it. The key property is independence. The receipt is written by a system the agent does not control.
This matters because most teams today rely on logs the agent emits about itself. Those logs describe intent, not outcome, and an agent that has been manipulated by indirect prompt injection or a poisoned tool description will happily under-report. A verifiable agent audit trail has to be produced from a vantage point the agent cannot reach, which is exactly the egress path.
Why in-process logging fails as audit evidence
Application-level logging libraries run inside the same trust boundary as the agent. If the agent reasoning is hijacked, or a tool wrapper is swapped at runtime, the logging code is just as exploitable as the action code. There is no separation of duties. Auditors and incident responders need evidence that holds up when the system under question is the very thing producing the evidence.
Consider the practical failure modes:
- Suppression: a malicious instruction tells the agent to perform an action without logging it, and the in-process logger never fires.
- Forgery: the agent writes a plausible but false log entry claiming it called an approved endpoint when it actually called an attacker-controlled host.
- Gaps: a crash, retry, or exception path skips the logging call entirely, leaving the record incomplete.
- Mutability: logs land in a store the same workload can write to, so they can be edited after the fact.
Signed audit evidence for an AI agent solves all four by moving capture out-of-band and sealing each record so any change is detectable.
How does an action receipt get created on the wire?
When an agent makes any outbound call, that traffic crosses an egress proxy before it reaches the internet or an internal service. Agent G sits at that boundary and inspects the full request, including tool arguments and, where relevant, the response. At the moment a policy decision is made, the proxy mints a receipt. Here is the sequence:
- The agent issues an outbound request (an HTTP call, an MCP tool invocation, a DNS lookup, or a WebSocket frame).
- The proxy authenticates the agent identity and resolves the applicable policy.
- It inspects the destination, method, and arguments against your policy-as-code rules.
- It renders a decision: allow, block, or escalate to a human reviewer.
- It writes a structured receipt containing the request metadata, the decision, the policy version, and a content hash, then signs it.
- The receipt streams to your log sink while the request proceeds or is denied.
Because the proxy is the choke point, there is no action it does not see, and therefore no action without a receipt. This is the same enforcement surface described in our deep dives on default-deny egress allowlisting and blocking destructive agent actions.
What makes a receipt tamper-proof?
A tamper-proof agent log needs three guarantees: integrity, authenticity, and ordering. Agent G provides them as follows:
- Integrity: each receipt carries a hash of its own contents, so altering any field invalidates the hash.
- Authenticity: the receipt is signed by the proxy's key, proving it came from your enforcement layer and not the agent.
- Ordering: receipts are chained, each referencing the prior record's hash, so deletions or reordering break the chain and are immediately visible.
The result is an append-only, verifiable sequence. An auditor can replay the chain and confirm that no event was removed, inserted, or edited after capture. That is the difference between a log file and genuine audit evidence.
Action receipts vs ordinary agent logs
The phrase action receipts is becoming a marketing term across the agent security space, but most implementations still capture data from inside the agent. The distinction is not the format, it is the vantage point and the cryptographic sealing.
| Property | In-process agent logs | Agent G action receipts |
|---|---|---|
| Capture point | Inside the agent runtime | Independent egress proxy |
| Survives a compromised agent | No | Yes |
| Records actual destination | As reported by agent | As observed on the wire |
| Tamper detection | Rare | Hash-chained and signed |
| Includes policy decision | No | Yes (allow, block, escalate) |
| Usable as compliance artifact | Weak | Strong |
Receipts as both control and compliance artifact
An action receipt is not only forensic. The same record that proves what happened also encodes the control that governed it: which policy version applied, whether a human approved the action, and why a request was denied. That dual role is what makes receipts valuable to two audiences at once.
Security teams use receipts to reconstruct incidents and feed detection rules, as covered in our work on streaming logs into a SIEM. Compliance teams use the same receipts to demonstrate continuous control operation for frameworks such as SOC 2, ISO 42001, and the EU AI Act logging obligations. A signed receipt showing a human approved a high-risk wire transfer, paired with the policy that required that approval, is exactly the evidence an auditor wants. This pairs naturally with the approval gates described in our human-in-the-loop approval guide.
What belongs in a useful receipt
A receipt that is too thin is not auditable, and one that is too noisy is unusable. A practical schema for a verifiable agent audit trail includes:
- Agent identity: the non-human identity making the call, not just an IP.
- Destination: resolved host, port, and protocol observed on the wire.
- Action detail: tool or function name and inspected arguments, with secrets redacted.
- Decision: allow, block, or escalate, plus the matched policy rule and version.
- Human context: approver identity and timestamp when an action was escalated.
- Integrity fields: content hash, signature, and prior-receipt hash.
Argument-level detail is what separates a receipt from a netflow record. For Model Context Protocol traffic specifically, this depends on deep inspection of tool calls, which our MCP gateway performs inline.
Frequently Asked Questions
What is an agent action receipt?
An agent action receipt is a signed, structured record of a single outbound agent action, created by an independent enforcement point rather than the agent itself. It captures the agent identity, destination, tool arguments, and the allow, block, or escalate decision, producing tamper-proof audit evidence that survives even if the agent is compromised.
How are action receipts different from normal logs?
Normal logs are written inside the agent runtime, so a manipulated agent can suppress or falsify them. Action receipts are captured out-of-band at the egress boundary, record the destination actually observed on the wire, and are hash-chained and signed. That independence and cryptographic sealing make them admissible as genuine audit evidence.
Can action receipts satisfy compliance audits?
Yes. Because each receipt records the controlling policy version, the decision, and any human approval, it doubles as evidence that a control operated continuously. Receipts map directly to logging and oversight expectations in SOC 2, ISO 42001, NIST AI RMF, and the EU AI Act, giving auditors verifiable proof rather than self-reported claims.
Do action receipts slow down my agents?
No meaningfully. Agent G mints and signs receipts inline at the proxy as part of the same policy evaluation that already governs the request, adding negligible overhead. The receipt is written to your log sink asynchronously while the allowed request proceeds, so throughput stays effectively unchanged.
Conclusion
Self-reported logs were never going to survive a threat model where the agent itself can be turned against you. Agent action receipts solve that by producing signed, hash-chained, tamper-proof audit evidence from outside the agent's trust boundary, recording not just what the agent claimed but what actually crossed the wire and what your policy did about it. The same receipts serve incident response, detection engineering, and compliance at once. Explore how Agent G enforces and records every outbound action on our product overview, compare approaches on our alternatives page, and when you are ready to generate verifiable receipts for your own agents, request access to the Agent G private beta.