The pitch is easy to write and hard to deliver. A user has sensitive data — health records, legal correspondence, financial history, journal entries with names in them. They want an AI agent to help them work with that data. They do not want the company hosting the agent to be able to read it. They do not want the company hosting the MCP server to be able to read it. They do not want a subpoena, a breach, or an insider with privileged access to expose it.
So you ship a zero-knowledge MCP server. The server stores the data encrypted. The keys live with the user. The server, the people running it, and anyone who compromises it learn nothing about the contents.
Then the agent calls a tool: find all records matching "anxiety". The server cannot answer. It has the encrypted ciphertexts; it cannot read them. The promise of zero-knowledge directly conflicts with the promise of "useful for arbitrary queries." The cleaner the encryption story, the dumber the server.
This is the paradox the rest of this post is about. There are four resolution paths people have actually tried — none of them solves it cleanly, all of them solve a part of it — and the right answer for any specific product is usually a combination, plus an honest accounting of what the system cannot do.
A clarifying note before the paths. Zero-knowledge is being used here in the loose architectural sense — "the server cannot read the data" — not the strict cryptographic sense of zero-knowledge proofs. The literature would call most of what follows end-to-end encryption with a blind server. The looser term is what the field has settled on, and we use it here for that reason; the rigorous reader should mentally substitute "blind storage" wherever it appears.
This is the first of three posts on zero-knowledge MCP, and it is the one that sets the frame for the others. Post 9 covers key recovery (the hardest UX problem in any ZK system). Post 10 covers searchable encryption (where the open problems live). Read in order if you can.
Why this is a hard problem at all
A naive person hears "encrypted database" and thinks the problem is solved. The data is encrypted. The keys are with the user. The server holds nothing readable. Done.
The trouble starts the moment any tool other than "give me the encrypted blob for ID X" is needed. Almost every useful tool involves either reading the data to make a decision (filter, search, summarize) or writing the data after some transformation (categorize, redact, link to another record). Both require the server to handle plaintext, or to perform operations on ciphertext that are equivalent to handling plaintext. A server that does either is not zero-knowledge any more.
The cleanest framing: zero-knowledge is a property of the data flow, not a setting on the database. Every place where the server would have to look at the plaintext to do its job is a place where the architecture has to either move the work somewhere else, or accept that the server learns the plaintext at that point.
There is no clever cryptographic trick that makes this go away in general. There are clever tricks that handle specific cases. The four paths below are the four families of those tricks, ordered by how much they ask of the system around them.
Path A: Client-side decrypt loop
The simplest path, and the right starting point for most products.
The pattern: the server stores ciphertexts and per-record metadata that does not leak content (a numeric ID, a creation timestamp, maybe a tag-set encrypted under a deterministic scheme — see Path C). The server's tools return only what it can produce without reading plaintext. The agent — running on the user's device, or on a server the user trusts — does the real work after decrypting.
A worked example. A health-records ZK MCP server, with a tool getRecord(id) that returns the ciphertext. The agent loop on the user's device:
- Agent decides it wants to find records mentioning a symptom.
- Agent calls
listRecordIds(). Server returns 200 IDs. Server has not read anything. - Agent loops: for each ID, calls
getRecord(id). Server returns ciphertext. Server has not read anything. - Agent decrypts each ciphertext with the user's key, on the user's device, and filters.
- Agent returns the matching records to the user.
The server has been completely blind. The decryption and the filtering have happened in a place where the plaintext is allowed to exist — the user's device, in the host process that owns the user's keys.
What this buys you: actual zero-knowledge, no fancy crypto, no infrastructure beyond a normal encrypted database, the simplest possible threat model.
What it costs:
- N round trips for an N-record query. A 200-record search means 200 tool calls. On a fast network this is bearable; on a phone over LTE it is painful; for a million-record archive it is impossible.
- All decryption work is on-device. Battery, memory, latency.
- The agent must run somewhere with key access. This collapses to "on the user's device." A cloud-hosted agent cannot help here without holding keys, and if it holds keys the system is not zero-knowledge.
This path is the right call when the data is small enough to ship in full to the device per session, the agent can run locally, and the use case tolerates per-record fetches. A personal journal app. A solo therapist's case-note tool. A low-volume legal archive. For larger or more interactive use cases, one of the other paths has to come into play.
One prerequisite this section glosses over and that decides whether any of this is real: the agent doing the post-decryption reasoning has to run in a place that does not leak the plaintext. If the user's device decrypts the records and then sends them to a cloud LLM for reasoning, the server is blind but the inference provider is not. The privacy boundary has just moved one hop downstream, and for most threat models that is not an improvement. Genuine ZK MCP requires either a local model on the user's device (see the Flutter on-device host post) or a self-hosted inference path the user trusts. A cloud LLM behind a blind MCP server is privacy theatre dressed as architecture.
Path B: Trusted execution environments
The path that looks like a clean answer and is, in practice, an answer with a footnote.
The idea: a TEE — Intel SGX, AMD SEV-SNP, AWS Nitro Enclaves, Apple Secure Enclave for mobile — is a hardware-isolated region of a CPU where code runs in a way that the hosting OS, the cloud provider, and the operator cannot observe. The code inside the enclave can be sent the user's key over an attested channel, can decrypt and process plaintext, and produce results that get re-encrypted before leaving.
For ZK MCP, this means: the server is split. The thin outer layer holds ciphertexts and routes requests; the enclave holds the keys and does the actual tool work in plaintext. To the world outside the enclave, the data stays encrypted; inside the enclave, the data is fair game and tools can do anything they want with it.
What this buys you: real searchability, real summarization, real cross-record reasoning, all without the operator being able to read anything. The server is meaningfully blind from the outside; the work happens inside a hardware boundary.
What it costs:
- Trust shifts to the hardware vendor. You are now trusting Intel, AMD, AWS, or Apple not to have a backdoor or a CVE in their TEE implementation. There is a real history of TEE vulnerabilities — speculative-execution attacks against SGX, side-channel leaks, attestation flaws. None of these are theoretical. Each one is a "the property you bought has been weakened" event.
- Attestation is fiddly. The user's client has to verify, at the protocol level, that it is talking to a real enclave running the real expected code. The remote-attestation flows for SGX, SEV, and Nitro are all different, all underspecified for AI workloads, and all have rough edges that show up under load.
- Performance is worse than native. Memory bandwidth in SGX is famously poor. SEV is closer to native. Nitro is fine for most workloads. None of them are free; you give up 10-50% of throughput depending on the workload shape.
- Deployment is non-trivial. TEEs are not "tick a box on your cloud console." Provisioning, key sealing, image signing, attestation pipelines — every piece is real engineering, and the team has to build the muscle.
The honest read: TEEs are the right answer when the data is too big or too dynamic for Path A and the org has the engineering depth to operate them well. For a startup with one backend engineer? They are going to bite. For a regulated enterprise that already runs Nitro? They are a fit.
Path C: Pre-computed encrypted indexes
The path that handles a specific, important question — can the agent find records by tag? — without exposing the broader plaintext.
The idea: when a record is written, the user's client computes a deterministic encryption of certain searchable fields and stores those alongside the ciphertext. To search, the client computes the same deterministic encryption of the query term and asks the server "give me all records whose encrypted tag matches this." The server can match ciphertext-to-ciphertext without ever decrypting either side.
A worked example. A journaling MCP server. Each entry is encrypted with a per-user content key. Each tag the user adds (work, relationship, health) is encrypted with a separate deterministic key — same plaintext always produces the same ciphertext. The server stores the encrypted entry plus a list of encrypted tags. Search-by-tag works because the user's client can compute Enc("work") and ask the server for all entries whose tag list contains that value.
What this buys you: O(log n) tag search at server scale, on encrypted data, without per-record round trips. For tag-shaped queries, this is genuinely powerful and cheap.
What it costs:
- Frequency analysis. Deterministic encryption is exactly as leaky as it sounds. The server cannot read
Enc("work"), but it knows that one ciphertext appears in 80% of records and another appears in 5%. With external context (you know the user is a software developer; one of those tags is probably "work"), the encryption breaks. The longer the server runs, the more frequency data it accumulates, the worse the leak gets. - No partial-match search. "Show me records mentioning anxiety" cannot be answered by a tag index unless
anxietywas a pre-tagged field. Free-text search wants Path A or Path B. - The set of indexed fields is fixed at write time. Adding a new searchable axis means re-encrypting the whole archive. Decisions made on day one travel a long way.
This path is best as a complement to Path A. The agent uses the tag index to narrow 200,000 records down to 30, then fetches and decrypts those 30 client-side. The blind index does the cheap part; the device does the precise part.
Path D: Derived-signal-only tools
The path nobody talks about and the one that, in our experience, is the right answer most often.
The idea: design tools that do not return data at all. They return derived signals — statistics, summaries, classifications — that the server can compute from ciphertexts without reading them, or that the server's user-trusted client component computes locally and sends back as a small post-processed value.
A worked example. A finance ZK MCP server with a tool categorizeSpending({ month }). Instead of returning a list of transactions for the agent to filter, the tool returns: { categories: { "groceries": 412.30, "rent": 1200.00, ... } }. The categorization happens in a small client-side worker that has key access; it pushes only the totals back to the server, which forwards them to the agent.
The server has done no reading. The agent has gotten enough information to answer the user's question. The plaintext never left the device.
This is the architecturally cleanest path for a wide class of tools — anything where the user wants insight rather than raw records. The agent does not need the underlying journal entries to answer "how have my mood patterns changed this month?"; it needs a sentiment-time-series. Compute the time series in a place that has key access, return only the aggregate.
What this buys you: real zero-knowledge, no exotic crypto, full agent capability for the queries you are willing to specify in advance.
What it costs:
- You have to know what tools the agent will need. The narrow-funnel principle from the security post gets sharper in ZK contexts. You cannot offer
executeQuery(sql). You can offercategorizeSpending,monthlyTotal,findUnusualTransactions. The product is the catalog of tools you have committed to writing. - Adding a new query is a feature ticket. If a user wants to ask a question your derived-signal tools do not answer, you ship a new tool. There is no "the system can answer anything."
- Some questions cannot be expressed as derived signals. "Why did this happen on June 14?" needs the raw record, and you are back to Path A or B for those cases.
The honest take: this is the path most working ZK products should use, alone or in combination with the others. It forces the team to make explicit product decisions about what the agent can do, which is healthier than pretending the agent can do anything because the database is encrypted.
Combining paths
Real ZK MCP products use more than one of these. A reasonable stack for, say, a personal-finance assistant:
- Path D for everything that wants to be a single number or a small aggregate.
monthlyByCategory,unusualTransactions,cashFlowProjection. These are server-cheap, do not read plaintext, and cover most user questions. - Path C for tag-shaped retrieval.
findTransactionsByCategory,findTransactionsByMerchant. Fast, blind index, complements D. - Path A for the long tail. When the user asks something neither D nor C can answer, the agent falls back to fetching ciphertexts and decrypting on-device. Slow, but correct, and the slow path is where you want a slow path.
- Path B if and only if the product has TEE-deployment muscle. For most teams, B is overkill until the product is mature enough that one of the other paths is hitting a real wall.
The pattern: cheap paths for common cases, expensive paths for edge cases, exotic paths only when the product has shown it earns them.
What you are committing to
A theme runs through all four paths: zero-knowledge is not a feature you can add late. It is an architectural commitment that touches every tool, every storage decision, every query the agent might ever make. Adding it later means re-architecting; adding it half-way leaves the worst kind of property — a system that seems private but leaks at the seams.
Three commitments worth being explicit about, before any code:
A finite tool surface. ZK MCP servers cannot be RPC catalogs of "ask me anything." They are catalogs of tools the team has committed to building such that they do not violate the property. The narrowness is the point.
Heavier client-side work. Decryption, derivation, sometimes tool execution itself, lands on the user's device or on a trusted client component the user runs. The server gets simpler at the cost of the client getting heavier.
A real key-management story. Which is its own post — see the key recovery post — but the short version is that a ZK system without a credible recovery path is a ZK system that ships with a permanent risk of total user data loss. That is not a feature, it is a footgun, and it is the part of the system most ZK projects get wrong.
Where this sits in the series
This post is the entry point to the zero-knowledge sub-cluster. The next two posts go deep on the parts hinted at above.
If your concern is "how does the user recover after losing their phone?" — that is the key recovery post. The hardest UX problem in any ZK system, and the one that decides whether the system is shippable.
If your concern is "can the agent really not search?" — that is the searchable encryption post. The honest state of the field in 2026, including which approaches actually work in production and which are still research papers.
For the broader security context that ZK sits inside — narrow-funnel tools, per-operation scoping, audit logging — the security post is the foundation. ZK does not replace those properties; it adds another layer on top.
Zero-knowledge architectures are the most demanding shape an MCP server can take. The reward is real — there is a class of products that cannot exist without them — but the demand is total. Every tool, every read, every write either honors the property or breaks it, and there is no half-credit. The teams that ship these systems well are the ones that committed to the architecture before the first line of code, not the ones that bolted it on after.