Advanced AI Society Proof-of-Control Opens a New Front in Agent Security

Advanced AI Society released Proof-of-Control for public review on September 17, despite unresolved questions about the draft’s version, scope, and readiness. The proposed standard asks AI agents to produce tamper-evident evidence showing that each controlled action stayed within its authorized boundaries. It also shifts agent security away from trusting a vendor’s private logs.

That shift matters because agents are moving beyond generating text. They can call tools, access records, change software, communicate with outside services, and initiate transactions. A quarterly audit cannot observe each decision as it happens, while a log controlled by the agent’s operator may offer limited independent assurance.

Advanced AI Society says more than 80 security leaders helped shape its approach. The group is placing the work inside Linux Foundation Decentralized Trust, which gives the project a neutral venue for technical governance. However, neutral governance does not make a draft complete, nor does cryptographic evidence guarantee that an organization selected the right controls.

Congress is approaching the same problem from another direction. A bipartisan House proposal would direct NIST to develop agent security practices covering continuous verification, security evaluation, inventories, and tamper-resistant records. The collision between voluntary open standards and government-backed requirements creates the real story.

Advanced AI Society Proof-of-Control Is More Than a Membership Announcement

The important change is the release of an inspectable agent verification proposal, not the membership headline surrounding it.

Advanced AI Society described its September announcement as joining the Linux Foundation and LF Decentralized Trust. Yet Linux Foundation records show that the organization became an LF Decentralized Trust associate member on April 21, 2026. The newer announcement therefore combines an earlier membership development with the public presentation of Proof-of-Control and its associated lab.

That distinction matters. Membership places an organization within a collaborative network, but it does not validate every claim or technical design that the organization publishes. The consequential action is bringing a proposed verification standard into a foundation environment where outside contributors can inspect, challenge, and extend it.

The April membership record identifies Advanced AI Society as one of two new associate members. The September launch notice introduces Proof-of-Control as an LF Decentralized Trust lab and invites public comments.

Proof-of-Control is designed around a direct question: can an independent party verify that an AI agent remained within its assigned controls? A control might prevent an agent from moving money without approval, restrict which customer records it can access, or limit the tools available during a task.

The proposal focuses on the action boundary, which is the point where an agent attempts to call a tool or create an external effect. Its architecture places a separate interception gateway at that boundary. The gateway evaluates the proposed action, blocks actions outside the declared policy, and emits evidence about the decision.

That design is more specific than conventional promises about responsible AI. It describes where enforcement occurs, what evidence should be produced, and how another party might verify that evidence. Advanced AI Society also identifies six verification domains: provenance, privacy, portability, authorization, identity, and security.

The framework’s central idea is that an agent’s runtime log remains a claim when the same operator controls both execution and recordkeeping. A compromised system could omit an action, rewrite a record, or route around logging. A useful verification mechanism must therefore expose alterations and identify the assumptions on which its evidence depends.

The project proposes multiple assurance tiers. Lower tiers depend on operator assertions or an auditor’s access. Higher tiers seek independently verifiable records or execution gates that prevent a controlled action without corresponding evidence.

This creates a meaningful distinction between observing an action and constraining it. A tamper-evident record can help investigators establish what was recorded after an incident. A correctly implemented execution gate can prevent a covered action when its authorization conditions fail.

Proof-of-Control does not claim to determine whether the underlying model is safe, accurate, or aligned. It also does not decide whether a company granted an agent too much authority. It tries to establish whether declared controls governed the actions included within a stated scope.

That narrower objective is a strength because it gives implementers something testable. It is also the source of the project’s biggest limitation. Evidence that an agent followed a weak policy only proves compliance with that weak policy.

Congress Is Turning Agent Verification Into a Procurement Question

Agent security is moving from a technical preference toward a condition for doing business with regulated buyers and the federal government.

The proposed Stop Rogue AI Act would direct the National Institute of Standards and Technology to publish standards, guidelines, and best practices for secure agent deployment. According to reported bill details, the work would cover continuous agent inventories, security evaluations, tamper-resistant logs, and verification of agent actions.

The proposal comes from Representatives Josh Gottheimer, a New Jersey Democrat, and Mike Lawler, a New York Republican. Most organizations would use the resulting NIST practices voluntarily. Federal contractors competing for new work would face stronger pressure to meet them.

That mechanism matters more than a broad regulatory declaration. Procurement requirements can influence technology markets without imposing one mandatory architecture on every private organization. Vendors often adopt government-facing controls across their products because maintaining separate security systems increases cost and complexity.

NIST was already working on the field before the House proposal emerged. In February, the agency announced an agent standards initiative covering interoperability, identity, authorization, and security. It also sought input from deployers, developers, researchers, and infrastructure providers.

The overlap with Proof-of-Control is clear. Both efforts focus on persistent identity, defined authority, observable actions, and evidence that survives outside the agent’s own narrative. Both also recognize that agents interact with existing systems through tools, credentials, and service interfaces.

Their roles remain different. NIST develops guidance through a federal standards process and can influence procurement expectations. Advanced AI Society is proposing an implementation-oriented standard through an open community and wants independent verification tooling to develop around it.

The House proposal creates pressure on three groups. Agent vendors must explain how their systems identify each agent and constrain its permissions. Enterprise deployers must maintain inventories and determine which systems can take consequential actions. Security providers must generate evidence that external assessors can examine.

Federal contractors face the clearest potential forcing function. A vendor might treat open verification as optional while selling into ordinary commercial markets. That position becomes harder to maintain when a major buyer asks for machine-readable inventories, continuous records, and independently testable controls.

Insurers and auditors create another source of pressure. An insurer assessing an agent that can initiate payments needs more than a policy document. It needs evidence showing which identity acted, what authority existed, which control evaluated the request, and whether the resulting record remained intact.

The same issue appears in healthcare. An agent may retrieve medical records, summarize a case, or prepare an order. A hospital must distinguish between confirming the record’s integrity and confirming that the clinical decision was appropriate. Proof-of-Control addresses the former, while governance and professional review still determine the latter.

Developers will feel the change at integration points. Security can no longer end with protecting a model endpoint. Teams must account for credentials, tool permissions, delegation chains, data access, and side effects across every service an agent can reach.

This is why agent security is becoming a procurement issue rather than a feature comparison. Buyers need evidence that remains meaningful across vendors. Proprietary dashboards help operators manage their own systems, but they do not automatically create a shared assurance language for auditors, insurers, regulators, and customers.

Open Verification Challenges Vendor-Controlled Logs

The primary contest is between portable third-party evidence and security records that remain controlled by the vendor being assessed.

Traditional enterprise logs are not useless. They support incident response, monitoring, debugging, and compliance. The problem is that a log’s value depends on who generated it, whether it captured every relevant path, and whether someone could change it afterward.

AI agents make those questions harder. Their actions can depend on changing context, retrieved data, model output, tool responses, and delegated permissions. A system can record the final tool call without preserving enough context to establish why the call was authorized.

Proof-of-Control proposes evidence generated during execution, not reconstructed after an incident. It also seeks portable records that different parties can interpret without obtaining privileged access to the operator’s entire environment.

The project’s published standard overview describes evidence as binary, contemporaneous, tamper-evident, and transparent about residual trust assumptions. Binary means the controlled action either stayed within the declared boundary or did not. It does not mean the broader outcome was correct.

Consider a purchasing agent authorized to place orders below a company-defined limit. The verification layer could record the agent’s identity, the delegated authority, the evaluated amount, and the policy result. It could also reject an order exceeding that limit.

However, the evidence would not establish that the purchase was necessary, that the supplier was reputable, or that the price represented good value. Those are separate business judgments. Verification shows whether an explicit control held, not whether the organization designed a sensible control.

This separation is essential because security language often collapses several different claims. A vendor may describe an agent as safe because it has permissions, audit logs, and human approval options. Those features do not prove that no bypass route exists or that every consequential action passes through the control point.

Proof-of-Control’s proposed action interception gateway attempts to solve that problem. It sits outside the agent process and mediates controlled tool calls. For the architecture to work, the agent must have no alternative credential or network path that bypasses the gateway.

That no-bypass condition is difficult. Modern software environments contain service accounts, cached credentials, background processes, plug-ins, and direct network routes. A verifier must test the surrounding system, not merely inspect the gateway’s output.

The proposal also introduces privacy tradeoffs. Verification evidence must say enough to support a meaningful conclusion without exposing prompts, personal records, model weights, or proprietary business data. Cryptographic claims can reduce disclosure, but their usefulness depends on the quality of the underlying measurement and implementation.

Portability raises another challenge. Two vendors may use different policy languages, identity systems, runtimes, and logging formats. A shared evidence schema can normalize part of that variation. It cannot erase all differences in how the original controls were defined or enforced.

Open governance offers a credible response to this fragmentation. Public specifications, test vectors, reference code, and documented threat models give buyers and researchers material they can inspect. A vendor-controlled assurance program may disclose less and change without external agreement.

The Linux Foundation provides institutional infrastructure for this work. It can support community governance, intellectual property rules, contribution processes, and long-term stewardship. It does not certify that the design has solved agent containment or enterprise adoption.

That boundary should stay visible. Foundation hosting is evidence that a project has a venue for collaboration. It is not evidence that every deployment conforms, that every proof is complete, or that customers will accept the resulting records.

The Draft Already Shows Why Independent Review Matters

Proof-of-Control’s early inconsistencies reveal the difference between launching a standard and establishing one.

Advanced AI Society’s September announcement calls the release a “v1.0 working draft” and says public comments remain open through October 30, 2026. Its more detailed standard page identifies the document as “Working Draft v0.1” and lists an October 7 comment deadline.

The Linux Foundation’s event description also calls it Proof-of-Control v0.1. These differences may reflect unsynchronized publishing, a changed release plan, or separate labels for related artifacts. Whatever the reason, version and deadline ambiguity is material for contributors deciding what to review.

A standard depends on stable identifiers. Implementers need to know which normative requirements apply, whether a test vector matches the current text, and when a breaking change occurred. Auditors cannot evaluate conformity against a moving label.

This does not invalidate the project’s objective. It demonstrates why neutral repositories, release tags, change records, and public issue tracking matter. An open standard must make its own provenance verifiable before asking agent vendors to do the same.

The planned public briefing is scheduled for September 23. It brings together Linux Foundation leaders, Advanced AI Society representatives, security investors, identity providers, insurers, and the Agentic AI Foundation.

That event can clarify governance, but public discussion alone will not resolve technical uncertainty. Contributors need a normative specification, an explicit threat model, conformance tests, and reproducible implementations. They also need a process for deciding which mechanisms satisfy each requirement.

The project says its repository includes a reference implementation, machine-readable claim definitions, attack scenarios, and signed test vectors. It describes the implementation as a reference rather than a production product. That warning is important because early code can demonstrate feasibility without meeting operational security requirements.

A reference gateway can show how to evaluate a policy and create signed evidence. A production gateway must also survive credential theft, race conditions, replay attempts, incomplete telemetry, key compromise, infrastructure failures, and hostile operators.

Completeness creates another difficult problem. Tamper-evident records can show that recorded entries were not altered. They cannot, by themselves, prove that every relevant action entered the record. An agent with an unmonitored route might act off-record while the visible evidence chain remains internally consistent.

The stronger tier proposed by Advanced AI Society addresses this through execution gating. Under that model, a covered action cannot occur unless it passes through the control and produces evidence. The remaining question is whether every consequential action is truly covered.

External effects also complicate the picture. A gateway may verify that an agent sent an authorized payment request. It cannot automatically prove that a bank settled the payment exactly as expected. Assurance must connect agent-side evidence with receipts from outside systems.

Identity chains introduce similar risks. One agent may delegate work to another, which then calls a third-party service. Each handoff can change authority, context, or data exposure. A credible standard must preserve attribution without assuming that one identity token explains the full chain.

Control quality remains the largest conceptual limitation. Proof-of-Control explicitly avoids judging whether a chosen rule was wise. That separation makes technical conformity manageable, but organizations may market conformity as broader evidence of safety.

Buyers should resist that shortcut. A verified agent can faithfully follow an unsafe policy. It can also produce authorized actions based on incorrect model reasoning. Runtime verification complements testing, human oversight, risk analysis, and incident response. It does not replace them.

The project’s most responsible claim is therefore the narrow one. It seeks to improve evidence about whether declared controls governed covered actions. Claims about complete agent safety, regulatory compliance, or eliminated liability would exceed what that evidence establishes.

The Standard Must Prove It Works Across Real Agent Stacks

Adoption will depend on whether Proof-of-Control can operate across hosted models, local systems, and multi-vendor workflows without creating another isolated compliance layer.

Enterprise agent stacks rarely come from one supplier. A company may use a hosted model, an internal orchestration framework, a third-party identity provider, cloud databases, and specialist tools from several vendors. Each layer exposes different controls and telemetry.

Proof-of-Control claims that its action-boundary model can work across open and closed configurations. The model provider does not necessarily need to reveal its weights or training data. The verification layer instead observes controlled actions where the orchestration system invokes external capabilities.

That approach favors organizations controlling their own agent loop. They can insert a gateway, restrict credentials, and route tool calls through a defined boundary. A managed agent service is harder because the vendor controls the orchestration environment and decides what evidence to expose.

This difference turns architecture into a buying criterion. Customers evaluating a managed agent must ask whether it emits independently verifiable evidence, whether evidence covers every relevant tool call, and whether an operator can bypass the declared path.

A finance team offers a concrete test. Suppose an agent prepares invoices, updates accounting records, and initiates bank transfers. The verification system must distinguish between reading a ledger, proposing a payment, obtaining approval, and submitting the final instruction.

Each action needs an identity, authority source, applicable policy, time reference, and result. The system must preserve that chain across tools without leaking account data into a public verification record. It must also handle a revoked approval or a policy change during execution.

A software engineering agent creates a different test. It can inspect private code, modify files, execute tests, and request deployment. Proof-of-Control might verify which repository the agent accessed and whether deployment required a named approval.

The standard would still need to account for indirect effects. Code that passes an authorization gate can later expose data or alter production behavior. Runtime evidence shows how the agent crossed a boundary, while software review and security testing evaluate the artifact it produced.

Healthcare tests privacy and professional authority. An agent might retrieve a patient record under a clinician’s delegation and send a draft order for approval. Evidence must prove that access stayed within the grant without disclosing the underlying medical information.

These scenarios require more than a generic signed log. They need common semantics for identities, permissions, policy evaluation, evidence retention, and failure behavior. A record that one verifier interprets differently from another does not create interoperability.

Conformance testing will therefore decide the project’s credibility. Independent teams should be able to run the same test suite against separate implementations and obtain consistent results. Negative tests should show how systems fail when records are altered, actions bypass the gateway, or authority expires.

Performance will matter too. Agents often make several tool calls during one task. Continuous evidence generation adds signing, storage, verification, and policy evaluation work. Enterprises will need latency and operating data from representative deployments.

Proof-of-Control’s public materials emphasize machine-speed verification because human review cannot match agent execution. That premise is reasonable, but automation can also repeat a flawed rule at machine speed. Control changes must therefore be governed as carefully as code changes.

Operational ownership is another open question. Security teams may define baseline policies, application teams may integrate gateways, identity teams may manage delegation, and compliance teams may retain evidence. A standard that assumes one unified owner will struggle inside large organizations.

The project can still succeed without becoming the only agent security standard. Its evidence model could inform NIST guidance, vendor APIs, insurance questionnaires, or procurement templates. Shared concepts can influence the market even when implementations vary.

The greater risk is ceremonial adoption. Vendors may claim alignment while covering only selected actions or using the language of open verification without providing independent tests. Clear conformance levels and machine-checkable requirements can reduce that behavior.

Three Signals Will Decide Whether Open Verification Becomes Infrastructure

The next three tests are specification coherence, independent implementation, and regulatory adoption.

The first signal is whether Advanced AI Society resolves the draft’s version and comment deadline conflicts. A public release tag should connect the normative text, schemas, test vectors, reference implementation, and change history.

That step would strengthen the project’s central argument. Verifiable provenance should begin with the standard itself. If the artifacts remain inconsistently labeled, enterprises will hesitate to build controls or contracts around them.

The second signal is independent implementation. The founding organization’s reference code can prove that its authors built what they described. A separate team must show that the specification communicates enough detail to produce compatible evidence and verification results.

Useful implementation reports should document failures as well as successes. They should identify latency, integration burden, unsupported agent frameworks, privacy constraints, and any bypass routes found during testing. Production claims need evidence from environments outside the authors’ direct control.

The third signal is how NIST and Congress define agent verification requirements. If federal guidance asks for continuous inventories, tamper-resistant records, attributable identities, and independently testable controls, Proof-of-Control will address a recognizable procurement need.

The project would gain further momentum if federal contractors or regulated buyers requested portable evidence rather than vendor screenshots. That requirement would reward interoperability and create room for multiple verification providers.

The opposite outcome would weaken the case for a shared ecosystem. Agencies might accept conventional logs and periodic audits, or Congress might fail to advance the underlying legislation. Enterprises could then treat open verification as an optional security experiment.

Washington’s broader AI debate remains unsettled. Congressional leaders have discussed guardrails while also emphasizing a light regulatory approach and competition with China. That tension makes targeted technical standards more plausible than one comprehensive AI law.

The distinction between legislation and enactment must remain clear. The House agent security proposal is not established federal policy. NIST’s existing initiative is active, but its final guidance and market effects are still developing.

Advanced AI Society therefore has a narrow window to influence the emerging vocabulary. If it can demonstrate implementable controls before procurement rules harden, its definitions may shape how buyers describe runtime assurance.

Developers should watch whether common agent frameworks add native support for portable evidence. Enterprise buyers should ask vendors to identify every controlled action and any route that bypasses enforcement. Security teams should compare evidence integrity with evidence completeness.

Knowledge workers also have a stake. An agent acting on a person’s email, documents, calendar, or financial accounts can create consequences before the user reviews them. Users need a comprehensible record of what authority they granted and what the agent did with it.

The Advanced AI Society Proof-of-Control initiative offers a serious answer to that need, but it remains an early draft. Its value will come from tested interoperability, precise scope, and evidence that survives scrutiny by parties other than its creators.

The right next step is not to assume the standard solves agent safety. Buyers and builders should inspect the draft, test the no-bypass requirement, and submit concrete implementation failures during public review. Open verification becomes infrastructure only when independent participants can reproduce its claims and identify its limits.