Who gives AI agents a tamper-evident work history?

A hash chain shows a change. It does not show who was able to make one. These six questions do.

• Who writes the record? The agent itself, a supervisor outside it, or an outside service. A record the agent writes about itself can leave out whatever it likes. The Agent Audit Trail draft puts it plainly: "An in-process signature demonstrates the transit integrity of a record but not recording honesty" (draft-sharif-agent-audit-trail).
• Is the identity signed, and checkable against a published key? A signature means something only when a stranger can fetch the public key from a place the operator cannot quietly change, and knows whose key it is: the agent's, the operator's or a service's.
• Is there an outside timestamp, witness or anchor, and what does it bound? Whoever runs the writer can rebuild a hash chain from scratch. A head held outside their control, where the reader can check it, makes that show: a witness's countersignature, an RFC 3161 timestamp, a transparency service or a public chain. Each one fixes history up to the last time it was used, and no further. As one draft says of its own format, "A log can be truncated at its end." (draft-sahu-agent-action-receipts).
• Can a stranger verify it without an account, without trusting the operator, and offline? Look for a verifier that runs on the reader's own machine, against files they hold and a key they fetched once. A check that runs on the operator's server is convenient; it is not the same thing.
• Does it record what the agent was allowed to do, as well as what it did? A log of actions with no mandate beside it answers "what happened" but not "was it allowed to".
• What does it never prove? None of these prove an agent was right, was safe, or reported everything. Halo Record's README says it in seven words: "no hash proves every action was captured" (Halo Record).

A published format anyone can implement, with a reference registry or toolset beside it.

Pick one of these when you want a format anyone can implement and check with no vendor in the loop. 1F916 suits an agent that wants a public, witnessed history under a key whose custody is on the record. Agent Receipts suits a team that wants a signed receipt for every tool call, written by a daemon on its own machines. In both, the reader still has to know whose key signed. 1F916 runs outside witnesses that countersign its heads; with Agent Receipts the outside timestamp is optional, and until one is added the operator is not bound by the chain.

You run the recorder. Your customer checks the file.

Pick Halo Record when you want the recorder inside your own code, with no dependencies and no vendor, and you can arrange a witness your customer has reason to trust. Its README is honest that a witness you run yourself commits history to you, not to your customer.

The record is written by the sandbox or the workflow engine, not by the agent.

Pick a runtime feature when your agents already run inside that runtime: the record comes with it, and it is written by the supervisor or the sidecar rather than the agent. Both keep the record on your own hosts under your own keys, so a buyer outside your company still relies on your copy unless you add an outside anchor.

Internet-Drafts are, in the IETF's own words, work in progress. Each one defines a format to implement; none of them runs anything.

Pick a draft when you are building your own recorder and want a format other people can check. A draft says what a good record looks like. Someone still has to run the writer, hold the keys and keep the witness. 1F916's own draft is in its row above.

The public chain is the witness. What it holds is identity, feedback and validation, not a log of every action.

Pick ERC-8004 when your agents already live on Ethereum or an L2 and the people checking them read the chain. It gives an agent a portable identity and a public trail of feedback and validation that cannot be deleted. On its own page it does not define a hash-chained log of each action an agent takes.

A service runs the writer and the check for you. The question to ask is what stops the service itself from rewriting history.

Often named in the same breath. They answer a different question: who is this agent, and what do others say about it?

Vouched Know Your Agent and KnowThat.ai are identity and reputation, not a signed work history, on the pages read. Vouched says that with its KYA-OS framework, "agents can prove who they represent", and lists "Maintain complete audit trails for security, compliance, and oversight." (Vouched Know Your Agent). KnowThat.ai, powered by Vouched, calls itself "A credit bureau for AI agents": "Operators report agent behavior. The registry aggregates trust." (KnowThat.ai).

Neither page describes the audit trail or the reputation record as signed, hash-chained, timestamped by an outside authority, or checkable by an outsider without trusting the registry. A product can do more than its marketing pages say, so check their documentation for your case. Pick one of them when the question is whether to let an agent in: whom it represents, whether it may act, and what other operators reported. Pair it with a work history when someone later asks what the agent actually did.

APIR gives every AI agent signed papers and a tamper-evident work history that buyers, auditors and insurers can check without trusting you.

• Who writes it. APIR's database writes each entry; the agent and its owner supply what goes in. For an agent APIR runs, database triggers write each registration, action, incident and containment event into its log book. For an agent that runs anywhere else, the agent sends what it did to POST https://apir.ai/api/v1/events with its API key, prompts and outputs as SHA-256 hashes made on its own side, and APIR writes each event into the chain. The owning organisation can also record events for its own agents. The log book is insert-only: the database refuses edits and entries are only added, and a deleted entry breaks the sequence and every link after it.
• Signed identity. Each agent's papers are signed with Ed25519 under did:web:apir.ai. The public keys are at /.well-known/jwks.json, and retired keys stay published so older papers still verify.
• What it was allowed to do. A mandate written by a named person at the agent's owner: the actions it may take, where, up to what value and until when. Anything not on it, it may not do. APIR signs it with its Ed25519 key. The free check shows the current mandate and whether it is signed; the mandate's signature bytes and its earlier versions are not yet published, and an owner can replace a mandate.
• An outside timestamp. Every night the heads of the agents' chains are combined into a Merkle root that an outside RFC 3161 authority (freeTSA) timestamps, so a later rewrite of anything before a stamp would no longer match it. For an agent with a public passport, anyone can fetch the token from the verify-black-box endpoint and check the stamp themselves, and an owner's free export carries the tokens too. The passport, the check, the resolve answer and the Evidence Pack do not carry them yet.
• Checking it. Free, with no account, at apir.ai/check-agent, by the agent's name, agent id or passport id: the signature on its Trust Passport is re-checked against the published key, its mandate is read back, and its log book's events are counted with the time of the last one. If the owner made the passport public, its page at apir.ai/verify-passport recomputes the log book's chain (links, content and sequence) on APIR's side every time it opens; a private passport gets no chain check for outsiders. A public passport's Ed25519 signature also checks offline against the published key, rebuilding the signed bytes from the canonical payload in the specification; that payload includes the owner's organisation ID, which the public envelope does not print, so ask the owner for it. A passport is issued at a score of 70 or more, and the check returns no record for an agent without one; an agent without enough evidence is Unrated, never given a made-up score. An Evidence Pack seals one agent's record behind a public link for a deal, a security review or a claim, AUD 499, one-time.

What APIR does not do, said plainly:

• APIR operates the writer and runs the chain check. A chain run by one operator is tamper-evident against everyone except that operator, which is why the nightly outside RFC 3161 timestamp matters: a rewrite of anything before a stamp would no longer match it. For an agent with a public passport, anyone can fetch the token from the verify-black-box endpoint and check the stamp themselves, and an owner's free export carries the tokens too. The passport, the check, the resolve answer and the Evidence Pack do not carry them yet.
• APIR's platform is not open source: its code is in no public repository, and it has published no standard. Its checker is open source: apir-record, MIT-licensed Python with no dependencies, rechecks an owner's export, a public agent's stamp and a seal with no APIR server in the loop. Also public is what any checker needs: the signing keys, the DID document, the specification of its record format, the free check, the offline seal checker and the API documentation.
• There is no public file of an agent's events to recompute offline, the way a 1F916 dossier or a Halo Record file can be checked: that takes the free export from the agent's owner. The log book's recompute runs on APIR's side when a public passport's page is opened: /verify-passport recomputes on every open, and /v/<agent-id> is refreshed at least every five minutes. A private passport gets no chain check for outsiders.
• The free check's answer carries no signature bytes. An offline signature check starts from a public passport's envelope and needs the owner's organisation ID, which the envelope does not print.
• APIR's public keys are published on APIR's own domain, at /.well-known/jwks.json and in the did:web:apir.ai document. A reader who wants a second channel has none yet beyond a copy they saved earlier.
• The entries are what the agent and its owner put on the record, whether the agent runs on APIR or anywhere else. The log book proves what was recorded and shows any later change, not that the record is complete: an agent that never sends an event leaves no entry.
• The database refuses edits and deletes, through triggers someone with owner rights could switch off. A deleted entry would break the sequence and every link after it. Deleting an agent that still has entries is refused.
• The mandate is written by the agent's owner. The record shows what the agent did beside it; it does not show whether the mandate was wise.
• APIR holds no SOC 2, ISO 27001 or penetration test report. It certifies no one, insures nothing and is not a compliance platform.

We don't promise results. We prove whatever happens.

It depends on who has to check the record, and whom they are willing to trust.

• You want a free, open protocol anyone can implement: 1F916 (a key bound to the agent, with its custody disclosed on the record) or Agent Receipts (in the recommended setup, a daemon outside the agent holds the key and signs every tool call).
• You want the recorder in your own code, with no vendor: Halo Record, plus a witness your customer has reason to trust.
• Your agents already run in a sandbox or a workflow engine: nono's supervisor audit log or Dapr workflow history signing (from 1.18). The record is written by the supervisor or the sidecar, not the agent.
• You are building your own recorder: start from a draft: draft-sharif-agent-audit-trail for a full set of fields, draft-sahu-agent-action-receipts for a small receipt that verifies offline, or draft-emirdag-scitt-ai-agent-execution for an independent custodian.
• Your agents live on a public chain: ERC-8004, for identity, feedback and validation.
• You need to decide whether to let an agent in: Know Your Agent from Vouched, or a reputation lookup at KnowThat.ai.
• A buyer, auditor or insurer has to check your agent's history without trusting you, and will not run code to do it: a 1F916 record, which the reader's browser re-checks against an outside witness copy; a Halo Record Runtime Report, which recomputes the chain in the browser; or a hosted record such as APIR (signed papers, a mandate and a log book, checked in a browser with no account, with the recompute run on APIR's side). Check an agent, free, or paper your first agent, free.

They combine. An agent can run inside nono and record with Halo Record or Agent Receipts; a buyer who wants one hosted place to check can also have its events sent to a service such as APIR.

Who gives AI agents a tamper-evident work history?

Six kinds of project, read on their own pages on 1 November 2026: open protocols (1F916, Agent Receipts), an open-source library (Halo Record), runtime features (nono's supervisor audit log, Dapr workflow history signing from 1.18), IETF Internet-Drafts (draft-sharif-agent-audit-trail, draft-sahu-agent-action-receipts, draft-emirdag-scitt-ai-agent-execution), an on-chain registry (ERC-8004) and hosted records such as APIR. APIR keeps Ed25519-signed papers, a mandate and a hash-chained log book for each agent, with the chain heads timestamped nightly by an outside RFC 3161 authority (the token is public for an agent with a public passport). Anyone checks an agent free at apir.ai/check-agent.

Is tamper-evident the same as impossible to change?

No. Tamper-evident means a change shows; it does not mean a change cannot be made. In a hash-chained log each entry carries the hash of the one before it, so editing, removing or reordering an entry breaks every hash after it. Whoever runs the writer could still rebuild the whole chain, and the newest entries can be dropped, which is why outside witnesses and RFC 3161 timestamps matter: they fix what the chain looked like at a moment someone else saw it. APIR calls its log book tamper-evident and uses no stronger word.

Can an AI agent write its own audit trail?

It can, but that record is only as honest as the agent. The Agent Audit Trail draft says a signature made inside the agent's own process shows the record was not changed in transit, not that it was recorded honestly, and asks for an independent recorder with its own key from trust level L2. nono's supervisor, Dapr's sidecar and the Agent Receipts daemon all write from outside the agent. With APIR, the entries are what the agent and its owner put on the record, wherever the agent runs, so its log book proves what was recorded and shows any later change, not that the record is complete.

How do I verify an AI agent's work history without trusting the vendor?

Check four things: the signature, against a public key you fetched yourself; the hash chain, recomputed on your own machine or by someone other than the vendor; an outside timestamp or witness on the chain head; and the mandate beside the actions. 1F916 dossiers, Halo Record files and draft-sahu receipts are built to verify offline. For APIR, open apir.ai/check-agent with no account. A public passport's Ed25519 signature also checks offline against apir.ai/.well-known/jwks.json, rebuilding the signed bytes from the canonical payload in the specification at apir.ai/agent-record-specification; you need the owner's organisation ID, which the public envelope does not print. APIR's log book recompute runs on APIR's side, and its timestamp tokens are public only for agents with a public passport.

Is APIR open source?

The checker is, the platform is not. apir-record, MIT-licensed Python with no dependencies at github.com/apir-ai/apir-record, rechecks an owner's export, a public agent's stamp and a seal with no APIR server in the loop. APIR's platform code is in no public repository, and it has published no standard. Also public is what any checker needs: the signing keys at apir.ai/.well-known/jwks.json, the DID document for did:web:apir.ai, the specification of its record format at apir.ai/agent-record-specification, the free check at apir.ai/check-agent, the offline seal checker at apir.ai/proof/verify-seal and the API documentation at apir.ai/docs. If you need an open-source record, 1F916, Halo Record, nono and Dapr are Apache-2.0 on their own pages, and Agent Receipts' code is Apache-2.0 with its specification under MIT.

Which work history do insurers and auditors accept?

No standard exists yet. The formats on this page are drafts, early versions or single projects, and APIR does not claim that any insurer, auditor or regulator accepts its record. Whether a record is accepted is for the person relying on it. What you can do is give them one they can check without trusting you, and say plainly what it does not prove. APIR gives no legal advice.

What is the difference between Know Your Agent and a work history?

Know Your Agent answers who an agent is and whom it represents, usually before you let it in. A work history answers what it did afterwards. On their own pages, Vouched's Know Your Agent and KnowThat.ai cover identity, delegation and reputation reported by operators. APIR's papers and mandate cover identity and authority, and its log book covers what the agent did.