Proof-of-Control 1.0: An Open Standard for Verifying What AI Agents Actually Did

A v1.0 working draft standard, released by the Advanced AI Society in September 2026, that replaces vendor-asserted AI safety claims with cryptographic, third-party-verifiable evidence of what an AI agent did at runtime — while explicitly not certifying that the boundaries enforced were the right ones.

Created 2026-09-23 Last reviewed 2026-09-23

What it is

Proof-of-Control is a technical standard for producing tamper-evident evidence that an AI agent stayed within the operating boundaries it was given. It was published as a v1.0 working draft on September 17, 2026 by the Advanced AI Society, which simultaneously joined the Linux Foundation and LF Decentralized Trust to house the effort. The draft is open for public comment through October 30, 2026, and its normative chapters, reference implementation, and test vectors are published on GitHub under the LFDT-ProofOfControl repository.

The standard responds to what its authors call the “verifiability gap”: as AI agents are given more autonomy to call tools, move money, or access systems, the only account of what they did typically comes from the vendor operating the system being asked about. Proof-of-Control’s stated goal is to replace that self-reported log with cryptographic evidence generated at the moment of execution — evidence that is binary (the agent stayed in bounds or it did not), contemporaneous, tamper-evident, and independently checkable. The mechanism proposed is an “Action Interception Gateway” that sits between an agent and its tools, records every attempted action and whether it was permitted, and produces a signed record with no bypass path.

The standard organizes verification into four tiers, from Tier 1 (“assertion” — simply taking the operator’s word) up to Tier 4 (“self-enforcing,” where execution is cryptographically gated so that an unverified action cannot occur at all). Proof-of-Control’s authors argue that most current AI governance — including compliance with frameworks like SOC 2 or the NIST AI Risk Management Framework — operates at Tier 1 or 2, because the entity being audited still produces and holds its own evidence. Proof-of-Control targets Tiers 3 and 4.

Why it matters for AI governance and narratives

Proof-of-Control sits inside a broader shift in AI governance discourse, one the observatory has tracked across regulatory and industry framing: a move from asserted safeguards — policies, model cards, self-certifications — toward demonstrated ones, of the kind boards, regulators, and insurers can check without trusting the vendor’s word. That shift shows up in Spain’s AESIA guidance on EU AI Act compliance, in Microsoft’s public framing of “runtime governance,” and now in a dedicated open standard built by a coalition of security professionals rather than a single vendor or regulator.

The framing contest here is worth watching closely. Proof-of-Control is being positioned — including by its own materials — as infrastructure analogous to UL certification for electrical safety or SOC 2 for cloud software: a neutral, verifiable layer other institutions (insurers, regulators, courts) can build on. Its own documentation, however, contains an important qualification that the standard’s boosters and critics both cite: evidence that a control boundary held does not by itself establish that the boundary was the right one to set. A GitHub issue on the standard’s own repository makes a related point — that most current agent frameworks (LangGraph, AutoGen) don’t yet implement the provenance and pre-action policy checks that runtime verification assumes exist. This is a live methodological fault line, not a settled matter: the standard proves compliance with a chosen boundary, not the adequacy of that boundary’s design, and the two claims are easy to conflate in coverage or advocacy.

Key facts and dates

This is a young, pre-final standard from an industry coalition rather than a government body or an established standards organization like ISO or NIST; its claims about adoption and impact are, at this stage, aspirational rather than demonstrated.

Where to learn more

Sources

Primary source: the standard's own page, describing scope, verification tiers, and mechanisms
Primary source: governance structure, leadership, timeline, and standards ecosystem crosswalks
Technical analysis by a standard co-chair, corroborating the Tier 2/3 distinction and adequacy limitation
Referenced in: Editorial No. 337