[Draft/Idea] Confidential Agent Policy Verdicts

ERCs
1

Confidential Agent Policy Verdicts proposes a pre-execution allow/deny interface for autonomous agent actions, where the decision is proven in zero knowledge against a policy that is never disclosed on chain.

Authors: Muhammad Zidan Fatonie (@mzf11125), Faisal Firdani (@zexoverz), Maulana Asykari Muhammad (@WeissCurry)

Summary

Agent authorization on Ethereum today comes in two shapes. It is either retrospective, as with ERC-8004, which records identity, reputation, and validation attestations after an agent has acted, or it is mandate-based, as with ERC-8150 and ERC-8312, where authority derives from a principal who signed a specific grant in advance.

A large class of deployments fits neither. Consider a corporate expense card. The cardholder does not pre-sign each purchase, and the card network’s fraud rules are shown neither to the cardholder nor to merchants. Authority comes from a standing ruleset held by a third party, applied to every transaction, updated without anyone re-signing anything, and deliberately kept secret, because a published fraud rule is a published evasion guide.

Regulated agent deployments have the same shape. An operator maintains screening rules, agents are subject to them whether or not any counterparty signed them, the rules change frequently, and publishing them defeats them. Both obvious workarounds fail. Putting the policy on chain discloses it to the adversaries it exists to stop. Trusting an off-chain oracle to say “allowed” gives no evidence that any policy was applied, so the verdict is indistinguishable from an arbitrary signature.

Zero knowledge resolves the tension. The verifier learns that some committed policy was correctly evaluated and returned allow, and learns nothing about its contents.

How It Works

  1. An agent proposes an action.

  2. The Policy Domain’s off-chain engine, not the agent, evaluates that action against the secret ruleset. The agent never holds the rules.

  3. If permitted, the engine produces a zero-knowledge proof that this action was checked against the committed policy and the result was ALLOW. The proof reveals nothing about the policy’s contents.

  4. A Guard contract on chain verifies the proof.

  5. If valid, the action executes. If not, it is refused.

The policy exists on chain only as a commitment, registered as a statement in the ERC-7812 Evidence Registry. What crosses chains is a single root, not the rules.

The standard defines only the verdict envelope and the verification interface. It does not define the policy language, the proving system, or the transport.

Two Choices Worth Surfacing Early

The program proven is a policy interpreter, not a compiled policy. If policies compile to circuits, every rule change produces a new verification key, which means a new verifier deployment on every chain for every update. For a ruleset that changes weekly this is disqualifying rather than inconvenient. By proving a fixed interpreter and passing the ruleset as private witness, the program commitment stays constant across policy updates and only the ERC-7812 root moves. The cost is that the interpreter proves a superset of any single policy, so proofs are more expensive than a bespoke circuit would be. That trade puts proving cost off chain with the domain and removes verification key churn from everyone else.

The policy commitment is deliberately unblinded, departing from ERC-7812’s blinding pattern. Blinding would make the commitment unverifiable even to a party holding the ruleset, which destroys the selective-disclosure path to auditors. Preimage resistance alone carries the confidentiality requirement, given adequate ruleset entropy.

Scope of the Privacy Claim

This standard hides the policy, not the action. A permitted action executes on a public chain and is public. The guarantee is that no observer, including the executing agent, learns the rules that permitted it.

It is an integrity property, not a safety property. A valid proof establishes that the committed ruleset was evaluated, and establishes nothing about whether that ruleset is correct or fair. A domain committing to a permit-everything ruleset produces proofs that verify perfectly well.

Relationship to Neighbouring Standards

  • ERC-8004 supplies the agent identity the verdict binds to.

  • ERC-7812 supplies the evidence registry. It was written abstractly so later proposals could build specific use cases on top of it, and nothing in the agent cluster has taken it up yet. This is that bridge.

  • ERC-8312 is complementary rather than overlapping. A verdict grants permission, a mandate grants capacity, and both must hold independently.

  • ERC-8150 is the closest neighbour, since it also does pre-execution verification in zero knowledge. The difference is the authority source and the secret. There, the user signs off on the agent’s batch, so the authorizing party knows exactly what was authorized and there is nothing to hide from the principal. Here, authority comes from a standing third-party ruleset that no counterparty signs, and its confidentiality is the point rather than a side effect.

  • ERC-8226 shares the regulated-deployment motivation, but its mandate stays legible to the parties it binds and it scopes to tokenized regulated assets. The envelope here is asset-agnostic and gates arbitrary calls. A domain could plausibly use both.

  • ERC-7579 and ERC-6900 are the natural integration surface. The Guard operates as a pre-execution hook or validation module.

  • ERC-4337 and ERC-7562 constrain how this can work inside validateUserOp. See outstanding issues.

Update Log

2026-07-24: initial draft, PR TBD

External Reviews

None as of 2026-07-24.

Outstanding Issues

  • 2026-07-24: Placement in the ERC-4337 validation phase. On-chain proof verification inside validateUserOp must respect ERC-7562 storage access and gas limits, or bundlers drop the operation. I believe verification can be made constant-cost and state-independent, but I have not checked it against the full ERC-7562 rule set and would value input from bundler implementers.

  • 2026-07-24: Asynchronous proving latency. Proof generation sits in the execution path, so an agent cannot act while the domain’s policy engine is unreachable. ERC-7412 looks like the right pattern for structured off-chain retrieval, but I have not decided whether the standard should reference it normatively or leave it to integrators.

  • 2026-07-24: Interpreter fidelity is currently assumed, not proven. A runtime proof attests that the committed program executed. It does not attest that the program faithfully implements the policy language it claims to. An interpreter that ignores its ruleset and always returns ALLOW produces proofs that verify identically to a correct one. The current draft handles this with a recommendation that domains publish a machine-checkable equivalence proof against a readable reference definition, bound to the program key. Open question: should that attestation mechanism become its own ERC that this one requires, or stay inline?

  • 2026-07-24: Interpreter confidentiality is a separate property from fidelity. A correct but leaky interpreter, whose public outputs or revert behaviour vary with which branch of the ruleset fired, satisfies every correctness check and still leaks policy structure. Proving time is the channel I am least confident about, since it sits outside the proof entirely.

  • 2026-07-24: Whether the domain registry should be a separate ERC. IPolicyDomainRegistry is specified as a recommended companion so independent implementations interoperate by default, while the core interface depends only on three semantic hooks. Splitting it would follow the ERC-7812 precedent but would couple this proposal’s path to Final to another Draft.

  • 2026-07-24: Root staleness as a revocation service level. maxRootAge exists because mirrored roots on spoke chains lag the hub. Set it to zero and verdicts break during any sync gap. Set it high and a removed rule keeps authorizing actions for that long on every spoke. There is no setting that avoids both, and I would like input on whether the standard should mandate a ceiling or leave it to domains to publish.

  • 2026-07-24: Cross-chain agent identity resolution is out of scope and deferred. agentId must currently resolve on the chain where the verdict is consumed. Flagging in case anyone considers this a blocking gap rather than a deferral.

  • 2026-07-24: interfaceId is a placeholder and will be finalized before this leaves Draft. The reference implementation, including an executable test suite and a two-spoke cross-chain deployment, is in progress and not yet published.

Feedback I Am Specifically Looking For

  1. Is the interpreter-as-proven-program approach the right call, or is there a compiled-circuit design that avoids verification key churn that I have missed?

  2. Does the unblinded commitment departure from ERC-7812 create problems for that standard’s authors that I have not anticipated?

  3. Is the executor binding sufficient against mempool front-running of a valid verdict, given that proof generation and submission are decoupled?

  4. For anyone working on ERC-8004: does the Validation Registry attestation proposed after a successful consume fit the intended use of that registry, or is it a misuse?

  5. For the ERC-8150 and ERC-8226 authors: is the boundary I have drawn the right one, or is there a merge that serves everyone better than three adjacent standards?