The Secret Problem
Every useful AI agent operates over credentials. A customer support agent needs database credentials. A DevOps agent needs cloud API keys. A financial agent needs payment authorization tokens. Without these secrets, agents cannot function. With them, we introduce vulnerabilities.
Traditional secret management concentrates trust in a single party. A centralized vault, an environment variable injected by a hosting provider, a key management service operated by one vendor. Every conventional approach means that someone can read every secret. A single breach, a single compromised insider, a single legal compulsion, and every agent’s credentials are exposed at once.
This is not a theoretical concern. It’s the architecture. And it is the same architecture we have spent decades trying to secure for human employees, except agents operate faster, at greater scale, and with less oversight. An agent can exfiltrate an entire database in seconds. An agent can be hijacked to take arbitrary actions with whatever permissions it holds. When an agent accesses the wrong data partition, it may leave no human-readable evidence at all.
The threat compounds further. Nation-state adversaries are executing harvest-now-decrypt-later campaigns: intercepting encrypted traffic today, stockpiling it for decryption once quantum hardware matures. Every API key transmitted under RSA or elliptic curve encryption is on a countdown timer.
The question is not whether these systems will be attacked. The question is whether the cryptographic foundation can survive when they are.
Distributing Trust: No Single Point of Failure
The core insight is straightforward: if no single party ever holds the master decryption key, no single party can be compromised to reveal it. OpenMatter’s hosting layer implements this through threshold cryptography. The master key is distributed across a Key Governance Committee (KGC) of independent nodes via a protocol called Distributed Key Generation (DKG).
The implementation begins with each KGC node independently generating a local secret key. This secret becomes the constant term of a bounded Shamir polynomial — a degree-(t-1) polynomial whose evaluation at each peer’s identifier produces a share of the secret. The threshold parameter t defines the minimum number of nodes that must collaborate to decrypt anything. Any t-1 or fewer compromised nodes learn zero information about the master key. This privacy guarantee stems from the mathematical properties of polynomial interpolation rather than a trusted software setup.
But Shamir’s secret sharing alone is not enough. A malicious node could distribute inconsistent shares, giving different parties values that correspond to different polynomials. The system guards against this with Feldman commitments: each node commits to every coefficient of its Shamir polynomial using an RLWE-based (Ring Learning with Error) commitment scheme. These commitments bind polynomial coefficients and keep them hidden, while remaining publicly verifiable. When a node receives a share, it checks the share against the dealer’s published commitments. If the share doesn’t match, the node rejects it in a single round. Invalid contributions are detected, allowing the corresponding dishonest dealers to be identified, accused, and excluded before they can corrupt the master key.
For our lattice-based encryption/decryption to work, we enforce strict smallness checks on the above parameters during the KGC setup. Specifically, to guarantee the validity of secret keys, each commitment is accompanied by a Zero-Knowledge Proof of Shortness (ZKPoS). This proof demonstrates that the committed polynomial coefficients are genuinely small, as required for the RLWE encryption scheme to remain valid, without revealing the coefficients themselves. Thus, a malicious node cannot commit to artificially large coefficients that surpass the allowed upper bound, which would otherwise bias the joint private key and invalidate subsequent encryption/decryption.
The DKG output is elegant: every node holds an aggregated key share, all nodes agree on a joint public key, and each node has a verifiable commitment to its share. The full private key was never assembled. It does not exist in any single location, in any single memory space.
The Deployment Lifecycle
When an enterprise deploys an agent, four phases execute in sequence. Each is designed so that no participant (not the enterprise, not the hosting provider, not any individual KGC node) ever has access to the agent’s secrets outside the running process.
Phase 1: Encryption
The enterprise samples a random polynomial from the plaintext domain and encrypts it under the KGC’s joint public key as an RLWE capsule. This capsule is computationally indistinguishable from random noise under the RLWE assumption. An observer cannot distinguish it from random ring elements. The enterprise also generates a ZKP of Plaintext Well-Formedness proving the capsule is a valid encryption (not a malformed ciphertext designed to attack the KGC). From the same random polynomial and the deployment identifier, a symmetric AES-256-GCM key is derived, and the agent’s actual secrets (database URLs, API keys, tokens) are encrypted under that key.
The construction is hybrid: lattice-based key encapsulation handles the asymmetric portion, while AES-256-GCM handles bulk encryption of arbitrarily-sized secrets. The Associated Authenticated Data (AAD) for the AEAD binds the ciphertext to the deployment ID, the deployment configuration, and the RLWE capsule itself. This prevents substitution attacks: if an attacker detaches a symmetric ciphertext from its original deployment and reattaches it to a different deployment ID, configuration, or capsule, the AAD mismatch causes authenticated decryption to fail. Secrets are cryptographically locked to the exact deployment context in which they were created.
Phase 2: Assignment
The hosting provider is selected and authorized to run the agent. Critically, the provider is assigned after the secrets are encrypted. The provider never sees unencrypted secrets and has no role in key management.
Phase 3: Threshold Decryption
Each KGC node computes a partial decryption using its private key share and returns it to the hosting provider deployment process. Each partial decryption contributes one piece of the puzzle without revealing the node’s share. To statistically hide partial key information from the partial decryptions themselves, each node adds carefully calibrated smudging noise: uniform randomness from a smudge domain and added to the partial decryption. This noise is large enough to statistically mask any secret information in the partial computation, but small enough that it doesn’t corrupt the plaintext stored in the lower-order bits.
Each node also generates a ZKP of Correct Partial Decryption alongside its partial decryption, proving that its partial decryption is consistent with those public key share commitments. This catches malicious nodes that attempt to submit garbage partial decryptions to corrupt the result. Faulty contributions are identified and excluded before final aggregation by the deployment process.
Phase 4: Recovery and Zeroization
The hosting provider’s runtime aggregates the verified partial decryptions, recovers the plaintext polynomial through Lagrange interpolation, derives the symmetric key, and decrypts the agent’s secrets. The agent launches.
Immediately afterward, all cryptographic key material is securely erased: the plaintext polynomial, the derived symmetric key, every intermediate aggregation value. This enforces forward secrecy, assuming the provider correctly zeroizes all key material. Even full compromise of the hosting provider after deployment execution cannot recover the previous secrets. An attacker would need to break an RLWE instance or re-coordinate the full threshold decryption from scratch.
Why Lattices, and Why Now
The entire hosting layer is built on the Ring Learning With Errors (RLWE) problem — a lattice-based hardness assumption that forms the foundation of NIST’s recently standardized post-quantum cryptographic suite. Concretely, NIST’s FIPS 203 and FIPS 204 (August 2024) standardized ML-KEM and ML-DSA (both built on structured lattice problems closely related to RLWE) as the primary post-quantum primitives for government and critical-infrastructure use.
Our implementation operates in the cyclotomic polynomial ring with a 4098-degree polynomial and a 109-bit prime modulus. This provides approximately 128 bits of classical security and 120 bits of post-quantum security, aligning with NIST’s recommended strength for long-term protection.
Why does this matter for AI agents? Agent secrets (database credentials, API keys, signing tokens) are uniquely vulnerable to harvest-now-decrypt-later attacks because they are both long-lived and high-value. Unlike a TLS session key that expires in hours, a single compromised agent credential can grant persistent access to infrastructure, exfiltrate training data, or impersonate the agent across services. An adversary who records today’s ciphertext under RSA or ECC needs only one future quantum capability to unlock all of it at once. Recent work from Google Quantum AI and Stanford (Boneh et al., March 2026) underscores the urgency: optimized quantum circuits can target secp256k1 with fewer than 500,000 physical qubits, down from millions in prior estimates just a few years earlier. The timeline for practical quantum attacks is compressing faster than previously assumed. Lattice-based cryptography closes this window entirely: no known quantum algorithm provides a meaningful speedup against RLWE, making the protection time-horizon independent.
Three Zero-Knowledge Proofs, Three Threat Boundaries
The protocol faces three distinct adversarial threats: malicious KGC nodes (up to t−1) that may corrupt key generation, malicious key nodes that may corrupt decryption, and a fully malicious client that may submit invalid ciphertexts. Each threat is addressed by a dedicated zero-knowledge proof to enforce honest behaviour of the adversary without revealing its internal secret key material, ensuring that no single party can corrupt the protocol undetected. All three proofs follow Lyubashevsky’s Fiat-Shamir with Aborts framework: it achieves zero-knowledge by using rejection sampling to ensure accepted responses are statistically independent of the witness, and achieves soundness by requiring the prover to commit to masking randomness before the challenge is determined, preventing adaptive manipulation of the response. Specifically, they target key generation, encryption, and decryption, respectively:
ZKP of Shortness (ZKPoS): During DKG, each node proves its committed polynomial coefficients have small norms. This prevents a malicious node from injecting disproportionately large coefficients that overflow the noise budget during decryption. The witness is the polynomial coefficient and its commitment noise, and the relation is the Feldman commitment equation linking them to the public commitment. The verifier checks that the response norms fall within the coefficient bound and that this equation holds, with a soundness slack factor κ absorbed by downstream parameters.
ZKP of Plaintext Well-Formedness: When the enterprise submits its encrypted capsule, it proves the ciphertext is a valid BGV encryption: that it was computed using properly sampled randomness and noise, not crafted to extract information from the KGC during decryption, and that the noise is bounded so the ciphertext remains decryptable. The proof covers both components of the ciphertext simultaneously, ensuring the encryption randomness and noise terms are genuinely short.
ZKP of Correct Partial Decryption: During threshold decryption, each KGC node proves three properties: (1) its partial decryption is consistent with its committed key share, (2) the share has bounded norm, preventing adversarial key material, and (3) the smudging noise is within the prescribed bound, preventing noise overflow that causes decryption failure. The proof simultaneously binds two equations: the partial decryption equation (relating the partial output to the ciphertext and key share) and the Feldman commitment equation (relating the key share to the public commitment). A malicious node cannot substitute a fake key share, inject adversarial key material, or inject unbounded noise without the proof failing.
From Theory to Running Code
The full protocol has been validated end-to-end over genuine TCP connections: five KGC nodes complete DKG with Feldman commitments and shortness proofs, an enterprise encrypts and proves well-formedness, three nodes compute verified partial decryptions, and a deployment process aggregates and recovers the original secrets.
The system handles the engineering details that separate a paper protocol from a deployable one. Performance-critical arithmetic is handled through Number Theoretic Transforms (NTT) for ring multiplication, with CRT representation for pointwise operations and power-basis conversion for the norm checks that zero-knowledge proofs demand. Serialization uses bincode for compact wire encoding. The network layer supports both broadcast and point-to-point messaging patterns required by the DKG and decryption protocols.
The resulting performance is practical. DKG is a one-time cost per committee formation. The online phase (encryption, proof generation, threshold decryption, and secret recovery) runs in the range of seconds, dominated by zero-knowledge proof computation. For an agent deployment that happens once and then runs for hours or days, this is a negligible overhead.
What This Means for the Agentic Economy
The agentic economy is accelerating. Enterprises are deploying autonomous agents that access sensitive data, call external APIs, and make decisions at machine speed. The security question is the same one we have asked about employees for decades: how do we prevent the entities we empower from leaking data, being manipulated, or acting beyond their authority?
Post-quantum threshold cryptography addresses this at the infrastructure layer. No single party ever sees agent secrets in the clear. The master key is never reconstructed. Decryption requires collaboration among independent nodes, each proving its honesty through zero-knowledge proofs. Forward secrecy, contingent on correct zeroization by the hosting provider, ensures secrets are irrecoverable after use. The entire construction rests on lattice hardness, immune to the quantum attacks that will eventually break conventional public-key cryptography based on integer factorization (RSA) and elliptic curve discrete logarithms (ECDSA, ECDH).
This represents a structural shift from centralized key management: trust is distributed across independent parties, and the security guarantee is enforced by mathematics rather than policy.