A practitioner sent us a question this weekend that we could not answer with a clean yes.
An autonomous agent performs an action under valid delegated authority. Months later, the action is disputed. A correction is issued. The policy that governed it is replaced. The authority it acted under is revoked. The evidence for every one of those events still exists somewhere.
Can you produce one record that shows exactly what authority applied when the agent acted, and everything that has happened to that action since — and can someone who does not trust you verify it?
We sign every governed decision. We record the policy version and a digest of the delegation chain. We thought we were close. When we checked our own system against the scenario, we were not.
Every agent action governed by EVE can now produce a single signed record: the authority that applied at the time, re-derived rather than asserted, and every later revocation, dispute, correction and policy change. It is anchored in the public Sigstore transparency log. Its verifier recomputes the conclusions instead of trusting them. You can test it yourself at the end of this post.
What we found in our own system
Here is what was true until this week, stated plainly because it is the useful part.
Edits overwrote history. A delegation grant — alice may let the treasury agent move up to $50,000 — lived in one database row. Changing the grant replaced the row. Our decision record carried a hash of the delegation chain as it stood when the agent acted, but once the row changed, nobody could show what that hash had been computed from. We could prove a chain hashed to a value. We could not say which chain.
Revocation had no memory. Revoking a delegation flipped a flag. No timestamp, no author, no reason. And a bug we had not noticed: re-submitting a revoked grant quietly switched it back on and erased the revocation.
Disputes and corrections had nowhere to live. Nothing in the system tied a later event to the action it concerned.
So the honest answer to the question was: someone would have had to reconstruct the story from logs, and some of the inputs they needed were already gone. That is exactly the failure mode we warned about in our last post — a signal that looks like evidence until you ask it the question you actually care about.
What “without trusting the vendor” actually requires
The practitioner’s follow-up was the better question: if the party examining the history cannot trust the vendor that produced it, what evidence is sufficient? Our answer was five things, and the vendor’s signature on its own counts for close to none of them.
- Reproducible interpretation. The record carries its inputs, and the verifier re-runs the same deterministic logic and gets the same result. A conclusion that cannot be recomputed is testimony, not evidence.
- Proof of when, fixed outside the vendor. The log’s state is committed to something the vendor cannot rewrite, close to the moment of the action.
- Completeness, not just integrity. Showing an event is in the log is easy. Showing nothing about the action was left out is the hard part.
- Events signed by their authors. A dispute is signed by whoever raised it. If the vendor writes every entry, the vendor decides what happened.
- Keys known before the event. The verifier needs to know the signing key was public before the records it signed.
We told the practitioner that CoreGuard met the first one, partly met the fifth, and did not meet the other three. Then we went and built them.
How each requirement is enforced now
An append-only history
Every change to authority — a grant, an edit, a revocation, a certificate revocation, a dispute, a correction, a superseded policy — is appended to a per-tenant, hash-chained log. Nothing is edited in place. The database role the application runs as can insert and read that table, and cannot update or delete it. A revoked delegation is now terminal: re-submitting it is refused.
Authority that is re-derived, not asserted
To answer “what authority applied when the agent acted,” EVE rebuilds the delegation graph exactly as it stood at the decision time and re-runs the same resolver the live system used. If the result hashes to the digest the decision recorded at the time, the record says VERIFIED and includes the exact grants. If it does not, it says MISMATCH. If no history covers that moment, it says UNRECONSTRUCTABLE rather than guessing.
The offline verifier does not take that label on trust. It recomputes the chain digest from the grants in the record and checks it against the decision. It also verifies the original decision certificate embedded in the record, and recomputes the summary fields a reader looks at first — disputed, corrected, revoked since, valid when decided — from the events themselves. A record re-signed with any of those changed fails verification.
Anchored in a public transparency log
Every few minutes, EVE publishes a signed checkpoint of each tenant’s history — its length and latest hash — to Sigstore’s public Rekor log. Rekor returns a signed timestamp proving that checkpoint existed at that moment. The verifier checks the timestamp offline against Rekor’s public key, which is pinned rather than fetched alongside the receipt.
Each record includes the anchors that fall on its chain, and the verifier checks the chain passes through every anchored head. If we rewrote history after an anchor was published, the rewritten chain would no longer pass through it.
Complete, not just intact
A record carries every event from before the decision up to a signed checkpoint — including events about other actions, redacted so that neither their contents, nor who made them, nor which records they touched is exposed. The verifier can only test identifiers it already knows. The verifier checks the chain links end to end and confirms that every event concerning this action is present. Dropping a dispute fails. Starting the proof after the dispute fails. Moving the recorded decision time past the dispute fails.
Signed by the people who assert them
Disputes, corrections and policy supersessions must carry a signature from the author’s own key — a key registered to the tenant, which must sign its own registration. (EVE’s own records are signed separately, with ECDSA P-384 keys held in AWS KMS.) Delegators can sign their own grants and revocations; the verifier checks the signed terms match the grant that was recorded and reports whether each event was signed by the delegator or recorded by EVE alone.
Keys announced first
EVE’s signing key is itself published to Rekor before any checkpoint is anchored, and the verifier reports when each key used in a record became public. A checkpoint is never timestamped ahead of the key that signed it.
The bug that had been hiding in plain sight
The first time we switched external witnessing on, earlier this month, every submission to Rekor failed. We turned it back off without learning why. This week we found out.
Rekor rejected each entry because it expected a different hash algorithm for that key type.
Rekor accepts an Ed25519 hashedrekord entry only as Ed25519ph — the pre-hashed variant over SHA-512. The widely used Python cryptography library implements plain Ed25519 and not Ed25519ph, so there is no small fix that keeps the same key type. We moved the witness to ECDSA P-256 over SHA-256, which Rekor supports directly.
If you are wiring Ed25519 into Sigstore from Python and Rekor keeps refusing your entries, that is why — and ECDSA P-256 is the path of least resistance.
Test it yourself
We built a live demo so anyone can check this without an account. It loads a signed record for a synthetic scenario straight from production. An agent sends a wire under authority delegated by alice; alice later revokes the delegation; the beneficiary’s bank disputes the payment; alice issues a correction; the governing policy is superseded. Alice’s grant and every event after it are signed by their authors, with registered keys.
On that page you can:
- see the authority the agent acted under at that moment, and where it stands now;
- verify the record with one click;
- try to change it — hide the dispute, erase the revocation, raise the spending limit — and watch each edited copy fail;
- check both public log entries, EVE’s key announcement and the record’s anchor, directly against Sigstore’s public log, with your browser talking to Sigstore rather than to us;
- download the record and keep it.
Changing a byte breaks our signature, which you would expect. The stronger property is what happens when the vendor itself re-signs a doctored record with its real key. Hiding the dispute, trimming the chain, moving the decision time, or inflating a spending limit all still fail, because the verifier recomputes those conclusions rather than reading them. Those are the cases our test suite checks.
What it does not do yet
In the same spirit as the rest of this post:
- The record is signed with our key, and the verification endpoint is ours. The Rekor anchors and their timestamps can be checked with no involvement from us. A standalone open verifier is the next step.
- Delegator signatures on grants and revocations are opt-in per deployment. Our admin console cannot sign yet, so they are not required by default. Every record states which events were signed by their author and which were recorded by EVE alone.
- History starts at deployment. Actions decided before this shipped report UNRECONSTRUCTABLE rather than a reconstructed guess.
- A record only contains what was recorded. A dispute that nobody enters is not in it.
- Anchoring runs on an interval and uses Sigstore’s public-good instance, which carries no availability guarantee. Each record reports how many of its events are not yet anchored.
Why this matters beyond us
Agents are acquiring authority faster than organizations are building the machinery to account for it — the gap we described in AI Has Entered the Org Chart. Most of the attention goes to the moment of decision: should this action be allowed? That matters. But the questions that end up in front of an auditor, a regulator, a counterparty or a court are usually asked months later, about an action whose context has since changed.
Answering them should not depend on how carefully the vendor kept its logs, or on whether you trust the vendor at all. It should come down to a record you can check.
We are grateful to the practitioner who asked the question that showed us we could not do that yet.
Frequently asked questions
What is a verifiable action history for an AI agent?
It is a single signed record for one agent action that shows the authority in force when the action happened and every later event affecting that action, such as a revocation of the delegation, a dispute, a correction or a superseded policy. It is verifiable when a third party can check it without trusting the system that produced it.
Why is a signed audit log not enough?
A signature proves the vendor produced a record and that it has not changed since. It does not prove the vendor recorded everything, recorded it at the time, or interpreted it correctly. Those need external timestamps, completeness proofs, recomputable conclusions and events signed by the parties who asserted them.
How does EVE prove what authority applied at the time of an action?
EVE keeps every delegation change in an append-only, hash-chained history. For a given action it rebuilds the delegation graph as it stood at the decision time, re-runs the same resolver, and checks the result against the digest the decision recorded. The verifier repeats the digest computation from the grants included in the record.
What does anchoring in Sigstore Rekor add?
Rekor is a public, append-only transparency log. Publishing signed checkpoints of the history to it gives an externally held timestamp for the history’s state. A history rewritten after a checkpoint was published no longer matches that checkpoint, and the mismatch is detectable without trusting EVE.
Why did Rekor reject Ed25519 witness signatures, and why use P-256 instead?
Rekor accepts Ed25519 for hashedrekord entries only as Ed25519ph, the pre-hashed variant over SHA-512, and returns “unsupported hash algorithm: SHA-256 not in [SHA-512]” otherwise. The Python cryptography library does not implement Ed25519ph, so we sign Rekor entries with ECDSA P-256 over SHA-256 instead.