An AI agent is only as safe as whoever holds its secrets. A leaked credential isn't just one exposed record. It's standing access to everything behind it. So where those secrets live is the whole question.
This week we kick off a three-part tour of the OpenMatter trust layer, one article for each product a workload passes through. We start where you can click: Datavizor, the console, and the question underneath every secret it stores — who can read it, and how the answer is no one.
Stay up to date as we build the infrastructure layer for secure AI collaboration.
OpenMatter is chairing the Decentralized AI Agent Alliance’s Agentic Privacy & Security subgroup. The next meeting will be held on July 29, 2026 at 1pm EDT, and will continue every other Wednesday thereafter. Please join us.
The Committee That Never Holds the Key
The Plaintext Never Leaves Your Machine While the Key Is Never Whole
To be useful, an AI agent has to hold the keys to something, whether a database, an inbox, a payments API, or an internal tool. To host that agent somewhere other than your own machine, someone else has to hold those keys too, at least long enough to hand them over when the agent starts working. The security of the whole arrangement comes down to who holds those keys.
Most answers rely on a custodian you have to trust. A cloud KMS: trust the provider. A hardware enclave: trust the chip vendor. A secrets manager: trust the operator. The custodian holds your actual keys, so your safety rests on the promise that it will behave.
Last week’s Datavizor 101 was the tour of the OpenMatter console — sign in, fund a project, launch an app. This article goes underneath the console, to the part that answers a foundational question: who holds an agent’s secrets, and can they read them? Datavizor’s answer is to build a custodian designed to be incapable of reading the keys it holds.
A Key That Was Never Assembled
When you store a secret in Datavizor, you encrypt it under a master public key. The encrypting happens in your browser, before anything is sent. What travels across the network is already ciphertext; the plaintext value of your secret never leaves your machine. That is the first half of the answer to the question above: the secret isn’t held on a server, because it never reaches one to begin with.
And the matching private key is never assembled anywhere: not on a provider’s disk, nor in the console’s memory. Instead, the key was generated in fragments, across a set of independent nodes called the key generation committee, and each node holds only a share. There is no moment in the key’s life when it sits somewhere waiting to be stolen, because it is never, anywhere, whole.
Reading a secret back works without ever changing that. To decrypt — to let an agent, or another user, or a scoped API key retrieve the value — at least three of the committee’s five nodes each perform a partial decryption with their own share, and only the combination of those partials recovers the plaintext. Any two nodes, cooperating or compromised together, learn nothing at all.
The Custodian That Doesn’t Sit Still
A textbook threshold scheme stops here: five nodes, three to decrypt. But OpenMatter’s threshold scheme keeps going. The key generation committee is not a fixed body. Its members can shift without changing the master public key. Everything you have already encrypted still resolves afterward; the public key is the same key it always was. But the set of parties actually holding shares gets rotated underneath it, as often as daily.
Think about what that does to an attacker. Against a fixed custodian, patience works: learn the members, work them one at a time, and wait for the opening. Against a committee that reshuffles before you have finished mapping it, patience is useless: you would need to breach enough nodes in the moving set at the same moment, then a different set tomorrow, and again the day after. And nothing has to be re-encrypted for any of it because the public key never changed.
What This Layer Is For
Datavizor does not ask you to trust a better custodian for your agents’ secrets. It arranges for there to be no custodian at all — no single party, and not even a stable set of parties, that can read what you stored.
Holding an agent’s secret so no one can read it at rest is one problem. Governing what the agent is allowed to do once it has that secret in hand — which calls it can make, which endpoints it can reach, and what leaves the boundary — is a different problem, and a different part of the tech stack. That one gets its own proof, and its own article, next week.
— The OpenMatter Team
If you know someone who would benefit from reading this article, please share it:
OpenMatter is building the verifiable trust layer that enables AI agents to securely collaborate on sensitive data sets. If you’re in a regulated industry and need a better way to prove that your data is secure, contact our team to learn how masked compute can help.
Fascinating approach to secret management! The idea of a "committee that never holds the key" is elegantly simple yet powerful.