The Problem With Seeing Data to Decide About It
Every compliance engine, credit scoring system, and insurance underwriting model in production today shares the same fundamental design flaw: they must decrypt data before making decisions about it. A credit decisioning system needs to see your income, your debt-to-income ratio, and your payment history in order to determine whether you qualify for a loan. An insurance underwriter needs to see your age, your medical history, and your driving record before pricing your policy. A compliance rule engine needs to read your transaction details before deciding whether to flag it for review.
This design requirement seems so obvious that it barely warrants stating. Of course you need to see data to make decisions about it. How could it be otherwise?
But this assumption creates an enormous attack surface. Every system that reads data to decide about it is a system where data is exposed in plaintext. Every credit bureau query, every insurance underwriting platform, every compliance screening tool is a place where sensitive information exists unencrypted in memory, on disk, or in transit. The decision-making step is the exposure step. They are inseparable in traditional architectures.
At H33, we have separated them. Our TFHE-based encrypted decision tree engine evaluates branching logic on fully encrypted features. The tree structure -- the model itself -- is public and known. The feature values flowing through it are encrypted. The server evaluates every branch of the tree, but it cannot see which branch was taken, what the input values are, or what the final decision was. The client receives an encrypted result and decrypts it locally. At no point does the server learn anything about the data or the outcome.
This is not a theoretical construction. This is production infrastructure running inside H33-Agent-Zero, our encrypted AI agent framework. And understanding how it works requires understanding three things: what a decision tree actually is when you formalize it as a circuit, what a programmable bootstrap does, and how the client/server key split makes the whole thing trustless.
Decision Trees as Comparison Circuits
A decision tree, at its core, is a sequence of comparisons. Each internal node asks a question: is feature X greater than threshold T? Based on the answer, the evaluation follows one branch or the other until it reaches a leaf node containing the decision.
Consider a simple credit decisioning tree. The root node might ask: is the applicant's debt-to-income ratio greater than 0.43? If yes, follow the left branch. If no, follow the right branch. The next node might ask: is the applicant's credit score greater than 680? And so on, until we reach a leaf that says "approve" or "deny" or "refer to manual review."
In traditional implementations, this is trivial. You load the feature values into memory, compare them against the thresholds, and follow the branches. The computational cost is negligible. But in the encrypted setting, each comparison is a cryptographic operation, and the cost structure changes fundamentally.
When we formalize a decision tree for encrypted evaluation, every comparison becomes a greater-than (GT) circuit operating on encrypted integers. If our features are represented as n-bit encrypted values, each GT comparison costs exactly 2n-1 programmable bootstraps. For 8-bit features, that is 15 programmable bootstraps per comparison. For a tree with d levels of depth, the total cost is d multiplied by the per-comparison cost at each level.
But here is the critical difference from plaintext evaluation: in the encrypted setting, we cannot follow just one branch. Because the comparison result is itself encrypted, the server does not know whether the "greater than" condition was true or false. It must evaluate both branches and then use an encrypted multiplexer (MUX) to select the correct result based on the encrypted comparison bit. This is what makes encrypted decision trees fundamentally different from their plaintext counterparts. The server does more work, but it learns nothing.
What a Programmable Bootstrap Actually Is
The term "programmable bootstrap" gets thrown around in TFHE literature without much explanation of what it actually does. This section addresses that gap, because understanding programmable bootstraps is essential to understanding why encrypted decision trees work and what they cost.
In TFHE, data is encrypted as LWE (Learning With Errors) ciphertexts. Each ciphertext is a vector of integers that encodes a single bit (or a small integer) plus noise. The noise is essential -- it is what makes the encryption secure. Without noise, LWE would be trivially breakable. But noise accumulates with every operation. After enough operations, the noise overwhelms the signal and the ciphertext becomes undecryptable.
A programmable bootstrap does two things simultaneously. First, it reduces the noise in a ciphertext back to a fresh level, allowing further computation. Second, it applies a lookup table (the "program") to the encrypted value during the noise reduction step. This means that a single programmable bootstrap can evaluate any Boolean function of one input bit -- AND, OR, NAND, NOR, XOR, XNOR -- all in a single operation.
The cost of a programmable bootstrap is dominated by a polynomial multiplication in a ring. On current hardware, a single programmable bootstrap takes on the order of one millisecond. This is the fundamental unit of cost in TFHE computation. Every Boolean gate that requires noise reduction costs one programmable bootstrap. Some operations, like XOR and NOT, can be done without bootstrapping (XOR is just LWE addition; NOT is just negation), but AND, OR, and their variants each require one programmable bootstrap.
When we say a GT comparison of two n-bit encrypted integers costs 2n-1 programmable bootstraps, we are saying that the circuit requires 2n-1 AND-equivalent gates. For 8-bit values, that is 15 milliseconds of computation per comparison on a single thread. This is not fast by plaintext standards, but it is deterministic, parallelizable, and -- most importantly -- it reveals nothing about the data being compared.
The Client/Server Key Split
TFHE uses a split-key architecture that is essential to understanding the trust model of encrypted decision trees. The client generates two types of keys: a secret key and a set of evaluation keys.
The secret key is an LWE secret key that the client keeps private. It is used to encrypt input features and decrypt the final output. It never leaves the client device.
The evaluation keys consist of two components: the bootstrapping key (BSK) and the key-switching key (KSK). The BSK is a set of encrypted copies of the secret key bits under a different encryption scheme (GGSW ciphertexts). The KSK enables conversion between different LWE key formats. Both the BSK and KSK are sent to the server.
The server uses the BSK and KSK to evaluate Boolean gates on encrypted data. It can perform programmable bootstraps, chain gates together, and evaluate entire circuits. But it cannot decrypt any input ciphertext, any intermediate value, or the final output. The evaluation keys give the server the ability to compute, not the ability to read.
This key split is what makes encrypted decision trees trustless. The client encrypts its feature values under its secret key, sends them along with the evaluation keys to the server, and receives an encrypted result. The server evaluates the entire decision tree without learning what the features are, which branches were taken, or what the final decision was. The client decrypts the result locally and acts on it.
Walking Through an Encrypted Decision Tree
Let us walk through a concrete example. Suppose we have a compliance rule engine for anti-money laundering (AML) that uses a decision tree with three levels. The tree evaluates three features: transaction amount (8-bit, scaled to a range), sender risk score (8-bit), and transaction frequency in the last 30 days (8-bit).
Step 1: Client-side encryption. The client encrypts each 8-bit feature value as eight individual LWE ciphertexts, one per bit. This produces 24 encrypted bits total. The client also generates the BSK and KSK evaluation keys and sends everything to the server.
Step 2: Root node evaluation. The root node asks: is the transaction amount greater than threshold T1 (say, $10,000 scaled to the 8-bit representation)? The server evaluates the 8-bit GT circuit on the encrypted transaction amount bits and the public threshold bits. This costs 2(8)-1 = 15 programmable bootstraps and produces a single encrypted bit representing the comparison result.
Step 3: Second level evaluation. The server must evaluate both child nodes because it does not know the comparison result. The left child asks: is the sender risk score greater than T2? The right child asks: is the sender risk score greater than T3? Each of these costs 15 programmable bootstraps. Total for this level: 30 programmable bootstraps.
Step 4: Third level evaluation. The server evaluates all four possible third-level nodes. Each asks a GT question about the transaction frequency against different thresholds. Total: 4 times 15 = 60 programmable bootstraps.
Step 5: Encrypted multiplexing. The server now has encrypted results from all leaf nodes and encrypted comparison bits from all internal nodes. It uses encrypted MUX operations to select the correct leaf value based on the encrypted branch conditions. Each MUX costs a small number of additional programmable bootstraps.
Step 6: Result return. The server sends the final encrypted decision bit back to the client. The client decrypts it with its secret key and learns the outcome: flag, pass, or escalate. The server learned nothing.
The total cost for this three-level tree on 8-bit features is approximately 105 programmable bootstraps for the comparisons alone, plus MUX overhead. At roughly one millisecond per bootstrap, the entire tree evaluates in approximately 120 milliseconds on a single core. With parallelism across independent branches, this drops further.
Why Greater-Than Is the Right Primitive
Every decision primitive that matters in production rule engines is built on greater-than comparisons. Thresholds ("is X above limit?") are direct GT operations. Greater-than-or-equal (GTE) is GT composed with equality at trivial additional cost. Argmax ("which of these N values is largest?") is a tournament of GT comparisons. Decision trees, as we have seen, are sequences of GT branches. Even range checks ("is X between A and B?") decompose into two GT operations.
Equality (EQ) comparisons, by contrast, have a more limited role in decision logic. Most compliance rules, credit models, and underwriting trees ask "is this value above a threshold?" rather than "is this value exactly equal to X?" This is fortunate because GT is structurally more robust than EQ in the TFHE Boolean gate setting. GT works reliably at 8-bit precision, handling the chained comparison noise depth that accumulates through the 2n-1 bootstrap chain. EQ, by contrast, works cleanly at 4-bit precision or below; at 8-bit it requires a parameter upgrade to TRLWE with N=1024 to manage the noise profile. This is a structural property of how comparison noise compounds through the gate chain, not a limitation that can be patched away.
For decision tree evaluation, this means we build everything on GT. And since GT covers thresholds, argmax, decision trees, and GTE at 8-bit precision, we cover the vast majority of real-world decision logic without needing EQ at all.
Use Case: Compliance Rule Engines
Consider a financial institution that must screen transactions against a complex set of compliance rules. The rules check transaction amounts, counterparty risk scores, geographic risk factors, transaction patterns, and dozens of other features. Today, the compliance engine must decrypt every transaction, load the feature values into memory, evaluate the rules, and produce a disposition.
This means the compliance engine has access to every transaction in plaintext. It sees every amount, every counterparty, every pattern. If the compliance engine is compromised -- by a breach, by an insider, by a supply chain attack on a vendor -- every transaction it has ever processed is exposed.
With H33's encrypted decision tree engine, the compliance rules are public (the tree structure and thresholds), but the transaction features are encrypted. The compliance engine evaluates the rules on encrypted data. It produces an encrypted disposition that only the originating system can decrypt. The compliance engine never sees a single transaction amount, a single counterparty name, or a single risk score.
The regulatory requirement is met: the rules were evaluated. The security requirement is met: the data was never exposed. These two requirements, which have always been in tension, are no longer in conflict.
Use Case: Credit Decisioning
Credit decisioning is perhaps the most natural application of encrypted decision trees. A lender needs to evaluate a borrower's creditworthiness using a model that considers income, debt levels, payment history, employment tenure, and other factors. The model is typically a decision tree or ensemble of decision trees (random forests, gradient-boosted trees) that produces a score or a binary approve/deny decision.
Today, the lender must see all of this data. The borrower submits their financial records, the lender's system processes them in plaintext, and the decision is made. The borrower's complete financial profile is exposed to the lender's systems, its employees, its vendors, and anyone who compromises any of those parties.
With encrypted decision trees, the borrower encrypts their financial features on their own device. The encrypted features are sent to the lender's evaluation server along with the evaluation keys. The server evaluates the credit decision tree on the encrypted features and returns an encrypted result. The borrower decrypts the result and learns whether they were approved, denied, or referred for further review. The lender learns the outcome (since the borrower must reveal it to proceed), but the lender's server never had access to the raw financial data.
This eliminates an entire category of data breach risk. The lender's database contains encrypted feature vectors, not plaintext financial records. A breach of the lender's systems yields ciphertexts that are computationally indistinguishable from random data. There is nothing to steal.
Use Case: Insurance Underwriting
Insurance underwriting involves evaluating risk factors that are deeply personal: health conditions, medication history, driving records, property conditions, lifestyle factors. Applicants are rightly concerned about sharing this information, and insurers are increasingly liable for protecting it. Encrypted decision trees resolve this tension entirely.
The underwriting model (the decision tree structure and its thresholds) is the insurer's intellectual property, and it remains public to the evaluation server. But the applicant's risk factors are encrypted. The evaluation server walks through the tree on encrypted features, computing GT comparisons at each branch, and produces an encrypted risk tier or premium estimate. The applicant decrypts the result on their device.
The insurer never sees the applicant's health conditions, medication list, or driving record. The insurer's model was still applied faithfully. The premium or coverage decision is still accurate. But the exposure window that existed in every previous underwriting system -- the moment when the data was plaintext on the insurer's server -- has been eliminated.
Connecting to H33-Agent-Zero
H33-Agent-Zero is our encrypted AI agent framework, and encrypted decision trees are a core component of its confidence boundary mechanism. When an AI agent operating within Agent-Zero needs to make a decision based on sensitive data -- routing a document, classifying a risk level, triggering an alert -- the decision is made through an encrypted decision tree.
The agent never sees the data it is deciding about. It submits encrypted features to the decision tree engine, receives an encrypted result, and acts on the decrypted outcome without ever having access to the underlying feature values. This is what we call "decision finality on ciphertext": the agent's decision is final and actionable, but the agent itself has zero knowledge of the data that drove the decision.
The confidence boundary in Agent-Zero defines the scope within which an agent can make autonomous decisions. Inside the boundary, the agent evaluates encrypted features through decision trees and acts on encrypted outcomes. Outside the boundary, decisions are escalated. The boundary itself is enforced through GT comparisons: if the agent's confidence score (computed on encrypted features) is greater than the threshold, the decision is autonomous; if not, it is escalated. Even the escalation decision is made on encrypted data.
This is the architecture that makes it possible to deploy AI agents on sensitive data without trusting the agent, the server, or any intermediate system with plaintext access. The decision tree is the mechanism. The GT comparison is the primitive. The programmable bootstrap is the cost.
Performance and Parallelism
The obvious question is performance. If each GT comparison costs 15 programmable bootstraps at 8-bit precision, and each programmable bootstrap takes approximately one millisecond, then a single comparison takes about 15 milliseconds. A tree with 7 levels (127 internal nodes in the worst case for a complete binary tree) would require roughly 1,905 programmable bootstraps, or about two seconds of single-threaded computation.
But decision trees have a natural parallel structure. All nodes at the same level can be evaluated simultaneously, since they operate on independent features against independent thresholds. A 7-level tree has at most 64 nodes at the deepest level, all of which can be evaluated in parallel. With sufficient hardware parallelism, the wall-clock time for the tree is determined by the depth (7 sequential comparison stages) rather than the total node count.
At 7 levels with full parallelism, the wall-clock time is approximately 7 times 15 milliseconds = 105 milliseconds for the comparisons, plus MUX overhead for the selection stages. This is well within interactive latency bounds for applications like credit decisioning or compliance screening, where existing systems often take seconds to respond anyway.
For ensemble methods like random forests or gradient-boosted trees, the individual trees can also be evaluated in parallel. A random forest of 50 trees, each 7 levels deep, takes the same wall-clock time as a single tree when sufficient parallelism is available. The encrypted vote aggregation across trees adds a small additional cost.
The Structural Guarantee
What makes encrypted decision trees fundamentally different from other privacy-preserving approaches (differential privacy, secure enclaves, federated learning) is the nature of the guarantee. Differential privacy adds noise to outputs, meaning the decisions themselves are degraded. Secure enclaves rely on hardware trust assumptions that have been repeatedly broken (Spectre, Meltdown, SGAxe, Plundervolt). Federated learning keeps data distributed but still requires models to see local data in plaintext.
Encrypted decision trees provide a mathematical guarantee: the server computes the correct decision without ever having access to the data. This is not a statistical guarantee (like differential privacy), not a hardware guarantee (like enclaves), and not an architectural guarantee (like federation). It is a cryptographic guarantee backed by the hardness of the Learning With Errors problem. Breaking it requires solving a problem that the entire cryptographic community believes is hard, including against quantum computers.
This is the guarantee that compliance officers, regulators, and security teams actually need. Not "we probably did not leak your data" but "it is mathematically impossible that we saw your data." That difference is the difference between privacy theater and actual privacy.
What Comes Next
Encrypted decision trees are the foundation. On top of them, H33 is building encrypted random forests, encrypted gradient-boosted tree ensembles, and encrypted rule chains that compose multiple trees in sequence. Each of these builds on the same GT primitive and the same programmable bootstrap cost model.
The path forward is clear: every decision that can be expressed as a tree of comparisons can be evaluated on encrypted data. And since decision trees are the most interpretable and widely deployed model family in regulated industries -- finance, healthcare, insurance, government -- the impact is immediate and direct.
The question is no longer "can we make decisions on encrypted data?" The question is "why are we still making decisions on plaintext data?" For compliance rule engines, credit decisioning, and insurance underwriting, there is no longer a good answer to that question.
H33-Agent-Zero ships with encrypted decision tree support today. The GT primitive is production-hardened. The programmable bootstrap is metered per gate for transparent billing. The client/server key split is built into every API call. The infrastructure exists. The only thing missing is the decision to use it.