Autonomous Agents Need Proof, Not Promises
Every organisation running autonomous agents is about to hit the same wall. The agents will do real things: send emails, move money, mutate infrastructure, talk to customers. And when someone asks “what did your agents actually do, and can you prove it?” the honest answer is almost always a dashboard screenshot and a log file.
Logs are claims. Evidence is proof.
That gap is the reason we built WitnessOS, and this week it crossed a line worth writing about: E4 anchored receipts are now live in production. Externally timestamped, revocation-verified evidence for every governed agent action, re-verifiable offline by anyone with zero trust in the operator.
This post is the technical story: the evidence ladder, what E4 actually means, and why we think “anchored” is where agent governance stops being theatre.
The Problem: Agents Act, Nobody Can Prove It
AI agents are crossing from “chatbots that suggest” to “systems that act”. The moment an agent holds a credential and can execute, you have a new class of problem that is not about model quality at all:
- Did the action match policy? Was it authorised for the task, at the time, by the right principal?
- What actually happened? Not what the agent said happened, but what the destination received.
- Can you prove it later? Months after the fact, when a regulator, auditor, or customer asks.
Most agent platforms answer with claims: the agent’s own self-report, stored in its own log. That is the weakest possible evidence, because the agent has every incentive to be wrong and no cost for being so.
The Evidence Ladder
We built a grading model that makes the strength of evidence explicit, so nobody can confuse a self-report with a notarised record. Every receipt carries exactly one grade:
Grade Name What It Proves E0 Declared Agent self-reports the action. No independent observation. Trust-based. E1 Observed A sidecar or SDK witnessed the action. Gaps are possible. E2 Enforced Gateway authorised and routed the action. Policy enforced by a credential broker. E3 Corroborated Destination provider confirmed the outcome. External receipt or state probe. E4 Anchored Externally timestamped via TSA. Merkle-checkpointed. Independently verifiable.Most vendor dashboards never rise above E0. Auditors start asking questions at E2. E4 is the grade where the receipt stops depending on anyone’s word.
What E4 (Anchored) Actually Means
An E4 receipt is anchored to an external, independent time source. The mechanics matter, so here is what is happening under the hood:
- Policy evaluation happens first. The action is checked against the organisation’s published allowlist and policy pack before anything executes. No allowlist match, no execution, no receipt above the enforcement floor.
- The action is executed through a credential broker. The agent never holds the destination credential directly. Policy, approval, and audit hooks sit between the request and the execution.
- The evidence record is hash-chained. Every event in the case links to the previous one, so tampering with any link breaks the chain visibly.
- The case-head commitment is sent to an RFC 3161 TSA. A real timestamp authority returns a token that proves the record existed at a specific point in time, signed by an independent third party.
- Revocation is checked at issuance. The TSA’s certificate chain is validated against CRL/OCSP at generation time, not just trusted once.
- The receipt exports as a bundle. TSA token plus signed case-head commitment. Any third party can re-verify the whole thing offline, with zero trust in the operator.
That last point is the one that matters for adoption. The evidence does not live in our database. It lives in a bundle anyone can check with standard tooling. We do not need to be trusted for the receipts to be credible – which is exactly how it should be.
Why “Zero Trust in the Operator” Is the Whole Point
Every governance product can show you a pretty dashboard. The test is whether the evidence survives the operator being dishonest, compromised, or simply wrong.
An E4 export bundle survives that test, because:
- The TSA token is signed by an independent authority (RFC 3161), so the timestamp cannot be backdated by us or anyone else.
- The hash chain means any edit to the action history is detectable.
- Revocation checking at issuance means a compromised or expired anchor cannot silently vouch for new records.
- The verification runs on the verifier’s own machine, from the bundle alone. No API call back to us, no “trust our endpoint”.
Deployments that run without strict mode, or without a revocation-verifiable anchor, still cap at E3. The grade is earned by the configuration, not claimed by the vendor.
Not Just a Product: The Standards Layer
WitnessOS is the enforcement and evidence layer, but the vocabulary it speaks is open. We publish the specs so the formats are not a walled garden:
-
ACI – how organisations describe themselves to agents through machine-readable manifests:
github.com/narko4u/aci-spec·pip install aci-spec -
AJSON – the authoring format for manifests, policy bundles, and evidence schemas:
github.com/narko4u/ajson·pip install ajson-spec -
AIP – the protocol for agent-to-agent interaction, negotiation, settlement, and evidence:
github.com/narko4u/aip-spec·go install github.com/narko4u/aip-spec/cmd/aip@latest
The specs are open and the feedback windows are live. The engine itself is proprietary and available under NDA for evaluation – the honest split is documented in the repo’s NOTICE file, because we think “open core” should say clearly what is open and what is not.
Public repository: github.com/narko4u/witnessos – specification, evidence grade model, SDK, and a working demo.
What This Means for Teams Running Agents
If you are running autonomous agents in production, ask yourself three questions:
- What is the highest evidence grade you can produce today? If the answer is “E0 – the agent told us”, you have a governance gap.
- Could your evidence survive an adversarial review? Not a friendly one. A regulator, a customer dispute, an incident post-mortem.
- Does your operator need to be trusted? If your receipts only verify through your own API, then yes – and that is a liability, not a feature.
The gap between what agents do and what you can prove is the next compliance crisis. The good news is the tooling now exists to close it, and the evidence model is open for anyone to adopt.
WitnessOS is the runtime governance layer for autonomous agents: policy enforcement, credential brokering, and cryptographic evidence – with the ladder now reaching E4 anchored issuance in production.
Try the interactive demo: narko4u.github.io/witnessos/demo.html
Read the full specification: github.com/narko4u/witnessos
Enterprise evaluation: [email protected]
Security Division, Empire Labs
www.empirelabs.com.au