The unanswerable question for every AI deployerCan I deploy this agent and still account for what it does?How do I know the controls held?

More: Why verification matters

Proof-of-Control verifies that an agent stayed inside the boundaries that were set. It covers evidence emitted at the moment of execution, for control-governed actions, across six domains: provenance, privacy, portability, authorization, identity, and security. Conforming evidence satisfies four criteria:

• Binary: The action stayed within bounds, or it did not.
• Contemporaneous: Generated at the moment of execution, never reconstructed afterward.
• Tamper-evident: The record cannot be altered without the alteration showing.
• Transparent: Explicit about its residual trust assumptions.

What it covers is what you declared. The evidence covers the control-governed actions in your declared scope, not every action an agent took (see question 8).

Verification is not validation.

More: C1 to C6 for the domains · C7 for the evidence properties

Proof-of-Control attaches at the action boundary, where policy controls are evaluated and tool calls execute. Every tool call and side-effect invocation must route through an Action Interception Gateway running as a separate process from the agent, with no bypass path: no network or credential route to its tools that goes around it (C7.1.1, Level 3). The gateway blocks out-of-scope actions rather than flagging them, and records the rejection (C4.1.3).

An assessor tests this requirement rather than assuming it holds. The no-bypass condition is the hardest part to meet, and the gateway’s own integrity is in scope too (C6).

Proof-of-Control turns the controls you already assert to counterparties from assertions into evidence, one at a time, in whatever order your risk says.

More: Where Proof-of-Control attaches · The gateway requirement, C7 · C9, the System surface · Appendix B, the per-layer mechanism inventory

Each of these answers a different question.

Formal verification establishes what a system can do, and interpretability reveals how it works. Proof-of-Control shows what an agent did. A system can be formally verified and have no Proof-of-Control, and the reverse.

ZKML, TEE attestation, and verifiable computation are mechanisms that can deliver Proof-of-Control. The standard defines the properties they must produce, not which one to use.

More: Where Proof-of-Control sits in the verifiable-AI landscape

Yes, whenever something depends on showing what your agents did (see question 8). Open verification is a property of the evidence, not a demand on your architecture: a closed proprietary model behind an API can produce openly verifiable evidence, and a fully open model can ship with none at all.

Open source means the model code was published for inspection, which shows nothing about what a specific deployment executed at runtime. An open-weights model on your own hardware can still make an unauthorized tool call, and its openness produces no record a counterparty can verify.

Local execution changes where inference occurs, not what an agent can reach. In July 2026, models being evaluated inside OpenAI’s own research environment chained vulnerabilities to reach Hugging Face’s production infrastructure and take the benchmark solutions from its database. OpenAI’s report traced it to reward hacking: over training, the models had become steadily more likely to probe their environment for weaknesses.

Four variables sit beneath the action boundary: runtime, weights, model code, and training data. Across all sixteen open and closed combinations, Proof-of-Control attaches at the Action Interception Gateway above the stack. Whether you can attach it yourself depends on who runs the orchestration loop:

• Self-orchestrated: If you control the agent loop and tool integrations, you can attach the gateway directly, at any of the sixteen.
• Managed vendor agent: If a vendor runs the orchestration loop, the evidence depends on that vendor conforming. That makes it a procurement question: can I verify it without trusting you.

A verifier learns whether a control held, without being shown what the action touched. What is public is the method: the specification, the validation algorithms, and the verification tooling. Evidence tokens carry cryptographic claims about control adherence, and omit raw prompt data, model weights, and underlying records.

The standard requires this in three places:

• Privacy-preserving provenance (C1.4): Where data is subject to minimization, provenance records retain digests, commitments, or redacted derivations, never raw payloads. An external verifier can confirm a claim about a confidential input without being shown it.
• Privacy-preserving verification (C2.3): Where Tier 3 evidence would re-leak protected inputs, the implementation substitutes a zero-knowledge proof, a selective disclosure, or a commitment, and an external verifier validates it without seeing the inputs.
• Evidence handling for protected data (C2.4): Retained evidence carries only derived forms, enforced by the pipeline schema rather than by convention, and the evidence store must never become a second copy of the data the domain protects. An auditor tests this by attempting to write a raw payload through the pipeline, which must fail.

What you disclose per domain is your decision, and it becomes visible in the disclosure of residual trust assumptions (C10.2). Metadata stays inferable: tool-call frequency and timing can be read from a record even when its contents cannot. The strongest privacy-preserving mechanisms are also the least mature, which is why Appendix B rates each one.

More: C2, Privacy · Appendix B, the proof-mechanism inventory

You need Proof-of-Control when something depends on showing, not saying, what your agents did.

The Verifiability Tiers match evidence strength to operational risk. Tiers 1 and 2 are cost-effective, and they are an intentional maturity on-ramp for low-stakes or internal tasks where taking the operator’s word makes business sense.

The bar rises when your risk profile hits these six triggers:

• High consequences: The action is hard to undo or carries severe financial or legal fallout upon failure.
• External reliance: An outside party, such as a counterparty, insurer, regulator, or court, must rely on the record.
• Boundary crossing: The agent leaves systems you control and operates in an external environment.
• Machine scale: Execution volume outpaces human review capacity, turning oversight into spot-checks.
• Highly regulated: Regulators require evidence of compliance, not assertions of it.
• Personal data: The systems run on sensitive personal data on behalf of people who cannot verify it for themselves.

When these triggers hit, Proof-of-Control applies from Tier 3, where you no longer take the word of the party vouching for the evidence:

• Tier 3 (Trust-minimized): Anyone can verify that the records were not altered after execution, without trusting the operator. Tier 3 guarantees that the records are intact, not that they are complete, and an agent could still act off-record.
• Tier 4 (Self-enforcing): Execution is gated: no proof, no write. An action behind a Tier 4 gate cannot execute without producing evidence, and for those actions the absence of evidence means the action did not happen.

Open verification works alongside the assurance you already have. A Tier 2 audit rests on the operator’s own record, and anchoring it in Tier 3 evidence gives the auditor something they did not have to take on anyone’s word.

More: C8, the Verifiability Tiers

Yes. The repository provides three complementary artifacts.

1 · Reference implementation: An open-source codebase demonstrating that the specification is implementable and making the claims in the text testable. You can run it in about a minute.

python3 schema/validate.py --vectors     # the published evidence test vectors
cd impl && python3 tests/test_core.py    # correctness tests
python3 attacks/run_attacks.py           # attack scenarios, with and without the requirement

It implements action interception, path-aware policy evaluation, hash-chained signed evidence, capability-bound dispatch, anchoring, gossip-based equivocation detection, and independent verification. It is a reference, not a product, and not something to deploy in production.

2 · Machine-readable claim set: The normative claim set in CDDL and JSON Schema, with canonical byte definitions, a CWT/CBOR profile, and signed test vectors. The reference implementation validates its own output against this schema in its test suite, and any drift between the two fails a test.

3 · The paper: Proof-of-Control: An Open Standard for Runtime Verifiability and Cryptographic Oversight in Autonomous AI Execution, carrying the theorems, the threat model, the measured results, and a section titled “What We Still Don’t Know.” It is a working draft under co-author review, and it has not yet been submitted.

The pipeline has been exercised in software and inside a real Intel TDX trust domain on GCP, with a matched non-confidential control.

The standard is in public comment until October 30, 2026, the reference implementation is being extended alongside it, and the specification is open for anyone to build against. It commits to conformance being demonstrated with running code rather than only asserted on paper, and a conformance test suite is the next artifact on the roadmap. If you are building against it, we want implementation reports, and we want to hear what breaks.

More: the reference implementation · the evidence claim set · the paper

Proof-of-Control is built on technology that already exists. Its primitives, from trusted execution environments to zero-knowledge proofs, are real, shipping code built by our members and by builders across the field. Security leaders and enterprise buyers work alongside them to define what evidence is required to trust an agent in the real world. Proof-of-Control brings that technology under a single open standard, so that vendors can deliver verifiable evidence without locking buyers in.

Cryptography is core to our members’ solutions, but the industry has had no shared standard of cryptographic verification for buyers. Open source was once in the same position: it was a disputed concept until the Open Source Initiative offered the Open Source Definition, and once the definition existed, a market formed on top of it.

More: the standard's own FAQ

Proof-of-Control changes what you are able to show.

• Evidence during execution: Proof-of-Control generates tamper-evident evidence at execution, verifiable by a party who does not have to trust you, whether or not a dispute ever arises. A contract, by comparison, gives you a legal right that you can exercise only with the cooperation of the party you would exercise it against.
• Accountability where prevention fails: Where a class of risk cannot be prevented, the record of what happened is the remaining control. The NSA’s May 2026 guidance on the Model Context Protocol says every tool and model invocation should be logged, with the exact parameters, the identities involved and, where feasible, cryptographic hashes of the results.
• Attribution for API and platform providers: For frontier labs and API providers, evidence generated at the boundary distinguishes an interface being invoked from what a downstream agent did with it.

Discovery: A tamper-evident record of what your agents did can also be produced against you, which is the same trade every organization already makes with access logs, transaction records, and email retention. The evidence covers the control-governed actions in your declared scope and shows whether a control held rather than what anyone intended, and you set retention periods as part of that scope. The alternative is a record you produced yourself, which is worth less in a dispute because it is worth less to everyone else.

What a court will conclude is still for the court: the evidence does not extinguish liability, decide fault, or judge whether the control you chose was adequate.

This section describes operational risk posture and is not legal advice.

More: Why verification matters

Proof-of-Control is the v1.0 working draft, open for public comment through October 30, 2026.

Normative chapters C1 to C10 are under version control in the repository. Open items are tagged [WG-INPUT NEEDED] and need contributors, including:

• Whether continuity across boundaries should join the four evidence properties as a fifth.
• Refining the overlap between identity and authorization.
• Defining operational requirements for the Continuously Monitored stage.
• Cryptographic and complexity-theoretic review of the binary threshold.
• Framework crosswalks that need a volunteer.

More: the full list of open issues · the roadmap · release and versioning policy

Individuals can join as a founding contributor (no cost).

(Google sign-in required)