What Evidence Should an AI Agent Leave Behind? A New Draft

When an AI agent does something it should not have, the first question a customer, an insurer or an auditor asks is what it actually did. The honest answer today is usually a log written by the same system that ran the agent. A draft standard called Proof-of-Control, published in the open on GitHub and open for public comment until October 30, 2026, sets out what evidence an agent should leave behind so that the answer can be checked by someone who does not have to take the operator's word for it.

This post is for a founder, technology lead or operations lead who runs agents with tool access and will be asked that question. It explains the draft without its vocabulary, gives the four-rung ladder it uses to grade evidence, turns its six domains into six plain questions, and lists what a business can do this quarter without waiting for a standard to settle. The facts are from the draft's repository and the steward's website, both read on September 19, 2026. Every claim about adoption, membership and review is the alliance's own.

A person who makes a mistake at work leaves evidence other people hold: an email in someone else's inbox, a change in a system they do not administer, a colleague who saw it. An agent running inside a company's own stack often leaves evidence only in logs that the same stack produces and can alter. The alliance behind the draft puts it bluntly on its site: the entity being watched is writing its own report card, and a compromised step can rewrite it afterwards. We saw the practical version of this in September's report of agents faking their own logs, and the incident-response version in our post on which logs to keep.

The draft's answer is not better logging. It is a change in who has to be trusted for the record to count. Its definition, in the repository's words, is a catalogue of verifiable requirements for open, tamper-evident evidence of what an agent actually did, "in a form anyone can verify without trusting the operator". That last clause is the whole idea.

The repository was created on August 5, 2026 and is stewarded by the Advanced AI Society, a nonprofit alliance that describes itself as bringing together more than 80 security leaders and the founders of companies building verifiable AI. The standard is co-chaired by Ken Huang and Tricia Wang, reviewed by a board the site lists as including Bruce Schneier, Michelle Dennedy and AstraZeneca's Charles Iheagwara, and the repository says a Proof-of-Control Lab is being established as a community lab at Linux Foundation Decentralized Trust. Its style is modelled on the OWASP application security verification standards: every requirement is meant to be verifiable, testable and implementable, and each section ends with what an auditor should collect.

Two version facts matter for anyone citing it. Until September 17 the repository's badge read Working Draft v0.1.4 under a Creative Commons licence. On September 19 the front page was relabelled "v1.0" for the public-comment launch and the licence corrected to Apache 2.0. The released 1.0 that locks the text is targeted for February 1, 2027. So "v1.0" today means the draft under comment, not a finished standard, and the requirement count, 127, is the draft's.

The draft grades evidence not by how much cryptography it uses but by who has to be believed. The repository is explicit that cryptography alone does not raise the tier; removing the trusted party does. The one-page summary carries the whole ladder in one phrase: trust me, trust my auditor, trust the maths, the leash locks itself. A system has Proof-of-Control at Tier 3 or 4 and not below, which is what makes it a yes-or-no question a buyer can put in a contract.

Most deployed agents sit on Tier 1 by the draft's own account: system prompts, safety filters and operator-held logs. A SOC 2 or ISO 42001 report is Tier 2, which the draft calls necessary and not sufficient, because a badge issued months ago cannot prove what happened today. Tier 3 is a mechanism, such as a signed hash chain of intercepted actions, that outsiders can verify with published tooling. Tier 4 adds that the system cannot act at all unless its integrity checks hold. The oversight-coverage metrics Anthropic proposed this week, which we covered in our post on its three numbers, are an operator-reported, Tier 1 measure of the same concern.

Chapters C1 to C6 say what must be verified. Chapters C7 to C10 say what the evidence must be, how it is graded, where in an agent stack it sits, and how a claim of conformance is checked and disclosed. The six domains reduce to six questions a non-specialist would ask after an incident.

The cross-cutting chapters contain the parts most likely to change how agents are built. C7 requires an interception gateway that emits evidence for every action rather than a log the agent appends to. C10 requires a conformant system to disclose its trust assumptions, so that two systems that both pass can still be priced differently. And the draft is careful about what it is not: not a judgment of whether the agent's outputs were right, not a governance framework, and not runtime enforcement, which it leaves to a companion standard.

Nobody should re-architect an agent around a draft under public comment. But the draft's Level 1 and Level 2 requirements describe evidence a team can produce now, and each maps to work we have already written up.

1. Put the logs outside the agent's reach. Append-only storage the agent's credentials cannot write to or delete from, with a hash chain if you can manage it. That alone moves you from an editable record to a tamper-evident one.
2. Record every tool call at a gateway, not in the agent’s own code. The draft’s central mechanism is interception at the action boundary; a proxy that sees every request the agent makes to a tool is the minimum version.
3. Write down the authority for each action. What was the agent allowed to do, who granted it, and did the action fall inside it? This is the C4 question, and it is what our post on workflows that break rules step by step found missing in most stacks.
4. Put agent and principal identity on every event. Which agent, acting for which person or team. Our agent identity playbook covers the credentials side, and our census of which agents act as you and which as themselves shows how far the market is from doing this consistently.

Do those four and an auditor can at least confirm the record was not altered, which is the draft's Level 2. Getting to Level 3 means someone outside the company can verify it with published tools, and that is where the standard, once settled, earns its place. If you want the first four built into an agent you are already running, our AI transformation service treats them as part of the base build.

The repository is public and anyone can open an issue or a pull request without being a member; the README asks for an issue before any large change and says normative changes go to a working group and then the review board. Comments filed before October 30, 2026 receive a published disposition: accepted, rejected with reasons, or deferred. The alliance also keeps a shared document for comments and lists membership as open to any organisation.

Three things are openly unsettled. The repository's Appendix D collects every decision still marked as needing working-group input. The alliance's site names delegation chains as an open problem: three agents deep, each hop within bounds, and no one able to say who authorised the last step. And the README's own coverage figures against other frameworks come with a warning that they are single-coder estimates with a known upward bias, which is the kind of caveat a draft should carry and a finished standard should not need.