The encrypted inference problem is solved. Multiple teams -- academic and commercial -- have demonstrated neural networks running on encrypted data. CKKS-based inference, BFV-based classification, even TFHE-based bit-level computation. The papers are published, the benchmarks are cited, and the conference talks are given. Encrypted inference is a known quantity.
But here is the question nobody is asking: what happens after inference?
The model produces an encrypted label. "Fraud" or "Not Fraud." "Approve" or "Deny." "Tier 1" or "Tier 3." That label is encrypted, sitting in a ciphertext on the server. Now what? In every system we have evaluated -- every academic prototype, every commercial offering, every open-source framework -- the answer is the same: someone decrypts it.
A human or a plaintext system reads the label, decides what to do, and takes action. That decryption step is the exposure. That is where the privacy guarantee breaks. And that is the gap that H33-Agent-Zero closes.
The Decryption Gap
Let us trace the full lifecycle of an encrypted inference in a typical system. A client encrypts their data -- say, a set of financial features for a credit decision. The encrypted features are sent to a server running an FHE-based model. The server performs encrypted inference: matrix multiplications, activations, pooling layers -- all on ciphertexts. The server produces an encrypted classification result.
At this point, the server cannot read the result. The encryption is intact. Privacy is preserved. This is the part that gets published in papers and demonstrated at conferences. This is where the story usually ends.
But the story does not end. The encrypted result must be sent back to the client. The client decrypts it. The client reads "Approved" or "Denied." The client then needs to act on that decision -- update a database, trigger a workflow, notify a downstream system, generate a compliance record.
The moment the client decrypts the label, a plaintext classification result exists in memory. That plaintext result can be logged, intercepted, modified, or leaked. If the client system is compromised, the attacker gets the classification result. If the client is a regulated entity, they now have a plaintext record that falls under data governance requirements. If the classification is sensitive -- a medical diagnosis, a fraud flag, a security clearance determination -- the plaintext label is itself a privacy exposure.
Worse, the enforcement decision -- what to actually DO based on the classification -- happens in plaintext. A separate system reads the label, applies business logic, and takes action. That business logic runs on unencrypted data. The enforcement step, which is where the real-world impact occurs, has no cryptographic protection at all.
Why Classification Is Not Enforcement
Classification answers a question: "What category does this input belong to?" Enforcement takes an action: "Based on that category, here is what happens next." These are fundamentally different operations, and conflating them is the central mistake of existing encrypted ML systems.
Consider a healthcare example. An encrypted ML model classifies a patient's diagnostic data and produces an encrypted label: "High Risk." In a classification-only system, the hospital decrypts the label, reads "High Risk," and then a care coordinator manually assigns the patient to an intensive monitoring program. The classification happened in the encrypted domain. The enforcement happened in plaintext.
Now consider what enforcement looks like when it stays encrypted. The encrypted "High Risk" label feeds directly into an encrypted policy engine. The policy engine evaluates: if risk level greater than threshold, assign monitoring tier 3. That evaluation happens on the encrypted label. The output is an encrypted action token: "Assign to Tier 3 monitoring." That token is attested -- a 74-byte cryptographic proof that the policy was evaluated on the classification result and the action is authorized. The downstream monitoring system accepts the attested action token and provisions the resources. At no point did any system see the plaintext label "High Risk" or the plaintext action "Tier 3."
This is the difference between encrypted inference and encrypted enforcement. Inference produces an encrypted answer. Enforcement produces an encrypted action with cryptographic proof of authorization.
The Classification IS the Control Plane
In H33-Agent-Zero's architecture, there is no gap between classification and enforcement. The classification output does not get decrypted and fed into a separate enforcement system. Instead, the classification output IS the input to the enforcement circuit. The enforcement circuit IS part of the same encrypted pipeline. And the output of the enforcement circuit IS a binding, attested action.
This is what we mean by "the classification IS the control plane." The ML model's output is not informational -- it is operational. It does not advise a human to take action. It authorizes action directly. The cryptographic attestation that accompanies the action proves that the authorization derived from a valid classification on valid encrypted data, evaluated through a valid policy, without any intermediate decryption.
The pipeline has four stages, and all four run on encrypted data:
Stage 1: CKKS Inference. The input data (encrypted floating-point features) passes through a neural network evaluated in the CKKS domain. CKKS supports the approximate arithmetic needed for matrix multiplications, activations, and normalization layers. The output is a vector of encrypted classification scores -- one per class.
Stage 2: TFHE Decision. The encrypted classification scores are converted from the CKKS domain to the TFHE domain for discrete decision logic. TFHE handles the threshold comparisons, argmax tournaments, and band classifications that convert continuous scores into discrete decisions. The output is an encrypted decision: which class, which tier, which action.
Stage 3: Policy Enforcement. The encrypted decision feeds into a policy engine that evaluates business rules on the encrypted decision. If the decision is "High Risk" and the policy says "High Risk triggers enhanced monitoring," the policy engine produces an encrypted action token encoding "enhanced monitoring." The policy evaluation happens entirely on encrypted values.
Stage 4: Attestation. The encrypted action token is attested -- a 74-byte proof is generated that binds the action to the classification, the policy, and the input data. The attestation is post-quantum secured with three independent hardness assumptions. It is portable: any system can verify the attestation without accessing the model, the data, or the policy engine.
No decryption occurs at any stage. The entire pipeline -- from raw encrypted features to attested action -- runs without the server ever having access to a secret key.
Decision Finality
The concept that emerges from this architecture is decision finality. A decision is final when it is: (1) derived from a valid computation on valid inputs, (2) bound to a specific policy that authorized it, (3) cryptographically attested so it cannot be disputed or altered, and (4) actionable by downstream systems without re-evaluation.
Decision finality is the property that existing encrypted inference systems lack. When an encrypted ML system produces an encrypted label and the client decrypts it, the label has no finality. It is just a value. The client can change it. The client can claim the model said something different. There is no binding between the classification and the action that follows. There is no proof that the action was authorized by the classification.
With Agent-Zero, the attested action token IS the final decision. It cannot be altered because it is cryptographically signed. It cannot be disputed because the attestation includes a commitment to the input data and the policy. It cannot be replayed because the attestation is bound to a specific computation instance. And it is actionable because downstream systems can verify the attestation and execute the action without needing to re-run the model or re-evaluate the policy.
This is not a theoretical improvement. It solves real operational problems. In financial services, regulators need to verify that a credit decision followed the institution's stated policy. With decision finality, the attestation proves it -- without the regulator needing access to the customer's data or the bank's proprietary model. In healthcare, a treatment decision needs to be traceable to a diagnostic classification. The attestation provides that traceability without exposing the patient's medical records.
The Exposure Window Problem
Every system that decrypts between inference and enforcement creates an exposure window. The exposure window is the duration between when a plaintext classification result exists and when it is either acted upon or destroyed. During the exposure window, the result is vulnerable to interception, modification, logging, and exfiltration.
In practice, exposure windows are not brief. A decrypted classification result often persists in memory, in logs, in message queues, in database records, and in audit trails. Each copy extends the exposure window. Each system that handles the plaintext result becomes part of the attack surface. A breach of any one of those systems compromises the classification result.
Agent-Zero eliminates the exposure window by eliminating decryption. There is no plaintext classification result. There is no plaintext enforcement decision. There is only an encrypted pipeline that produces an attested action token. The token itself is not a secret -- it is a proof. Anyone can read the attestation and verify that a valid decision was made. But the attestation does not reveal what the decision was based on, what the classification scores were, or what the input data contained.
This is a fundamental architectural difference, not an incremental improvement. You cannot reduce the exposure window to zero by making decryption faster or by encrypting the result at rest after decryption. The only way to eliminate the window is to never create it. Agent-Zero never creates it.
Why Competitors Stop at Inference
The reason most encrypted ML systems stop at inference is architectural, not technical. Building encrypted inference requires one FHE scheme (typically CKKS for neural networks). Building encrypted enforcement requires a second FHE scheme (TFHE for discrete decision logic) and the ability to bridge between them. Building attested enforcement adds a third layer (post-quantum signatures for the attestation).
Most teams have deep expertise in one scheme. They build a CKKS inference engine and call it done. The enforcement step is left to the application layer -- decrypt the result and handle it in plaintext. This is not laziness; it is a scoping decision. Building a multi-scheme pipeline that bridges CKKS inference to TFHE decisions to PQ attestation is a fundamentally different engineering challenge than building a single-scheme inference engine.
The bridge between CKKS and TFHE is particularly challenging. CKKS operates on approximate real numbers with a noise budget. TFHE operates on exact bits with programmable bootstrapping. Converting a CKKS ciphertext (an encrypted floating-point score) into a TFHE ciphertext (encrypted bits suitable for threshold comparisons) requires careful management of precision, noise, and encoding. This is not a standard operation in any FHE library. It is a custom engineering effort that requires deep understanding of both schemes.
H33 invested years building this bridge because enforcement is where the value is. Inference without enforcement is a demonstration. Enforcement without inference is a static rule engine. The combination -- encrypted data flows through ML inference, through decision logic, through policy enforcement, and produces an attested action -- is the complete system.
The Attestation as Enforcement Authority
The 74-byte attestation that Agent-Zero produces is not just a receipt. It is an enforcement authority. Downstream systems accept the attestation as proof that an action is authorized, without needing to verify the authorization themselves.
Consider a multi-party workflow. Bank A runs an encrypted credit model on a customer's data. The model classifies the customer. The policy engine produces an attested action: "Approved for Tier 2 credit." Bank A sends the attestation to Credit Bureau B. Bureau B verifies the attestation (a fast, public operation that requires no secret keys) and updates the customer's record. The customer's data never left Bank A. The model never left Bank A. The policy never left Bank A. But the decision is now trusted by Bureau B because the attestation proves it was validly derived.
This is cross-system enforcement without data sharing. The attestation travels across organizational boundaries while the data, the model, and the policy stay within their respective boundaries. This is fundamentally different from existing approaches where cross-system decisions require either data sharing (violating privacy) or duplicate computation (wasteful and inconsistent).
The attestation also serves as a compliance record. Regulators can verify that decisions were made according to policy without accessing the underlying data. Auditors can confirm the chain of computation without re-running the model. Legal teams can produce the attestation as evidence of process integrity without disclosing sensitive information.
Concrete Example: Insurance Claims Processing
An insurance company receives a claim. The claim data -- damage photographs, repair estimates, policy details, historical claim patterns -- is encrypted at the point of collection. The encrypted claim data enters the Agent-Zero pipeline.
CKKS inference evaluates the claim against a fraud detection model. The model produces encrypted scores for three classes: Legitimate, Suspicious, and Fraudulent. These scores are encrypted floating-point values that the server cannot read.
TFHE decision logic evaluates the encrypted scores. An argmax tournament determines the top class. A threshold comparison checks the margin between the top two classes. If the margin exceeds the confidence threshold, the decision is final. If not, the decision is flagged for review.
The policy engine evaluates the encrypted decision against the company's claims policy. A legitimate claim above the auto-approval threshold generates an encrypted action: "Auto-approve, disburse payment." A suspicious claim generates a different action: "Route to senior adjuster, flag for enhanced review." A fraudulent claim generates: "Deny, notify SIU."
Each action is attested with a 74-byte proof. The auto-approval attestation travels to the payment system, which verifies it and disburses funds. The routing attestation travels to the workflow system, which assigns the case to a senior adjuster. The denial attestation travels to the SIU notification system.
At no point did any system see the claim data in plaintext. The fraud detection model ran on encrypted data. The decision logic ran on encrypted scores. The policy engine ran on encrypted decisions. And the downstream systems acted on attested tokens, not plaintext labels.
The Pipeline in Practice
The four-stage pipeline is not a theoretical architecture. It is a production system running on H33's infrastructure. The CKKS inference stage handles encrypted floating-point computation with 4096 SIMD slots for batch processing. The TFHE decision stage uses 8-bit GT comparisons (15 PBS per comparison) for threshold logic. The policy engine chains GT comparisons into decision trees and band classifications. The attestation stage produces 74-byte proofs secured with three independent hardness assumptions.
The system processes decisions at production speed because each stage is optimized for its specific workload. CKKS is optimized for dense matrix arithmetic. TFHE is optimized for sparse Boolean logic. The attestation is optimized for compact proof generation. And the bridge between CKKS and TFHE is optimized for minimal precision loss during domain conversion.
The result is a system where 2,293,766 authentication decisions per second flow through the full pipeline -- from encrypted input to attested action -- at 38 microseconds per decision. This is not a batch throughput number achieved by cutting corners. It is sustained throughput on the full four-stage pipeline with all cryptographic guarantees intact.
What Changes When Enforcement Is Encrypted
When enforcement moves into the encrypted domain, several downstream changes follow.
First, audit becomes non-invasive. Regulators verify attestations, not data. They confirm that decisions followed policy without seeing the inputs or outputs of those decisions. This eliminates the tension between regulatory oversight and data privacy -- a tension that currently forces companies to choose between compliance and confidentiality.
Second, multi-party decisions become trustless. When Bank A's decision attestation is accepted by Bureau B, neither party needs to trust the other's data handling practices. The attestation is a mathematical proof, not a contractual promise. This enables new collaborative workflows that are currently impossible due to data sharing restrictions.
Third, liability is provable. If a decision is challenged, the attestation proves exactly what happened: what policy was applied, when it was applied, and that it was applied to encrypted data that was never exposed. This is a stronger liability position than "we followed our internal processes," which requires trusting the institution's account of what happened.
Fourth, the attack surface shrinks dramatically. A system that never decrypts cannot leak plaintext through memory dumps, log files, message queues, or database records. The attack surface reduces to the cryptographic primitives themselves, which are well-studied and provably secure under standard assumptions.
Conclusion: Close the Gap
Encrypted inference is a solved problem with an unsolved consequence. The consequence is that every system that decrypts after inference creates an exposure that undermines the entire purpose of encrypting in the first place. If you encrypt data for privacy and then decrypt the decision for enforcement, you have protected the input but exposed the output. The output -- the classification, the decision, the action -- is often more sensitive than the input.
H33-Agent-Zero closes the gap. The classification output is the binding policy decision. The attestation is the enforcement authority. Downstream systems accept it without re-evaluation, without accessing the model, without seeing the data. This is decision finality: end-to-end encrypted computation that produces actions, not just answers.
The industry has spent a decade building encrypted inference. It is time to build encrypted enforcement.