Cryptographic engineering · Technologies
HEIR makes privacy a compiled contract rather than a property of the model
Fully homomorphic encryption can keep an input sealed while a server computes on it. The useful question is not whether an AI is “private,” but which values, keys and execution paths the system has actually placed behind that boundary.
- Private inference is a scoped guaranteeHEIR can compile operations over ciphertext, but that does not automatically conceal model weights, outputs, logs or the surrounding deployment.
- The Secret type protects a valueA developer marks the sensitive argument. Public constants can remain visible while the compiler rewrites the operations that touch the secret input.
- Key ownership decides the last mileThe client can encrypt an argument with a public key and decrypt the returned ciphertext with a private key. Moving either step changes the trust boundary.
- A compiler can expose its own maturity limitsHEIR’s public roadmap, backend choices and debug variants are evidence to inspect, not details to hide behind a “private AI” badge.
“The server never sees your data” sounds like a product claim. HEIR turns it into a program that can be inspected. Google’s open-source compiler takes familiar high-level code, follows values marked as secret and lowers the relevant operations into cryptographic computation. The server receives ciphertext, applies the compiled circuit and returns ciphertext. In the intended path, the client alone performs the final decryption.
That is a meaningful engineering shift. It also makes a common shortcut less defensible. Privacy does not arrive because a model has been labelled private. It emerges from an agreement among types, compiler passes, scheme parameters, keys, backend code and deployment choices. HEIR is interesting because it lets us read that agreement rather than merely trust the adjective.
Private AI is not one promise
Several protections are routinely compressed into the phrase “private inference.” Input confidentiality asks whether the service can inspect the user’s request. Model confidentiality asks whether the user can extract the provider’s weights. Output confidentiality asks who can read the result. Operational privacy asks what appears in logs, traces, crash reports and debug builds. Fully homomorphic encryption can give the first question an unusually strong answer without automatically settling the other three.
Client side
Plaintext may exist here
The user prepares the input, encrypts it and retains the private key needed to read the returned result.
Server side
Computation stays sealed
The service runs the compiled circuit over ciphertext. Public model constants can remain available to the evaluator without revealing the secret input.
The cryptographic seam protects the value that crosses it, not every asset around it
The Secret type protects a value, not an entire product
HEIR’s Python examples make the boundary unusually concrete. A sensitive argument receives a secret type annotation. A model parameter does not have to receive the same annotation merely because the company treats the model as proprietary. In the machine-learning pipeline, weights can be compiled as public constants while an input tensor remains encrypted.
That distinction is not a loophole. It is one of the reasons private inference can be practical. The evaluator needs a circuit and can use public constants inside it, yet still cannot read the encrypted request. But “the server cannot see the input” and “the client cannot learn the model” are different claims. The second depends on what the compiled artifact, API behavior and repeated queries reveal—not just on whether the first argument was marked Secret.
Signature module · executable boundary
Read the secrecy signature before the privacy promise
This compact signature is a review instrument. It forces the product claim to name the secret value, the public value and the party that can open the result.
@compile(scheme="ckks", backend="openfhe")
def score(
x: Secret[Tensor],
weights: Tensor
) -> Secret[Score]Secret inputThe client encrypts x before the evaluator receives it.
Public constantThe compiler can embed weights without pretending they are ciphertext.
Secret resultThe client’s private key, not the model label, closes the promise.
The compiler is part of the threat model
Ordinary ML code does not map directly onto one homomorphic instruction set. HEIR lowers a program through intermediate representations, selects a cryptographic scheme and targets a backend such as OpenFHE or Lattigo. Approximate arithmetic with CKKS introduces scale, precision and rescaling decisions. Boolean or integer workloads can require different schemes. The same high-level function can therefore produce materially different encrypted computation depending on the selected path.
This is why “FHE enabled” is too thin for a technical review. The compiler must preserve the declared secrecy while transforming operations, and the deployment must supply compatible keys and parameters. Performance pressure also matters. An optimization that removes an expensive encrypted operation may be excellent; an optimization that silently moves a value into plaintext would change the product’s security claim.
Compiler evidence
A privacy claim survives only if every lowering preserves it
The useful audit path follows the value from a source-level annotation to the backend operation that will execute in production.
Secret annotationWhich argument is sensitive?
→
Encrypted IRWhich operations touch it?
→
Scheme parametersHow are precision and noise managed?
→
BackendWhat actually executes?
| Layer | Decision to inspect | Failure hidden by “private AI” |
|---|---|---|
| Source | Which inputs and outputs carry Secret types | Only part of the request is encrypted |
| Compiler | Lowering path, scheme, precision and unsupported operations | A fallback or approximation changes the guarantee |
| Keys | Who generates, stores and uses public, evaluation and private keys | The service can decrypt despite the marketing claim |
| Runtime | Debug mode, traces, caches and error handling | Plaintext appears outside the encrypted circuit |
| Product | What repeated queries and returned outputs reveal | Input secrecy is mistaken for model secrecy |
Debugging can reopen the boundary you meant to close
Google’s credit-card fraud demonstration is valuable precisely because it refuses to make debugging invisible. Its standard variant runs the encrypted flow. A timing variant measures stages. A debug variant decrypts intermediate encrypted values and compares them with cleartext computation to diagnose precision differences.
That is sensible research practice, but it changes who may see what. A build that decrypts intermediates is not equivalent to a production evaluator that never receives a private key. The lesson is broader than HEIR: debug access is a separate security state. It must be excluded from the production trust boundary by build controls, key separation and deployment policy, not by the hope that engineers remember which switch they used.
Debug aperture
The same function can have two different disclosure surfaces
Treat diagnostic decryption as an explicit privileged capability. If it can reach production keys or traffic, the encrypted circuit is no longer the whole boundary.
Production evaluatorAccepts ciphertext, runs the circuit and returns ciphertext. No intermediate plaintext is required.
Build
mode
Diagnostic evaluatorMay decrypt intermediate values to compare encrypted and cleartext precision. Access and keys must be isolated.
Research maturity belongs inside the privacy claim
HEIR’s public repository describes active support across several schemes and backends, but it also says the project is not an officially supported Google product. Its CKKS lowering tracker still records unfinished work around operations such as key switching, rotation, rescaling and bootstrapping. Those are not reasons to dismiss the compiler. They are reasons to report capability at the level of a tested workload rather than infer universal readiness from a successful demo.
A mature procurement question therefore sounds different from “Do you use FHE?” It asks which model and operator set were compiled, which scheme and backend executed them, what precision loss was measured, where keys live, whether debug decryption exists, which unsupported paths fail closed and what version of the compiler produced the artifact. HEIR makes those questions easier to answer because its intermediate representations and open implementation expose more of the chain.
HEIR’s most important contribution may be grammatical. It replaces “this AI is private” with a sentence that has subjects, objects and verbs: this client encrypts this value, this compiled circuit transforms it, this server cannot open it and this key holder can decrypt the result. Privacy becomes something an engineer can trace—and something a reviewer can falsify.
Questions about HEIR and private AI
What is HEIR?
HEIR is an open-source compiler toolchain for homomorphic encryption. It lowers high-level programs and machine-learning workloads into cryptographic operations that supported backends can execute over encrypted data.
Does HEIR encrypt the AI model?
Not automatically. HEIR’s ML pipeline can compile model weights as public constants while keeping the input secret. Model confidentiality is a separate design and evaluation question.
Who decrypts the inference result?
In HEIR’s client-helper pattern, the client encrypts the input and decrypts the returned result with its private key. A deployment that gives the evaluator decryption capability creates a different trust boundary.
Is HEIR ready for every production AI workload?
No universal claim is justified. Support depends on the operator set, scheme, backend, precision and performance requirements. The repository’s roadmap and disclaimer should be evaluated alongside a workload-specific test.
