Platform Logs vs Independent Evidence
Updated
Every agent platform keeps logs, and for running your systems day to day they are the right tool. This page is about a different question: when someone outside your company has to rely on the record of what your AI agent did, why should they believe it? It is written for buyers, auditors and legal teams. Engineers can skip to the section for engineers near the end.
The short version
A log is a diary your system keeps about itself. An Asqav receipt is closer to a sealed, notarized copy. Once it is issued, anyone can check that its sealed contents have not been changed, without taking your word for it.
What "verifiable" means
Verifiable means a stranger can check the record for themselves. Think of the tamper-evident seal on a medicine bottle. You do not need to call the manufacturer to know whether the bottle was opened. The seal tells you.
A receipt works the same way. When your agent acts, a signing service separate from your system signs a description of the action together with the time it was signed. The signature is a mathematical seal over those exact contents. Change a single character of what was sealed and the seal no longer matches. An exported receipt also carries plain copies of a few fields for convenience, such as the agent and the time. Nothing seals those copies, so the check compares each one with the sealed value and fails the whole receipt if any of them differs. Whoever holds the receipt can check it on the public verify page, or run the open-source offline verifier on their own computer so the check does not depend on us. They do not need an Asqav account.
An ordinary application log has no seal. It is a file or a database table. Whoever runs the system can edit or delete entries later, and nothing visible to an outsider shows that it happened. That is normal for an operations tool. It also means a log only ever proves what its owner says it proves.
Logs and receipts side by side
| Ordinary logs | Asqav receipts | |
|---|---|---|
| Who writes it | Your own system | A separate signing service (Asqav's by default) seals it when the action is recorded |
| Who can change it later | Anyone with admin access, without a trace an outsider can see | Not without it showing. An edit to the sealed record fails the check, and each receipt points to the one before it, so one removed from the middle of a run leaves a gap the next receipt exposes |
| Who can check it | Only people with access to your systems, and they have to trust you | Anyone holding the receipt, with no account. The offline verifier does not need to contact us |
| What it shows an auditor | That you say these events happened | That this exact record existed when it was signed and has not changed since |
| In a dispute or after an incident | Your word against theirs | A record both sides can check the same way |
A dispute, told two ways
Your AI agent handles account changes for customers. A customer says the agent changed their settings on 3 March without permission. Your team says the agent only did what the customer asked.
With logs only. You export the matching rows from your own database and send them over. The customer's lawyer asks how anyone can know those rows were not edited after the complaint came in. You can say they were not. You cannot show it.
With Asqav receipts. You hand over the receipt for that action. Their expert checks it independently. From the sealed part they can read which agent acted and when it was signed, plus either the action details or a fingerprint of them, depending on how your system sends actions. If anyone had edited the sealed record after it was issued, the check would fail. The argument moves from whether the record is genuine to what the record says.
What a receipt does not prove
A receipt proves what was recorded and when. It does not prove that the agent described its action truthfully, or that every action was sent for signing. That depends on where the signing sits in your system, which Capture Topology explains. Auditors look for this limit, so we state it plainly.
Why this matters when you buy
Auditors can check sample records themselves instead of relying on screenshots and exports. What Your Auditor Will Ask For lists what they usually request.
Article 12 of the EU AI Act requires high-risk AI systems to support automatic recording of events over their lifetime. For most high-risk systems it applies from 2 December 2027. Receipts will not make you compliant on their own, but they give you records an outsider can check. See EU AI Act Article 12.
When a customer or partner challenges what an agent did, you can hand them a record they can test themselves. And after an incident, the sealed record in each receipt issued beforehand cannot be quietly rewritten, so you can check every receipt in the timeline you present.
Why a log on its own falls short
Strip away the product around it and a platform audit log has one structure: the party that runs the agents also writes the record, stores it and controls how long it is kept. An administrator with the right role can shorten the retention window, export a filtered view or delete entries. None of that is a flaw. It is what an operations log is for.
It does mean the log rests on your own say-so. Someone who trusts you learns a lot from it. Someone auditing you, or on the other side of a dispute, learns only that you say so.
For engineers: keep your platform, add receipts
Five properties make the check above possible:
- With the hosted signer, the record is signed server-side by an operator unaffiliated with the agent's operator, so the recorded party cannot forge or backdate its own record. Key custody is covered in Key Custody and Disclosure.
- The wire format is published as an IETF Internet-Draft, draft-marques-asqav-compliance-receipts, so a reader does not need the vendor's tooling to parse it.
- The verify key is public at
GET /.well-known/jwks.json, so the reader resolves the signing key themselves. - The standalone verifier (verify_receipt.py, Apache-2.0) is open source and runs offline, so verification routes through no one. It checks an exported receipt's signature and anchors against its payload. It also compares the plain copies beside the payload, such as the agent ID or the time, with the signed values, so an edited copy fails the verdict. Still take the agent and time from the payload. Independent Verification walks through the exact checks.
- Each receipt chains to its predecessor by SHA-256, so a record deleted from the middle of a chain leaves a broken link instead of silence. Removing the newest receipts does not break a link, so keep copies outside the system that produced them.
In United States federal litigation, Federal Rule of Evidence 902(14) lets data authenticated by a process of digital identification, such as a hash value comparison, be self-authenticating when a qualified person certifies the process. A receipt that carries the action's digests and an independently verifiable signature can support that kind of certification.
Asqav does not replace your agent platform's logging and does not ask you to move anything. It runs alongside, and there are three deployed paths in.
Sign actions at the call site. The SDK signs each agent action as it happens, in process. The receipt is independent of whatever else your platform records. Start at Agent Receipts.
Stream receipts into the tooling you already run. Asqav ships native output formatters for Splunk HEC and Datadog Logs on the webhook delivery path, so receipts land next to your existing platform events. See SIEM Streaming.
Attest an export after the fact. When the activity already happened and all you hold is the platform's export, you can still record the export's exact form at a point in time. Hash the export and sign an observation receipt over the digest:
import hashlib
export_bytes = open("agent-audit-export.json", "rb").read()
digest = "sha256:" + hashlib.sha256(export_bytes).hexdigest()
receipt = agent.sign(
"platform:log_export",
{"source": "agent-platform-audit-log", "window": "2026-06-01/2026-06-07"},
receipt_type="protectmcp:observation:result_bound",
result_digest=digest,
capture_topology="passive_telemetry",
)
print(receipt.signature_id)
That receipt proves the export existed in exactly that form at signing time and that no byte of it has changed since. With the default hosted signer, the signature on that claim comes from an operator that is not you. It does not prove the platform captured every action, and it does not prove nothing was edited before the export was taken. The capture_topology=passive_telemetry value states that limit inside the audit trail itself: the cloud rejects receipt types that would claim active enforcement from an after-the-fact vantage point, as described in Capture Topology.
An attested export turns "trust our log" into "the log you were shown is the log that existed on this date". That claim is narrower, and an outsider can check it.
Where to go next
- What Your Auditor Will Ask For: the concrete asks, mapped to what you hand over.
- Independent Verification: the offline checks a third party runs on a receipt.
- Verify a Receipt Without Asqav: a ten-minute walkthrough with no Asqav account.
- Key Custody and Disclosure: who holds which keys, and why that matters.
References
- Regulation (EU) 2024/1689 (EU AI Act), EUR-Lex
- draft-marques-asqav-compliance-receipts, IETF Datatracker
- Set up and use HTTP Event Collector, Splunk
- Logs API, Datadog