Overview

zkMCP policies answer one question:

Given a concrete normalized action request, does this agent have authority to execute it under the private policy committed for this deployment?

The hackathon implementation intentionally uses a small explicit policy model rather than pretending a general policy DSL already exists.

Current policy state

The private policy contains:

policy secret
allowed agent
allowed documents tool
allowed email tool
allowed payments tool
allowed resource
private payment hard maximum
private payment approval threshold

These values are committed together at deployment. Later authorization calls must prove that the witness policy hashes to the same public policyCommitment.

Implemented primitives

The primitives are conjoined. A successful receipt means all constraints relevant to that branch passed, not that an independent advisory check returned “looks okay.”

Click to zoom

Policy is separate from application payload

The policy does not automatically cover every field an MCP tool accepts.

For example, the payment tool forwards:

amount
recipient
memo

but the current payment circuit constrains only:

amount
approved
agent
tool

The recipient and memo are therefore not protected by the current proof statement.

This is why tool normalization and circuit design have to be reviewed together. If an application field matters to authority, it must become part of the deterministic authorization statement and, when appropriate, the execution commitment.

Policy privacy

The current policy values are local/private witness state. The public contract stores a salted commitment rather than the raw rules.

A verifier can learn:

this authorization matched policy commitment 0x...

without learning:

the private maximum was £5,000
the assigned matter was matter:thompson
the approval threshold was £4,000

The local policy owner/prover obviously knows its own rules. The privacy boundary is between that private authorization environment and public verification state.

Current lifecycle limitation

One private policy commitment is sealed per current contract deployment.

The prototype does not yet provide:

policy update
policy version selection
policy revocation
multiple active policies
per-agent policy lookup
policy expiry

Those need an explicit lifecycle because changing a hidden policy while retaining the same public identity would weaken auditability.

Read by primitive

For exact circuit syntax and current field coverage, see Circuit constraints.