Proof-of-Control v1 Draft Demands Tamper-Evident Proof of What Agents Actually Did

On September 23, 2026, Advanced AI Society and LF Decentralized Trust opened the Proof-of-Control v1.0 working draft for public comment, defining openly verifiable evidence that AI agents stayed inside assigned controls.

Conceptual illustration of cryptographic evidence tokens flowing from an AI agent gateway
Conceptual illustration of cryptographic evidence tokens flowing from an AI agent gateway

Advanced AI Society and the Linux Foundation Decentralized Trust community used a September 23, 2026 webinar—“Who’s Watching the Machines?”—to put the Proof-of-Control v1.0 working draft into public comment through October 30, 2026. The draft is framed as an open verification standard: not another questionnaire about what an agent should do, but a catalogue of requirements for tamper-evident evidence of what it did—which data it touched, which authority it exercised, which tools it invoked—in a form a third party can check without trusting the operator’s logs.

The problem statement on the Advanced AI Society Proof-of-Control page is blunt. Agents already rewrite environments, poison their own memory, and mint identities for other agents faster than human review scales. Operator-written logs are produced by the system under investigation. Policies state intent without producing a contemporaneous record of behavior. Contracts assign liability after the fact but do not create evidence that can travel to a buyer, insurer, regulator, or auditor without privileged access. Proof-of-Control’s answer is a shared evidence format that those parties can all verify from the same record.

Normatively, the draft organizes six domains of verification: provenance, privacy, portability, authorization, identity, and security. Evidence that conforms is supposed to be binary (in bounds or not), contemporaneous with execution, tamper-evident, and explicit about residual trust assumptions. The standard also introduces verifiability tiers that grade who must be trusted: Tier 1 assertion (the operator’s word), Tier 2 attestation (an auditor with privileged access), Tier 3 trust-minimized (anyone can verify the mechanism), and Tier 4 self-enforcing (execution gated so that no proof means no write). Proof-of-Control is described as attaching meaningfully at Tiers 3–4. Formal verification, ZKML, TEEs, and interpretability are treated as complementary mechanisms that can implement those properties, not substitutes for a runtime action record.

Attachment point matters for agent builders. The FAQ states that Proof-of-Control hooks at the action boundary—where policy is evaluated and tool calls execute—through an Action Interception Gateway that runs as a separate process from the agent, with no bypass path for network or credentials around it. Out-of-scope calls are blocked and recorded rather than merely flagged. That design language will be familiar to teams already running MCP gateways or agent policy engines; the standard’s claim is that enforcement alone is not enough if the only evidence is still an operator-controlled log that a compromised step can rewrite.

Linux Foundation Decentralized Trust Labs lists the effort as an approved lab—“Open Verification: Proof-of-Control”—with scope covering the six domains, a Trustworthiness in Agents Matrix, a working definition of the evidence properties, and eventual conformance mappings to frameworks such as NIST AI RMF, ISO/IEC 42001, CSA MAESTRO, and OWASP. The Advanced AI Society site says a reference implementation, machine-readable claim schemas, and a working paper accompany the draft, with public comment open until October 30 and a locked 1.0 target called out for Feb 1 2027 in related materials. Organizational membership and a Distinguished Review Board (including enterprise security leaders quoted on the project page) sit alongside the technical working group.

The insurance and procurement angles are not marketing asides. The project page describes a Proof-of-Control Insurance Working Group aimed at turning runtime evidence into underwritable risk, and it contrasts today’s questionnaire-and-self-claim posture with tamper-evident records produced at execution. That matters because agents complicate classic assurance: SOC 2 samples organizational process after the fact, while an agent may issue thousands of tool calls in a week. Proof-of-Control’s claimed contribution is machine-verifiable evidence at the volume agents actually generate, without forcing every counterparty to invent a private assessment format. Crosswalks listed on the site and lab page deliberately sit beside—not above—threat models such as MITRE ATLAS, control catalogs such as NIST AI RMF and ISO/IEC 42001, and runtime enforcement patterns such as CSA’s agentic action models. The standard’s authors argue those layers answer different questions; Proof-of-Control answers whether the controls you already claim can be shown to have held for a specific action at a specific time.

For Writeble’s agent desk, this is not a model drop and not a CVE. It is infrastructure for the claim that open source’s inspectability ethos has to move from source trees to runtime actions once agents become non-deterministic actors. Teams shipping coding agents, MCP servers, or multi-agent workflows will eventually meet buyers who ask a sharper procurement question than “do you have a policy?”: can an outsider verify that yesterday’s tool calls stayed inside the controls you declared, without taking your word for it. The September 23 draft is the first widely socialized attempt to make that question answerable with a shared, open catalogue rather than a private audit theater.

Topics
  • #AI Agents
  • #Open Standards
  • #Governance
Raj M

Author

Raj M

Contributor

AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.