AI Agent Receipts for SOC 2 and ISO Evidence
Last updated: 2026-09-28
An execution receipt can strengthen an evidence package by showing what an execution layer recorded. It does not make an organization compliant, replace a control owner, or prove that a policy operated effectively. The useful question is which receipt fields support which review step, and which evidence must come from elsewhere.
Try the Zambo demo · Explore Zambo
Use the public receipt verifier to inspect a receipt when you have one. A receipt is evidence about a recorded execution, not a guarantee that an outside system accepted the result or that a human decision was correct.
Evidence is not a certification
SOC 2 and ISO 27001 assessments examine a system, its controls, its operation, and its evidence over a defined scope and period. A receipt is one evidence artifact. It can help a reviewer connect an automated action to a timestamp, tool, scope, and observed output. It cannot establish that the control design is adequate, that every relevant event was recorded, that access was approved, or that a control operated consistently. This page is a field mapping, not legal advice and not a compliance promise. A control owner must decide whether a receipt is relevant and sufficient for the particular assessment.
What AER-1 style fields provide
The core receipt fields are narrow by design. A stable id identifies the record. receipt_schema_version identifies the record format. created_at gives the recorded time. The tool object identifies the operation, version, and caller scope. provenance_class describes how the event entered the record. canonical_bytes preserve the exact committed representation, while output_hash allows an integrity check. verification_status reports the stated verification result. These fields support traceability and integrity review. They do not contain a complete access review, change approval, retention schedule, incident response record, or population completeness statement.
SOC 2 mapping table
The table below maps evidence use, not control satisfaction. A reviewer should attach the receipt to the control narrative only after confirming scope, ownership, retention, and completeness through the organization's evidence process.
ISO mapping table
ISO 27001 A.8.15 concerns logging. A receipt can be one structured log artifact for an AI execution, but it does not implement the whole logging control. The organization still needs to define what events are logged, who can access them, how records are protected, how clocks are managed, how retention works, and how review is performed.
Control evidence matrix
| Evidence question | Receipt field | What it supports | Gap to disclose |
|---|---|---|---|
| Can the reviewer identify one event? | id | A stable reference to one record. | It does not prove that all events were captured. |
| When was it recorded? | created_at | Temporal context for the record. | It does not prove clock governance or business-time correctness. |
| What operation and scope were recorded? | tool.name, tool.version, tool.scope | Review of the recorded operation and caller scope. | It does not prove approval, least privilege, or policy completeness. |
| How did the event enter the record? | provenance_class | Context for whether it was executed, observed, or reported. | It does not independently confirm an outside actor's statement. |
| Can the representation be checked? | canonical_bytes, output_hash | Integrity comparison for the committed bytes. | It does not prove the bytes were correct or complete. |
Completeness and population
A receipt proves the record that exists. It does not prove that every execution was captured. To support a population claim, pair receipts with the source system's event inventory, collection configuration, failure monitoring, and reconciliation procedure. If collection can be bypassed, the receipt is evidence of one path, not evidence that no other path occurred.
Integrity and access
The hash and canonical bytes support a narrow integrity check: the committed representation can be compared with the record presented for verification. They do not prove who accessed the record, whether an administrator could rewrite the storage layer, or whether the surrounding system had suitable key management. Pair them with access logs, storage controls, change records, and review evidence.
Retention and incident response
A receipt can make an incident timeline easier to inspect when it remains available and its timestamp is meaningful. It does not set a retention period or prove that the organization can retrieve all required records. For an incident process, preserve the receipt reference, retrieval result, investigator notes, and any system-of-record confirmation. Do not treat a missing receipt as proof that the event never happened.
How to write an honest control note
A useful note names the exact field and the limited claim it supports. For example: the created_at value and stable id let the reviewer locate one recorded execution in the stated period. The note should then list the missing evidence, such as population completeness or access review. Avoid phrases such as fully compliant, certified, or guaranteed. Precision makes the evidence easier to challenge and easier to trust.
A practical review workflow
Start with the control requirement and its owner. Identify the event or decision that needs evidence. Retrieve the receipt and verify its identifier, timestamp, tool, scope, provenance, bytes, and hash. Compare the observed result with the system that owns the outcome. Then attach supporting records for authorization, completeness, retention, access, and review. If any link is missing, record the gap. The public verifier at /verify can help with the receipt portion, but it cannot perform the organization's assessment.
What to do next
Use receipts as a consistent evidence unit for the narrow execution claim they actually cover. Keep the control narrative broader than the artifact. That approach avoids overclaiming while still giving reviewers a fast way to inspect an automated step. A mature evidence program may have many sources: receipts, system logs, approvals, configuration snapshots, tickets, and interviews. The receipt is valuable because it gives one of those sources a stable, integrity-checkable shape.
Review notes
Good evidence work starts with a bounded question. Name the action, the system that owns the result, the time window, and the person or service responsible for reviewing it. Then separate three states that are often collapsed into one: an action was requested, an execution layer recorded an action, and an outside system confirmed an outcome. The first state is intent. The second is execution evidence. The third is outcome evidence. A page that keeps these states separate is easier to use during an incident and harder to misuse in a status summary.
When evidence is incomplete, record the gap instead of filling it with confidence. A missing record may be a collection failure, a transport problem, a retention issue, or an action that never ran. Those possibilities have different owners and different remedies. Preserve the original record, the verification attempt, and the reviewer conclusion. If a later retry succeeds, keep the earlier attempt visible. This makes the evidence useful to someone who was not present when the work happened and gives the next operator a concrete place to start.
Reviewers should also write down assumptions. State which timestamp is authoritative, whether a result was observed directly, how a hash was computed, and which system owns the final state. If the answer depends on an external service, link the external evidence or mark it unavailable. If the action involved private data, describe the field class without copying the data into a public page. These habits turn a receipt from a decorative status badge into a durable review artifact. They also make disagreements productive: two reviewers can compare assumptions instead of arguing over a summary.
Finally, keep the evidence proportional to the decision. A low-risk read can use a light check, while a money movement, data mutation, deployment, or external communication deserves a stronger receipt and an independent state check. Do not use a larger word count or a more elaborate format to imply certainty. The relevant question is always what was recorded, what was verified, and what remains outside the record.
Frequently asked questions
Does an AI agent receipt prove SOC 2 compliance?
No. It is one possible evidence artifact for a recorded execution. It does not certify an organization or prove control effectiveness.
Can receipts satisfy ISO 27001 A.8.15 by themselves?
No. They may support a logging evidence package, while scope, completeness, access, retention, and review remain separate requirements.
Which receipt field supports traceability?
The stable id, created_at timestamp, tool object, and provenance_class together support review of one recorded event.
What gap should every mapping disclose?
A receipt does not prove that every relevant event was captured. Population completeness needs independent evidence.
Where can a receipt be checked?
A reviewer can use https://zambo.dev/verify for the receipt's verification step.