The server cannot read your data. Not "chooses not to read." Not "promises not to read." Cannot. The server binary does not contain a decrypt function. This is not a policy. It is a compile-time structural guarantee. The code for decryption does not exist in the deployed artifact. An attacker who gains root access to the server, who dumps all memory, who disassembles the binary instruction by instruction, will not find a decrypt function because there is none to find.
And yet the server classifies your documents. It makes threshold decisions on your scores. It enforces policy based on your data's classification. It produces cryptographic attestations that prove the decision was made correctly. All of this happens on encrypted data -- ciphertexts that the server processes but cannot interpret.
This is H33-Agent-Zero. It is not a research prototype. It is a production system that processes 2,293,766 decisions per second at 38 microseconds per decision. It is built on fully homomorphic encryption, which allows computation on encrypted data without decryption. And it closes a gap that the entire encrypted computation industry has left open: the gap between knowing the answer and acting on the answer, without ever seeing either one.
What "Cannot See" Actually Means
The privacy claims in the technology industry have been degraded by overuse and underdelivery. "We don't look at your data" means "our policy says we don't, but our systems could." "End-to-end encrypted" often means "encrypted in transit, plaintext at rest, and our server has the key." "Privacy-first" usually means "we anonymize some fields and hope for the best."
H33-Agent-Zero makes a different claim, and the claim is verifiable. The server binary is compiled from source code that does not import, implement, or call any decryption routine. The FHE scheme used (a combination of CKKS for inference and TFHE for decision logic) requires a secret key for decryption. That key never leaves the client. The server holds only public keys and evaluation keys -- the keys needed to perform computation on encrypted data, not to decrypt it.
This is structurally different from access-control-based privacy. In access-control systems, the data is decryptable and the protection comes from who is allowed to decrypt it. Policies can be changed. Access can be granted. Insiders can abuse privileges. In Agent-Zero, the protection comes from the mathematics of FHE: without the secret key, the ciphertexts are computationally indistinguishable from random noise. No policy change, no insider access, no privilege escalation can produce plaintext from ciphertext without the key.
Let us be concrete about what the server sees during a classification operation. The server receives an array of encrypted 64-bit integers. Each integer is a ciphertext -- a polynomial in a ring, expanded to thousands of coefficients. The server applies the model weights to these polynomials using homomorphic operations (addition and multiplication in the ring). The server produces output polynomials that encode the classification scores -- still encrypted. The server applies threshold comparisons using TFHE Boolean circuits. The server produces an encrypted Boolean result. At every stage, the server manipulates polynomials. It never sees numbers. It never sees features. It never sees labels.
A Concrete Example: Law Firm Contract Classification
To make this tangible, let us walk through a real-world use case: a law firm that needs to classify incoming contracts for routing, access control, and compliance tagging.
The law firm receives hundreds of contracts per day. Each contract needs to be classified into categories: Employment Agreement, Non-Disclosure Agreement, Merger Agreement, Service Agreement, License Agreement, and so on. The classification determines who can access the document, which compliance rules apply, which review workflow is triggered, and how long the document must be retained.
The problem is that the contracts themselves are privileged. Attorney-client privilege, trade secrets, confidential business terms -- the content of these contracts is sensitive at every level. The law firm cannot send the contracts to a cloud-based classification service in plaintext. Even "secure" cloud services hold decryption keys or process plaintext in server memory. A breach of the classification service would expose the firm's entire contract portfolio.
Step 1: Feature Extraction and Encryption. The law firm's on-premises system extracts features from each contract. Features include clause type indicators (non-compete present, indemnification present, termination for cause), party count, monetary value ranges, jurisdiction indicators, effective date ranges, and structural features (section count, defined terms count). These features are represented as a numerical vector.
The feature vector is encrypted using the law firm's public key with the CKKS homomorphic encryption scheme. The encrypted feature vector -- a set of ciphertexts -- is sent to the Agent-Zero server. The law firm's secret key never leaves the firm's premises.
Step 2: Encrypted Classification (CKKS Inference). The server receives the encrypted feature vector and evaluates a trained classification model on it. The model's weights are known to the server (the model is not secret -- it is the data that is secret). The server performs matrix multiplications between the encrypted feature vector and the plaintext model weights. It applies activation functions (approximated as low-degree polynomials for CKKS compatibility). It evaluates layer by layer until it produces a vector of encrypted classification scores -- one score per contract category.
At this point, the server has a set of encrypted scores. It does not know which score is highest. It does not know if the contract is an NDA or a merger agreement. The scores exist as ciphertexts that the server can operate on but cannot interpret.
Step 3: Encrypted Decision (TFHE Argmax). The encrypted classification scores are bridged from the CKKS domain into the TFHE domain for discrete decision logic. The server runs an argmax tournament: pairwise GT comparisons between encrypted scores. For six categories, this requires five GT comparisons. Each 8-bit GT comparison costs 15 programmable bootstrapping operations. The tournament produces an encrypted index identifying the winning category.
The server now has an encrypted category label. It still does not know which category won. The encrypted index is a TFHE ciphertext that encodes the result without revealing it.
Step 4: Encrypted Policy Enforcement. The encrypted category label feeds into a policy engine that runs on encrypted data. The policy maps categories to access tiers:
- Merger Agreements: Tier 1 (partners only, mandatory 30-year retention, SEC compliance tagging)
- NDAs: Tier 2 (senior associates and above, 10-year retention)
- Employment Agreements: Tier 3 (HR plus assigned attorney, 7-year retention)
- Service Agreements: Tier 4 (general access, standard retention)
The policy engine evaluates encrypted comparisons to map the encrypted category to the encrypted access tier, the encrypted retention period, and the encrypted compliance tags. All of these outputs are encrypted -- the server does not know which tier, which retention period, or which compliance tags were assigned.
Step 5: Attestation. The encrypted decision (category + tier + retention + compliance tags) is attested. A 74-byte proof is generated, binding the decision to the input, the model, and the policy. The attestation is post-quantum secured with three independent hardness assumptions.
Step 6: Client Decryption. The law firm receives the encrypted decision and the attestation. Using their secret key (which never left their premises), they decrypt the decision: "This is an NDA. Tier 2 access. 10-year retention. No SEC compliance tagging." The firm's document management system applies these parameters automatically.
Throughout this entire process, the server -- which performed the classification, the decision logic, the policy enforcement, and the attestation -- never learned that the document was an NDA. It never saw the clause types, the parties, or the terms. It processed polynomials and produced polynomials. Attorney-client privilege was maintained because the system literally could not read the contract.
Why This Matters for Attorney-Client Privilege
Attorney-client privilege is one of the most zealously guarded protections in law. Once privilege is waived -- even inadvertently -- it can be difficult or impossible to reassert. Sending privileged documents to a third-party service creates a risk of waiver, even if the service has contractual confidentiality obligations.
With Agent-Zero, there is no waiver risk because there is no disclosure. The third-party service (H33) never has access to the document content. The mathematical guarantee of FHE is stronger than any contractual protection. A court cannot compel H33 to produce the document content because H33 never possessed it. The ciphertexts on H33's server are computationally indistinguishable from random noise without the law firm's secret key.
This is not a marginal improvement over existing confidentiality practices. It is a categorical change. The document's content never crosses the trust boundary. It cannot leak from the classification service because it was never there.
Beyond Classification: The Full Decision Pipeline
Document classification is the example, but the principle extends to any decision that operates on sensitive data. The same pipeline handles:
Medical triage. Patient diagnostic features are encrypted. The model classifies urgency. The policy engine assigns care tier. The attestation proves the triage decision was made according to protocol. The hospital where the computation runs never sees the patient's diagnosis.
Financial fraud screening. Transaction features are encrypted. The model scores fraud probability. Threshold logic flags transactions above the risk boundary. The attestation authorizes the flag. The screening service never sees the transaction amount, the parties, or the account numbers.
Government clearance processing. Personnel security data is encrypted. The model evaluates risk factors. Decision logic determines clearance level recommendation. The attestation records the recommendation. The processing system never sees the applicant's personal history.
Insurance underwriting. Applicant health and financial data is encrypted. The model predicts risk. Decision logic determines premium tier. The attestation authorizes the pricing decision. The underwriting platform never sees the applicant's medical records or financial statements.
In every case, the pattern is the same: sensitive data enters encrypted, computation happens on ciphertext, a decision is produced and attested, and the attestation is the only artifact that leaves the encrypted pipeline. The data stays protected by FHE throughout.
The Compile-Time Guarantee
A reasonable skeptic might ask: "How do I know the server really cannot decrypt? Maybe there is a hidden decrypt function. Maybe the evaluation key is secretly equivalent to a decryption key."
This is a valid concern, and the answer is structural rather than promissory.
First, the FHE scheme used (CKKS and TFHE) has a mathematical separation between evaluation keys and secret keys. Evaluation keys enable computation on ciphertexts. They do not enable decryption. This separation is proven in the security reduction of the schemes. An evaluation key for CKKS is a set of specially structured ciphertexts that enable key-switching and rotation operations. These ciphertexts are themselves encrypted under the scheme's parameters -- extracting the secret key from them is as hard as breaking the underlying lattice problem.
Second, the server binary is compiled from a codebase that is auditable. The Rust source code contains no decrypt function. The dependencies are pinned and auditable. The compiled binary can be reproduced from the same source and compiler version, allowing bit-for-bit verification. This is not trust-me security. It is verify-it-yourself security.
Third, even a hypothetical insider who modified the server binary to add a decrypt function would need the secret key. The secret key exists only on the client's system. It is never transmitted to the server, not even in encrypted form. The server could not decrypt even with a modified binary because it does not have the key material.
These three properties -- mathematical separation of key types, auditable source code, and client-side key custody -- compose into a guarantee that is stronger than any single property alone. Breaking the system requires simultaneously compromising the mathematical proof, the code audit, and the client's key storage. Any single compromise is insufficient.
How This Differs from "Privacy-Preserving AI"
The term "privacy-preserving AI" covers a range of techniques with very different security properties. It is worth being precise about how Agent-Zero compares to the alternatives.
Differential privacy adds calibrated noise to data or query results to limit what can be inferred about individual records. The server still processes plaintext data. The protection is statistical, not absolute -- given enough queries, an adversary can narrow down individual values. Differential privacy is a valuable technique for aggregate analytics, but it does not protect individual records during computation. The server sees the data.
Federated learning keeps data on client devices and trains models by aggregating gradients rather than centralizing data. The server sees model gradients, not raw data. However, gradient attacks can reconstruct training data from gradients in many cases. The protection is heuristic, not provable. And federated learning addresses model training, not inference or decision-making.
Secure enclaves (Intel SGX, ARM TrustZone) create hardware-protected execution environments where data is decrypted and processed in a secure region of the CPU. The data IS decrypted -- the protection comes from hardware isolation, not from keeping data encrypted. Side-channel attacks, speculative execution attacks (Spectre, Meltdown), and enclave extraction attacks have repeatedly compromised secure enclaves. The data is plaintext during processing; the protection is hardware, not mathematics.
Multi-party computation (MPC) splits data across multiple servers so that no single server sees the complete data. This provides strong privacy guarantees when the non-collusion assumption holds. But MPC requires multiple independent servers, significant communication overhead, and breaks if servers collude. The privacy guarantee is conditional on the servers being truly independent.
Fully homomorphic encryption (FHE) -- what Agent-Zero uses -- keeps data encrypted throughout computation. The server never sees plaintext. The protection is mathematical: without the secret key, ciphertexts are indistinguishable from random noise under standard lattice hardness assumptions. No hardware trust, no non-collusion assumptions, no statistical noise budgets. The data is never decrypted on the server. Period.
Each technique has its place. Differential privacy excels at aggregate analytics. Federated learning excels at distributed model training. Secure enclaves provide reasonable protection with minimal performance overhead. MPC enables collaborative computation across organizations. FHE provides the strongest single-server privacy guarantee at the highest computational cost.
Agent-Zero pays the computational cost of FHE because the use cases demand it. When a law firm's attorney-client privilege, a patient's medical records, or a government's classified data is at stake, "statistical noise" and "hardware isolation" are not sufficient. The guarantee must be mathematical and unconditional on hardware trust.
The One-Liner
H33-Agent-Zero is a system where encrypted data is classified, decisions are made over ciphertext, and those decisions are cryptographically enforced without ever exposing the underlying data.
That sentence describes the complete system. Data enters encrypted. The CKKS inference layer classifies it. The TFHE decision layer makes discrete choices about it. The policy enforcement layer takes action based on it. The attestation layer proves it all happened correctly. And at no point in this pipeline does any component see, access, or reconstruct the plaintext data.
The one-liner is not marketing language. It is a technical specification. Each clause maps to a specific layer of the system, and each layer has a provable security guarantee. "Encrypted data is classified" = CKKS inference on ciphertexts. "Decisions are made over ciphertext" = TFHE Boolean circuits on encrypted values. "Cryptographically enforced" = 74-byte PQ attestation with three independent hardness assumptions. "Without ever exposing the underlying data" = no decrypt function in the server binary, no secret key on the server, no plaintext in server memory.
Scale and Performance
The historical objection to FHE has been performance. Early FHE systems were millions of times slower than plaintext computation. That era is over.
Agent-Zero processes 2,293,766 decisions per second at 38 microseconds per decision. This is the full pipeline throughput -- not a microbenchmark of a single operation, but the sustained rate of the complete system including CKKS inference, TFHE decision logic, policy enforcement, and PQ attestation.
The system uses 4096 SIMD (Single Instruction, Multiple Data) slots within the FHE ciphertexts, enabling batch-parallel processing. Multiple documents, multiple feature vectors, and multiple decisions are processed simultaneously within each ciphertext. This is not a trick or an amortization -- it is a fundamental property of the lattice-based encryption scheme that the system exploits for throughput.
For the law firm example, this means the firm's entire daily intake of hundreds of contracts can be classified in a fraction of a second. The bottleneck in a real deployment is not the encrypted classification -- it is the feature extraction and encryption on the client side, which is a standard computational task.
What We Are Not Claiming
Honesty about limitations is part of the specification. Here is what Agent-Zero does NOT do:
It does not protect against a compromised model. If the classification model itself is biased, backdoored, or incorrect, the encrypted computation will faithfully produce biased, backdoored, or incorrect results on encrypted data. FHE guarantees that computation is correct (the same result as plaintext computation on the same inputs), not that the computation is wise. Model auditing and validation remain necessary and are separate concerns.
It does not hide the computation being performed. The server knows which model it is evaluating, how many layers deep the computation goes, and what policy rules it is applying. It is the DATA that is hidden, not the PROGRAM. An adversary who knows the model architecture and observes computation patterns cannot learn the data, but they can learn the model structure (which is not secret in this architecture -- the model is a known, audited artifact).
It does not eliminate the need for the client to eventually decrypt. The law firm must eventually decrypt the classification result to act on it in their own systems. The protection is that the decryption happens on the firm's premises, under their control, with their key. The classification service never decrypts. But the client must.
It does not make FHE free. The encrypted computation is more expensive than the equivalent plaintext computation. The 38 microseconds per decision includes the overhead of operating on ciphertexts rather than plaintext values. For throughput-sensitive applications, this is the price of mathematical privacy. For most enterprise applications -- particularly those handling privileged legal documents, medical records, or classified data -- the price is negligible relative to the value of the data being protected.
The Broader Implication
Agent-Zero represents a shift in how we think about AI and privacy. The prevailing assumption in the industry is that AI systems must see data to make decisions about data. This assumption drives the architecture of every cloud ML service: data flows to the model, the model processes plaintext, results flow back. Privacy protections are layered on top -- access controls, audit logs, data minimization policies -- but the fundamental architecture requires plaintext data on the server.
Agent-Zero inverts this assumption. The AI does not see the data. It computes on the mathematical representation of the data (the ciphertext), which is indistinguishable from noise without the key. The decisions are correct -- the same decisions the model would make on plaintext data -- but the data's content is never accessible to the system making the decisions.
This is not a philosophical distinction. It is an architectural one with practical consequences. Systems that see data can leak data. Systems that cannot see data cannot leak it. The attack surface reduction is categorical, not incremental. There is no configuration error, no insider threat, no zero-day exploit that can cause Agent-Zero to reveal data it never possessed.
We built an AI that makes decisions on encrypted data. It classifies without seeing. It decides without knowing. It enforces without accessing. And it proves it all with a 74-byte attestation that any system can verify.
The server has no secret key. The server binary has no decrypt function. The data never leaves its encryption. And the decisions are mathematically correct.
That is H33-Agent-Zero.