The Proof-of-Control Initiative

Proof-of-Control is a category of AI security technology that delivers independent, tamper-resistant, cryptographically verifiable evidence that AI systems operated within defined control boundaries.

It is a binary property. A system either generates this evidence or it doesn't. The evidence is produced by the cryptographic mechanism at the moment of execution, not reconstructed or narrated after the fact. It is checkable by anyone without relying on vendor attestation or contractual assurance.

The Verifiability Gap is the absence of independent evidence of what AI systems actually do. Enterprises cannot demonstrate to their boards what their AI systems did last quarter. Regulators cannot verify that high-risk AI operated within authorized parameters. Insurers cannot underwrite AI agent risk because there is no standardized evidence of agent behavior at runtime.

Logs can be fabricated. Vendor attestations are self-reported. Contractual assurances are promises, not evidence. Proof-of-Control closes this gap.

The technology already exists. Dozens of companies are building cryptographic verification for AI. But every vendor uses different names, different frameworks, and different claims. An enterprise that wants to verify what its AI agents did cannot compare providers, cannot specify what to buy, and cannot evaluate whether a vendor's claim is real.

No multi-stakeholder industry standard for cryptographic verifiability of AI agent behavior exists today. We confirmed this gap with the Linux Foundation, ISO, NIST, IEEE, and CEN/CENELEC.

Without a standard, any company can claim its AI is “verified” or “controlled” or “governed.” Without a standard, those claims are marketing. With a standard, they are testable.

In the late 1990s, anyone could call their software “open source.” The Open Source Initiative didn't build Linux. They defined what “open source” means, precisely enough that any claim could be independently evaluated. Once the definition existed, the label became trustworthy. Enterprise procurement could specify it. A $46 billion market followed.

The PoC Standard follows the same pattern used by every major security certification framework: FIPS 140, Common Criteria, CSA STAR, SLSA, PCI DSS, and C2PA. AAI Society is applying the proven architecture to a new domain.

Proof-of-Control applies across five domains, each defining a category of control boundary:

• Privacy — independently verifiable evidence of enforceable data boundaries and usage constraints
• Portability — independently verifiable evidence of continuity and control across vendors, platforms, and environments
• Verifiability — independently verifiable evidence of what actions occurred and how they propagated
• Security — independently verifiable evidence of system integrity and access control enforcement
• Identity — independently verifiable evidence of actors, agents, and delegated authority relationships

A sixth domain, Provenance (origin and lineage), is proposed for working group evaluation.

The standard defines three conformance levels that measure the rigor of evaluation, not the type of cryptographic architecture:

• Level 1: Self-Declared — the organization documents its cryptographic evidence capabilities and publishes a PoC Conformance Statement on the PoC Registry. Low barrier to entry.
• Level 2: Third-Party Assessed — an independent, qualified assessor validates that cryptographic mechanisms work as claimed.
• Level 3: Continuously Monitored — cryptographic evidence is generated and validated on an ongoing basis, not assessed at a point in time.

At every level, the implementation must disclose what trust assumptions remain in a standardized format.

No. The standard is technology-neutral. It defines the property (cryptographic evidence generated at execution time), not the mechanism. TEE-based solutions, ZK-proof systems, consensus timestamps, verifiable computation, and other approaches can all qualify. The standard requires that the evidence be independently verifiable, not that it use a specific technology.

SOC 2 certifies that controls exist and have been tested by an auditor. Proof-of-Controlcertifies that independently verifiable evidence of what the system did exists at the moment of execution. SOC 2 answers “Did the organization implement the controls it said it would?” Proof-of-Controlanswers “Did the AI system operate within its defined control boundaries, and can anyone check?”

They are complementary, not competitive. PoC addresses a gap SOC 2 was not designed to fill with AI Agents.

Binary means a system either has Proof-of-Controlor it doesn't. The threshold is the boundary between documentation-based assurance (logs, auditor reports, contractual promises) and cryptographic evidence (generated by a cryptographic mechanism at execution time, not narrated by the operator).

This matters because the category does not exist until buyers can ask a yes-or-no question. “Does your AI have Proof-of-Control?” is procurable. Every successful standard that created a category used a binary threshold: FIPS validated or not, CC certified or not, PCI compliant or not.

Confidential Computing (CC) is a mechanism. Proof-of-Control is a property. They are different categories.

CC protects data in use by processing it inside hardware-isolated Trusted Execution Environments (TEEs). The hardware creates an enclave that the cloud provider, the OS, and even the system administrator cannot access or tamper with. The key output is an attestation report: a hardware-signed certificate proving that specific code ran in an untampered environment on genuine hardware. CC solves a real problem, and several AAI Society members use TEE-based architectures.

Under the PoC Standard, TEE attestation is one valid cryptographic mechanism for delivering Proof-of-Control, primarily in the Security domain. But CC alone does not cover what the PoC Standard requires:

• CC doesn't cover Identity. A TEE can prove that code ran untampered. It cannot prove who authorized the agent to act, what delegation chain existed, or whether the agent was legitimately acting on behalf of a specific principal.
• CC doesn't cover Portability. CC protects execution within each environment. It does not produce evidence of continuity across boundaries when an agent moves between clouds or vendors.
• CC doesn't cover the full Verifiability domain. A TEE attestation proves the environment was secure. It does not produce a cryptographic record of what the agent did within that environment: which data it accessed, which APIs it called, which decisions it made. That requires cryptographic logging, consensus timestamps, or ZK proofs layered on top of the TEE.
• CC has no conformance framework for AI agent verification. No conformance levels, no assessment methodology, no insurance-ready architecture, no trust assumption disclosure standard.

The analogy: CC is to Proof-of-Controlwhat a deadbolt is to a home security standard. The deadbolt is real, it works, and you probably want one. But a security standard covers locks, alarms, cameras, monitoring, and assessment. The standard doesn't compete with the deadbolt. It gives the deadbolt a place in a system that can be evaluated, certified, and insured.

The Confidential Computing Consortium (a Linux Foundation project) is a natural standards body partner for the PoC Initiative. CC and PoC are complementary, not competitive.

Verifiable AI is an emerging category of AI security encompassing multiple technology layers, each verifying a different question. Understanding which layer does what prevents confusion about what the PoC Standard covers and what it doesn't.

• Cryptographic inference proofs (ZKML) verify that a specific model processed specific data. They answer: “Did I get the model I paid for?” Players include Modulus Labs, Ritual, and Giza.
• Confidential Computing (TEEs) verifies that code ran in a secure, isolated hardware environment. It answers: “Was my data protected from the infrastructure operator?” Players include NVIDIA, Microsoft Azure, Google Cloud, and Intel.
• Formal verification proves what a model is mathematically bounded to do. It answers: “Can I guarantee this system will never violate this property?” Players include Axiom, Harmonic, AWS Automated Reasoning, and Theorem.
• Mechanistic interpretability reveals what is happening inside the model when it makes a decision. It answers: “Why did the model produce this output?” Players include Goodfire and Anthropic's interpretability team.
• Content provenance (C2PA) verifies the origin and edit history of media content. Identity and credentials verify who authorized what. Governance architecture provides structural guardrails. Each is real, each is valuable, each answers a different question.

The Proof-of-Control Standard does not attempt to standardize all of these. It addresses one specific and critical question that no other standard currently answers: can you produce cryptographic evidence of what your AI system did at runtime, generated at the moment of execution, verifiable by any third party?

Two important boundaries:

Formal verification and mechanistic interpretability are pre-deployment and vendor-internal. They prove what a system can do. Proof-of-Control proves what it did do. A system can be formally verified and lack Proof-of-Control. A system can have Proof-of-Control and not be formally verified. They answer different questions for different stakeholders at different points in the lifecycle.

Cryptographic inference proofs, TEE attestation, consensus timestamps, and verifiable computation are mechanisms that can deliver Proof-of-Control. The standard defines the property those mechanisms must produce, not which mechanism to use. This is why the standard is technology-neutral: it specifies what the evidence must be (binary, contemporaneous, tamper-evident, transparent), not how to build it.

A robust AI governance posture may include formal verification for pre-deployment bounds, mechanistic interpretability for model understanding, and Proof-of-Control for runtime execution evidence. They are complementary layers of a maturing field. The PoC Standard addresses the layer no one else is standardizing.

Proof-of-Control delivers verification, not validation. It verifies that the system operated within defined control boundaries. It does not validate that the output was correct. This is a deliberate scope boundary.

Cryptographic mechanisms can verify that a model executed the authorized weights on authorized data within authorized parameters. They cannot guarantee that a specific output would be reproduced if the system ran again, because correctness for a stochastic system is a range, not a point. Whether the control boundaries were correctly defined is a human judgment that belongs to regulators, auditors, and governance boards.

Standards do not get adopted because the technology is better. CISOs have limited budgets, competing priorities, and no incentive to adopt a new standard unless something forces the question. Regulation is slow, jurisdiction-specific, and reactive. The EU AI Act does not specify which technical standard to use.

Insurance operates differently. An insurer who requires PoC conformance as a condition of AI liability coverage creates immediate commercial pressure. The CISO does not need to be convinced the technology is better. The CFO tells them the company cannot get coverage without it. This is how SOC 2 became mandatory for SaaS, not through regulation, but through the insurance and procurement chain.

AI governance frameworks document policies, processes, and organizational controls. They describe intent. Proof-of-Controlprovides cryptographic evidence of execution. You may have the right policies in place, but if a regulator, insurer, or board asks “what did your AI system actually do last quarter?” your governance framework cannot answer that question. Proof-of-Control can.

Companies at all stages of control maturity belong in the AAI Society ecosystem. The standard recognizes three stages, from documentation-based evidence (Stage 1) through independently auditable systems (Stage 2) to cryptographically verifiable evidence (Stage 3). The standard defines Stage 3. Companies at Stages 1 and 2 have a clear path forward.

The PoC Standard specification will be freely available under a permissive license (CC BY 4.0 or equivalent). This is not incidental. It is the most consequential adoption decision in the entire initiative.

The parallel to open source runs deeper than analogy. In the 1990s, the open source movement established a principle: source code should be inspectable by anyone, not controlled by a single vendor. That principle created a $46 billion market because buyers could trust what they were getting. Independent verifiability of the code replaced vendor trust.

Proof-of-Control applies the same principle to AI execution. The evidence of what AI systems did should be verifiable by anyone, not controlled by the vendor that operates the system. Independent verifiability of behavior replaces vendor trust. The philosophical foundation is identical: transparency and independent verification as the basis for trust, rather than institutional authority.

The structural lesson from open source is equally important. Every standard that achieved rapid adoption made its specification freely available: OWASP, SLSA, C2PA, PCI DSS. Every standard that restricted access slowed its own adoption. Apple's $1/port royalty killed FireWire against royalty-free USB. The specification must be free. Revenue comes from certification, training, membership, and the registry, not from restricting access to the definition itself.

Open source proved that openness and commercial success are not in tension. The Linux kernel is free. Red Hat built a $34 billion business on it. The PoC Standard is free. The ecosystem of certification, assessment, implementation, and insurance built on top of it is where the value flows.

For funders, this matters for two reasons. First, an open standard maximizes adoption speed, which maximizes the standard's impact on AI accountability. Second, an open standard cannot be captured by a single vendor or jurisdiction. It belongs to the ecosystem. That is what makes it durable.

This is the question at the core of why the standard exists.

A technical standard might seem like an unlikely vehicle for protecting human agency. But history shows otherwise. Open source is the precedent. In the 1990s, a licensing definition and a set of criteria for what “open source” means did more to protect developer freedom, user choice, and innovation than any policy declaration or ethical framework. Before the standard, vendors controlled the code and users had no way to verify what they were running. After the standard, users could inspect, modify, and redistribute. The technical definition created the structural conditions for agency. The Open Source Initiative didn't write code. They wrote a definition. That definition changed who had power.

Proof-of-Control follows the same logic for AI. The technical definition of what constitutes cryptographic evidence of AI behavior creates the structural conditions for human oversight. Without the standard, vendors control the evidence and users have no way to verify what their AI systems did. With the standard, any party can check.

As AI agents take on more autonomous action, the risk is not just that they act badly. The risk is that humans lose the ability to know what happened, and therefore lose the ability to govern. When the evidence of what an AI system did is controlled by the system's operator, when it exists only as vendor-provided logs that cannot be independently checked, human oversight becomes ceremonial. You can have a governance board, a compliance framework, and an ethics policy, but if you cannot independently verify what the system actually did, you are exercising authority without evidence. That is not agency. That is faith.

Proof-of-Control restores the evidentiary foundation that makes human oversight meaningful.

Three specific mechanisms protect human agency:

• The verification-not-validation scope boundary. The standard deliberately does not automate judgment. It verifies that AI systems operated within the control boundaries that humans defined. Whether those boundaries were the right ones remains a human decision. The standard provides the evidence; humans provide the judgment. This keeps the human permanently in the role of the decision-maker, not the spectator.
• Trust assumption disclosure. Every PoC-conformant implementation must declare, in a standardized format, what must still be trusted by humans. No implementation eliminates all trust. The standard requires that residual trust be visible, so humans can make informed decisions about which systems to deploy, which vendors to trust, and which risks to accept. Hiding trust assumptions from the humans who bear the consequences is the opposite of agency.
• The three-stage structure. Not every company needs to deliver cryptographic evidence today. But every company should be moving toward greater transparency about what their AI systems do. The three stages (documentation, independent audit, cryptographic verification) create a path where human oversight becomes progressively more informed and less dependent on vendor goodwill.

The deeper point: in a world where AI agents execute transactions, move data, and make decisions at speeds humans cannot match, the question is not whether humans remain “in the loop” in real time. They cannot. The question is whether humans retain the ability to verify, after the fact, what happened, and to hold systems accountable based on independent evidence. That is what human agency means in an AI-driven world. Proof-of-Control is the infrastructure that makes it possible.

Open source proved that a technical definition can redistribute power. The PoC Standard is designed to do the same: ensure that the evidence of what AI does belongs to the people affected by it, not to the vendors that operate it.

AAI Society is a 501(c)(6) industry association. The Proof-of-ControlStandard is owned by the Advanced AI Foundation, AAI Society's affiliated 501(c)(3), which ensures it remains a public good — neutral, freely available, and free from commercial capture. AAI Society administers the initiative on behalf of the Foundation.

The standard specification is freely available under a CC BY-ND 4.0 license. This means anyone can use it and build on it; modifications to the specification itself require permission, which protects the integrity of the standard against fragmentation. This is consistent with how durable standards operate: the specification is free, the ecosystem around it generates value.

AAI Society's revenue comes from membership dues paid by companies building and deploying Proof-of-Controltechnology. Membership funds the convening, the initiative, and the ecosystem — not the standard itself.

The initiative operates through five layers. Co-chairs Ken Huang and Tricia Wang lead the initiative and steward the standard through development. The leadership team works asynchronously on drafting documents. The Distinguished Review Board provides senior technical review to ensure credibility with cryptographers and standards bodies. Founding members shape the standard through feedback and working group participation. Industry working groups, organized by sector, produce use cases that validate the standard against real deployments.

Partners extend the standard's reach beyond AAI Society's membership. Standards body partners provide technical alignment and regulatory credibility. Vertical industry partners bring domain expertise and distribution into priority sectors. Implementation partners carry the standard into the field and provide real-world feedback that strengthens future versions.

The resulting standard is owned by the Advanced AI Foundation and made freely available to the public. AAI Society administers the process; the Foundation holds the asset in trust for the field.

Founding members shape the standard through input, not attendance. The leadership team meets twice monthly and handles drafting. Founding members receive working drafts for review and comment, participate in working group discussions when relevant to their expertise, and weigh in on key decisions (properties, domains, conformance levels). There is no mandatory meeting schedule. The architecture document is designed for asynchronous input: leave comments directly in the document, flag disagreements, propose changes.

The initiative has three partner categories.

• Standards body partners contribute technical alignment and help the PoC Standard map to existing frameworks and regulatory requirements.
• Vertical industry partners bring sector expertise and help validate the standard against real deployment contexts.
• Implementation partners (consulting firms and systems integrators) will be the ones helping enterprises assess, adopt, and deploy Proof-of-Control, and their field experience directly strengthens future versions of the standard.

Partners are not required to be AAI Society members. The relationship is structured around mutual value: you extend the standard's reach and credibility, the standard creates a new service line and client conversation for your organization. Contact us to discuss which partner category fits.

Complete the founding member interest form →

Or email hi@advancedaisociety.org to start the conversation.