What a Zero-Knowledge Proof Is

A zero-knowledge proof lets one party — the prover — convince another party — the verifier — that a statement is true, without disclosing anything beyond the truth of the statement itself.

Analogy

Proving you have the right key to a locked room by opening the door — without ever showing the key.

▶
Prover
The AI agent. Holds a secret and constructs a proof from it.
✓
Verifier
The counterparty service. Checks the proof in milliseconds.
⊘
Statement
"This agent is authorized for this action" — true or false, nothing more.
What Is — and Isn't — Revealed

Counterparties learn exactly what the proof attests to, and nothing else. The principal — the human on whose behalf the agent acts — is never identified by name, account, or history.

Revealed to Counterparty
  • An agent exists. A real cryptographic principal is acting — not a prompt-injected string.
  • Scoped authority. The exact actions, resources, and spending bounds this proof covers, right now.
  • Policy binding. The proof is tethered to a signed policy the principal approved.
  • Revocation status. Whether the proof is still live or has been pulled.
Not Revealed
  • Owner identity. The human or organization behind the agent — no name, no account number, no email.
  • Raw key material. No private keys, signing secrets, or replayable tokens ever cross the wire.
  • Transaction history. Prior actions with other counterparties remain invisible.
  • Underlying prompt or model. The agent's reasoning and training stay sealed.
What It Unlocks
⟁
Autonomous Transactions
Counterparties accept the proof without a human in the loop — agents act on behalf of people, at machine speed, under policy.
◈
Audit & Compliance Without Over-Sharing
Auditors verify that an action was authorized. Raw transaction data stays with the principal — not with the auditor or the counterparty.
⥁
Portable Trust Across Counterparties
One proof travels between counterparties without re-sharing identity. The PrivacyCore Audit Trail anchors each use to an immutable, exportable record.

Fully homomorphic encryption lets an agent compute over sealed data without exposing the underlying inputs.

Explore the FHE workflow →
How It Differs From API Keys or OAuth
Dimension API Key OAuth 2.0 ZK Agent Identity
Identity model Shared secret. Anyone with the key is the agent. Delegated token bound to a user account. Proof bound to a policy; the holder proves the right, not the identity.
Disclosure to counterparty None — key is opaque, no claims attached. High — user identity, scopes, and provider metadata are exposed. Minimal — only the policy-scoped claims this transaction needs.
Revocation Rotate the key globally — affects every caller. Server-side token revocation list per provider. Proof is self-contained and expires; revocation is a one-bit signal.
Audit posture After-the-fact log scraping; no proof of intent. Provider logs the who, what, and when — but the user is identifiable. Cryptographic proof of authorization at the moment of action; principal remains pseudonymous.
Replay / theft risk High — stolen key = full impersonation. Medium — bound to client + redirect URI, but token theft works. Low — proofs are single-use or tightly scoped; keys are never sent.
Read the Architecture deep-dive → See it mapped to HIPAA / PCI / SOC2 → Request Enterprise POC