Zero-Knowledge Proofs

What is a proof?

When you ask ICME to check an action against a policy, the system runs a solver to determine whether the action is allowed (SAT) or blocked (UNSAT). But how do you know the check actually happened correctly? You're trusting a server to give you an honest answer.

A zero-knowledge proof is a piece of math that lets you verify the answer was computed correctly — without having to rerun the computation yourself, and without seeing the private inputs that went into it.

Every /v1/checkIt call on ICME generates one of these proofs automatically.

Two properties that matter

Succinct verification

The solver that checks your action against a policy does real work — it parses rules, extracts variables, runs an SMT solver, and cross-checks with multiple reasoning engines. This can take seconds.

The proof of that computation, however, can be verified in milliseconds. A third party doesn't need to rerun the entire pipeline. They just need the proof and a verifier, and they get a yes/no answer: was this result computed honestly?

This is what "succinct" means. The proof is tiny compared to the computation it represents, and checking it is fast regardless of how complex the original work was.

Privacy preservation

A zero-knowledge proof reveals the result of a computation without revealing the inputs.

In ICME's case, this means a verifier can confirm that a policy check returned SAT or UNSAT — without seeing the policy rules, the extracted variables, or the raw solver state. The proof attests to the correctness of the output without exposing what went in.

This matters when policies contain sensitive business logic. You can let an external party verify that a check happened and that the result is legitimate, without handing over the policy itself.

How it works in practice

1. You call /v1/checkIt with a policy and an action.

2. The system runs the check and returns SAT or UNSAT.

3. In the background, a ZK proving pipeline takes the computation trace and generates a cryptographic proof.

4. The response includes a proof_id you can use later.

From there, anyone can verify the proof — no API key needed:

bash

# Verify the proof was computed honestly
curl -s -X POST https://api.icme.io/v1/verifyProof \
  -H 'Content-Type: application/json' \
  -d '{"proof_id": "YOUR_PROOF_ID"}' | jq .

The verifier confirms that the claimed result (SAT or UNSAT) matches what the solver actually computed. If someone tampered with the result, the proof would not verify.

Why this matters for AI agents

AI agents increasingly make decisions that affect real assets — transferring tokens, approving transactions, executing trades. Policies that govern these agents need to be enforceable and auditable.

Without proofs, you're trusting the guardrail service to report honestly. With proofs, trust is replaced by math. An agent's operator, a counterparty, or a regulator can independently verify that a specific action was checked against a specific policy and that the result is authentic.

This is especially useful when the party verifying the result is different from the party who created the policy. The proof bridges that trust gap without requiring either side to share sensitive information.

Key terms

Prover — the system that runs the computation and generates the proof. In ICME's case, this is the backend that executes the policy check.

Verifier — anyone who checks the proof. Verification is fast, public, and doesn't require access to the original inputs.

Trace — the full record of the computation (every step the solver took). The prover uses this to build the proof. The verifier never sees it.

SAT / UNSAT — the result of a policy check. SAT means the action is allowed under the policy. UNSAT means it's blocked.

Claimed result — the result the prover says the computation produced. The proof lets the verifier confirm this claim is honest.

Current status

The ZK proof system is functional and generates real cryptographic proofs for every policy check. The proving pipeline has not yet completed a formal security audit. Reach out to the team with questions or concerns.

Proofs are single-use — once verified or downloaded, they are marked as consumed. We also recommend verifying or downloading proofs shortly after generation, as they are stored on ICME's infrastructure and the SRS string used to create them, may not persist indefinitely across server updates.