Introduction

zkMCP sits between an MCP client and an existing MCP tool server. Sensitive tools/call requests are reduced into deterministic authorization facts, evaluated against a private committed policy with Midnight/Compact, and forwarded upstream only after authorization succeeds.

Public developer documentation: https://zkmcp.zohaibarsalan.me. The hosted playground uses the final verified recorded receipts; fresh proving runs locally with the Midnight stack.

Click to zoom

The problem zkMCP solves

Connecting an agent to a tool establishes access, not authority over every possible side effect.

zkMCP is focused on the third question.

This lets an integration express boundaries such as:

documents.read
  → only the assigned private resource

email.send
  → requires trusted human approval

payments.transfer
  → private hard maximum
  → private approval threshold

What is implemented

The current repository has a real end-to-end MCP + Midnight path.

Enforcement model

The critical ordering is:

receive request
    ↓
normalize + trusted context
    ↓
private policy authorization
    ↓
proof verification + transaction finalization
    ↓
upstream MCP execution

A policy denial, replay, malformed request, unavailable prover, or unavailable Midnight contract all stop before the upstream tool handler.

The gateway does not “execute and then write an audit proof.” The proof-backed authorization is a prerequisite for execution.

Privacy model at a glance

A successful authorization intentionally exposes a small public receipt:

policyCommitment
executionCommitment
nullifier
transactionId
blockHeight
contractAddress
network

The current ledger does not directly publish:

policy secret
allowed agent
allowed resource
private maximum
approval threshold
requested amount
approval token
nonce
prompt
arbitrary tool arguments

Private policy denials are also surfaced generically as policy.AUTHORIZATION_DENIED so the caller cannot learn which hidden constraint failed.

What zkMCP proves

zkMCP does not prove that the LLM reasoned correctly, that its prompt was trustworthy, or that an upstream tool implementation is correct.

The statement is deliberately smaller:

This concrete action request satisfied the committed authorization policy before the gateway invoked the protected MCP tool.

That boundary keeps the probabilistic model outside the security proof while making the side-effect decision deterministic and verifiable.

Where to go next