What is Proof-of-Control?

Proof-of-Control is an open standard from the Advanced AI Society for evidence, openly verifiable by anyone, that an AI agent stayed within the controls it was given. Its working draft defines 127 requirements across six domains of verification (Provenance, Privacy, Portability, Authorization, Identity, and Security) and four Verifiability Tiers. It is open for public comment through October 30, 2026.

Where does AER-1 verification sit in the Proof-of-Control Verifiability Tiers?

The AER-1 verification procedure has the character Proof-of-Control describes for Tier 3, Trust-minimized: anyone can verify, with no privileged access, after the fact, and a break in the record can be detected by anyone while the system itself can still run. AER-1 does not have the Tier 4 property: execution is not gated on a proof. This page is a mapping, not a rating: no Proof-of-Control body has rated, certified, or endorsed AER-1.

Does an AER-1 receipt prove an agent stayed within its authorization?

Not by itself. An AER-1 receipt records the tool, its version, and the caller scope as stated, and a checker can verify that record was not changed after it was saved. AER-1 does not grant authority and does not block an out of scope action; enforcement belongs to the executing system. The receipt is the evidence layer a control system can point to, not the control itself.

Proof-of-Control and AER-1: How Receipt Fields Map to the Six Domains and Verifiability Tiers

Proof-of-Control: open standard stewarded by the Advanced AI Society; standard text in the public repository github.com/LFDT-ProofOfControl/ov-poc-standard

PoC status: v1.0 working draft, open for public comment through October 30, 2026

PoC shape: 127 requirements across six domains of verification, graded by four Verifiability Tiers

AER-1: IETF Internet-Draft draft-zambo-aer1-24 by Brennan Zambo. An Internet-Draft is not a finished standard. This revision expires April 23, 2027.

AER-1 conformance: kit v1.5.6, 119 vectors and 122 checks per runner, as stated in the draft itself

What this page is not: not a certification, not an endorsement, and not a conformance claim. No Proof-of-Control body has rated AER-1. It is a mapping written from the two public texts.

What Proof-of-Control is

Proof-of-Control is, in its own words, an open standard for evidence, openly verifiable by anyone, that an AI agent stayed within the controls it was given. It exists to close what it calls the Verifiability Gap: the widening distance between what AI agents do and anyone's ability to openly verify that they stayed within their controls.

The draft organizes its 127 requirements under six domains of verification: Provenance, Privacy, Portability, Authorization, Identity, and Security, one chapter per domain (C1 to C6 in the repository). It grades evidence, not intentions: a policy states what an agent should do, and Proof-of-Control asks what record shows what the agent actually did.

It also draws a hard line on how evidence is checked. Its four Verifiability Tiers are graded by who you must trust to believe the evidence. Tier 1 is Assertion (their word), Tier 2 is Attestation (a third party vouches), Tier 3 is Trust-minimized (anyone can verify), and Tier 4 is Self-enforcing (it cannot run otherwise). The draft states that a system has Proof-of-Control when, and only when, its evidence reaches Tier 3 or Tier 4.

What AER-1 is, in one paragraph

AER-1 defines a portable receipt for one AI agent tool call. A receipt is a plain JSON object. Its core members, from Table 1 of draft-zambo-aer1-24, are id, receipt_schema_version, created_at, tool (name, version, and caller scope), provenance_class, canonical_bytes, output_hash, metadata_hash (required at schema 0.4 and later), verification_status, and the optional supersedes. Anyone can run the verification procedure in Section 6 of the draft: resolve the receipt at its stable public URL, recompute the SHA-256 digest over the canonical bytes, and compare it with output_hash. A verifiable receipt proves the saved result was not changed. It does not prove the model was right.

The domain by domain mapping

Each row names the AER-1 fields that bear on the domain, what evidence need they serve, and the limit of that service. The limits are part of the mapping: a crosswalk that only lists strengths is marketing, not a crosswalk.

Proof-of-Control domain	What the domain asks for	AER-1 fields and properties	How the receipt serves it, and its limit
Provenance (C1: lineage and origin)	Where an artifact, model, or piece of data came from, that it matches what it claims to be, and the custody chain linking origin to the action record.	`provenance_class`, `canonical_bytes`, `output_hash`, `created_at`, `id`; optional `execution_context` (model name, version, and digest; source system; framework); optional `field_provenance`	Direct fit. Every receipt names exactly one of the three provenance classes in Section 5 of the draft: EXECUTED BY ZAMBO, OBSERVED VIA GATEWAY, or LOGGED BY AGENT, so a reader can see who ran or reported the action and how far the record reaches. The output commitment binds the exact bytes produced to the record, and `execution_context` can record which model state and source system sat behind the call. Limit: `execution_context` is producer-asserted context outside the metadata commitment, and the draft says a verifier must surface it as recorded, never as an attested fact.
Privacy (C2: confidentiality)	What data was touched, and that the purpose matched the grant, evidenced without exposing the data being protected.	`input_hash` (optional, Section 3.3), `output_hash`, `metadata_hash`	Partial fit, stated honestly. The digest members let a checker confirm that presented input or output bytes match the bytes committed at execution time, without re-running the job. Limit: AER-1 is an evidence format, not a confidentiality mechanism. It records no purpose or grant, and in the reference implementation the receipt at its public URL carries the canonical output bytes themselves. A deployment that needs Proof-of-Control privacy evidence still has to control what goes into a receipt before the receipt is made.
Portability (C3: cross-context control)	That evidence and control move across vendors, platforms, and environments as claimed.	The receipt as a bare JSON document; the stable public URL rule (Section 9); workflow receipts and their Merkle root (Section 8); external anchors (Section 10)	Direct fit. The receipt object is the document: no presentation envelope is part of the format, and every receipt must be retrievable at a stable public URL without an account, wallet, or token, so the evidence travels wherever the work travels and can be checked there. A workflow receipt binds an ordered sequence of step receipts under one Merkle root, so a multi-step job stays one checkable record when it moves. External anchors of type nostr, ots, witness, scitt, or rfc3161 can bind the record to a system outside the issuer.
Authorization (C4: granted authority)	That each action stayed within the authority granted, and what happened when it did not.	`tool` (including caller scope), `created_at`; optional `execution_context.payment` (method and reference); optional `reversal`; optional `negative_record`	Partial fit. A receipt fixes, in a checkable record, which tool ran, in what caller scope, and when, and it can record the payment reference for the call and whether the execution was later reversed or compensated. That is the record an authorization review reads. Limit: the receipt records scope as stated. It does not grant authority, evaluate a policy, or block an out of scope action. The draft says the same about reversal: whether a reversal is permitted or enforced belongs to the executing system, not to the receipt. AER-1 supplies the evidence layer for this domain, not the enforcement layer.
Identity (C5: attribution)	Whose agent acted, who delegated the authority, and that the operator authorized it.	`id` and the Section 6 `id_verdict`; `tool` caller scope; `provenance_class`; optional `field_provenance` (actor, tool, counterparty)	Partial fit. A verification report does not just say pass or fail about an id: the `id_verdict` is one of matched, resolved, mismatched, unverified, or absent, so a reader can see exactly how the receipt id was bound to the bytes, or that it was not bound at all. `field_provenance` states, per field, which party wrote the value. Limit, in the draft's own words in its Security Considerations: issuer authentication is not part of this specification. An AER-1 receipt attributes a record; it does not authenticate an issuer the way a credential system does.
Security (C6: environment integrity)	That the code ran unmodified, in the environment claimed, with access controls enforced.	`output_hash`, `metadata_hash` and the Section 3.1 metadata block; hash-chained job timelines (Section 7); external anchoring (Section 10)	Partial fit, on the record side. The metadata block binds `created_at`, `id`, `output_hash`, `provenance_class`, `receipt_schema_version`, and `tool` into one digest, so relabeling a receipt breaks its own check. In a job timeline, each entry carries the digest of the previous entry, so editing, moving, or splicing entries is detectable by recomputation. Limit: AER-1 checks the integrity of the record after the fact. It does not attest the runtime environment, and it does not stop execution when a check fails. Environment attestation is a different mechanism, and Proof-of-Control treats it as one.

Verification outcomes: the AER-1 vocabulary

Proof-of-Control wants binary, deterministic outcomes: every verifier reaches the same answer from the same record. AER-1 Section 6 gives a verifier a small, fixed vocabulary for saying exactly what happened, and forbids blurring the categories.

Structural verdict: a pass, verification failed (a recomputed value does not match the committed value), or rejected: <reason> (the record cannot be fully evaluated, for example a duplicate receipt id, a size limit, an unresolvable record, or unreproducible bytes). A rejection must never be reported as verification failed.
Id verdict (id_verdict): matched, resolved, mismatched, unverified, or absent.
Per-anchor outcome, for each external anchor, exactly one of: verified, verification failed, rejected: unresolvable record, not checked, or absent. An anchor the verifier did not evaluate is reported as not checked, never with an evaluated outcome, and not checked and rejected: unresolvable record are different states that must not be conflated.

That last rule is the one that matters most for Proof-of-Control readers: the vocabulary has a first class way to say "nobody has checked this yet," separate from "this was checked and failed." Evidence systems that cannot say not checked force every unchecked item to borrow credibility it has not earned.

Where AER-1 sits in the Verifiability Tiers

Tier	Proof-of-Control definition	AER-1 position
Tier 1: Assertion	Their word. Not verified; asserted. You must trust the operator.	A claim about agent work with no receipt sits here. AER-1 exists to move a claim off this tier.
Tier 2: Attestation	A third party vouches. An auditor verifies, with privileged access, after the fact and sampled.	An auditor's report about receipts would sit here. The receipt itself needs no auditor: that is the point of the format.
Tier 3: Trust-minimized	Anyone can verify, no privileged access, after the fact but by anyone. On an integrity break: detected by anyone, and the system can still run.	This is the character of AER-1 verification. Any person can resolve a receipt at its public URL and recompute its digest, with no account and no relationship to the operator, and every verifier reaches the same result from the same record. A changed record is detectable by anyone who checks it, and nothing in the format stops the underlying system from running, which is exactly the Tier 3 integrity row and exactly not Tier 4.
Tier 4: Self-enforcing	It cannot run otherwise. Verification is continuous, and execution is gated: no proof, no write.	AER-1 does not claim this tier. A receipt is produced at execution and checked after it. Nothing in AER-1 gates a tool call on a proof, and the draft claims no such property.

Two cautions belong next to that Tier 3 row. First, the tiers grade who you must trust, not whether mathematics is used, and the Proof-of-Control tiers chapter itself warns that a mechanism published and vouched for by one central party does not reach Tier 3 on math alone. AER-1's answer to that caution is structural: the format is public, the verification procedure is public, the conformance corpus is public (119 vectors, 122 checks, kit v1.5.6), and external anchoring under Section 10 can place the commitment with systems the issuer does not control. Second, this page is a mapping by the AER-1 side. A formal tier determination, and the residual trust disclosure Proof-of-Control requires at Tier 3 and Tier 4 under its conformance chapter, are separate work that has not been done by any Proof-of-Control body for AER-1.

What this crosswalk does not claim

No certification. AER-1 is not Proof-of-Control certified, and this page does not say it conforms to Proof-of-Control. It maps fields to domains.
No endorsement. Nothing here implies that the Advanced AI Society, the Proof-of-Control working group, or the Linux Foundation endorses AER-1 or Zambo.
Both texts are drafts. Proof-of-Control is a v1.0 working draft in public comment. AER-1 is an IETF Internet-Draft (draft-zambo-aer1-24), not a finished standard or RFC. Either text can change.
A receipt is evidence, not a control. AER-1 records and lets anyone check. It does not set policy, grant authority, keep data private, or halt a run.

Comment on Proof-of-Control, while the window is open

The Proof-of-Control v1.0 working draft is open for public comment through October 30, 2026. The working group reviews comments and publishes its decisions. If you build agent evidence systems, this crosswalk is one reading of how an existing receipt format meets the draft; the draft's authors are the right audience for where it should be stronger.

Read and comment: advancedaisociety.org/proof-of-control
Standard text: github.com/LFDT-ProofOfControl/ov-poc-standard, including the Verifiability Tiers chapter (C8)
AER-1 text: draft-zambo-aer1-24 on the IETF Datatracker

Use the receipt layer today

Zambo is the verifiable work layer for AI and the reference implementation of AER-1: 153 tools behind one MCP endpoint at https://zambo.dev/mcp (35 on the default surface), continuity and handover that carry work across AIs, and a verifiable AER-1 receipt for every job. Start with a Day Pass for $0.99 for 24 hours, or the Zambo Pass at $29 per month.

Hold one in your hands: mint a real AER-1 receipt in 30 seconds, no signup, then check it yourself and compare the outcome words with the vocabulary above.

Proof-of-Control and AER-1: the crosswalk