The pattern is store once and prove repeatedly: zkshare_prove turns a question into a yes/no answer inside a signed envelope, and the recipient checks it with zkshare_verify_proof without ever seeing the value. Know where the trust sits in the default mode — server-sealed facts are decrypted in memory by the server that holds the encryption key, so the operator is inside the boundary; use the client-sealed path when they should not be.
A privacy layer for agent context. Facts go in encrypted; what comes back out is a yes/no answer wrapped in a signed proof envelope, plus semantic search and an allow-listed sandbox for computing over values you would rather not expose.
- A fact stored encrypted with AES-256-GCM, with a commitment and an embedding kept beside it
- A yes/no answer to a question about a stored fact, returned in an HMAC-signed envelope carrying the commitment, the query and a nonce — never the value
- The same answer plus a single-use, time-bound share token issued to a named recipient agent
- Semantic search across the facts stored under your API key
- Verification of any proof envelope, done without reading the fact behind it
- Allow-listed computations over sensitive values, such as calculate_travel_budget and analyze_spending
- A client-sealed path, where the server holds only opaque ciphertext and never derives plaintext
ZKSHARE_API_KEY, which identifies the caller and scopes which stored facts are visible. ZKSHARE_API_URL points at the deployment — the hosted service, or your own, since the implementation is a Next.js app backed by PostgreSQL with pgvector.
One command plus a key — npx -y zkshare-mcp, then supply credentials