On August 14 Google published in its security blog a post about HEIR — a compiler that takes a trained model and turns it into code that runs over encrypted data. The server receives ciphertext, processes it through network layers, and returns ciphertext — and at no point does it have any physical way to see inside. Only the one who holds the key, i.e., the user themselves, can decrypt.
Sounds like a marketing slide, so let me clarify: HEIR itself is not new. It has been on GitHub since 2023, under Apache-2.0, and this is no secret project. What’s new in the August post is the claim that you can finally use it without being a cryptographer, plus four demos and a list of hardware partners. Below is an analysis of what’s really going on inside such a compiler, because without this you can’t understand where the boundaries of homomorphic encryption applicability lie.
Homomorphic encryption in one paragraph. Regular encryption is a box you must open to do anything with its contents. Homomorphic is a glovebox: you slip your hands inside and add, multiply, compare without opening the lid. Fully homomorphic schemes (FHE) support addition and multiplication unboundedly, enough to express any computation.
Layer 1. Function whose arguments are marked as secret
The entry point looks deceptively simple. The developer writes a normal function, marks the types of those arguments that must not be revealed, and gives this to the compiler. Inside HEIR this becomes an MLIR dialect secret — a representation that doesn’t know anything yet about cryptography. It only says: “there is a computation on a value here that the server should not see.”
Splitting into “scheme-independent” and “scheme-dependent” levels is the essence of the project. It allows running the same source through different cryptosystems and comparing the results.
Diagram based on heir.dev documentation (Design section) and dialect descriptions in the google/heir repository
Layer 2. Branching schemes: why four, not one
Next the compiler chooses the cryptosystem, and this is not a matter of taste. Each scheme has its own arithmetic and strengths:
| Scheme | Native operations | Typical use |
|---|---|---|
| BGV / BFV | exact arithmetic on integers | counting, aggregations, SQL-like operations |
| CKKS | approximate arithmetic on real numbers | neural networks, statistics, ML inference |
| CGGI (TFHE) | bit-level logic, fast bootstrapping | comparisons, branching, arbitrary boolean circuits |
A machine learning model almost always shifts to CKKS: floating-point numbers map to the scheme naturally, at the cost of the result being approximate. If the task requires precise comparisons and branching — that’s CGGI territory.
Layer 3. Noise — expendable material that runs out
Here’s where the pretty idea starts to run into physics. Any ciphertext in these schemes carries a small random noise, without which encryption would not be resilient. Each operation increases noise: addition a little, multiplication noticeably. When the noise exceeds a threshold, decryption yields garbage.
So the compiler does not so much “translate” as budget. In HEIR this is handled by a separate mgmt dialect, whose job is to place service operations in the program:
- relinearization — after multiplying, the ciphertext “bloats”; it must be compressed back;
- modulus switching — reset part of the accumulated noise at the cost of reducing the remaining headroom;
- bootstrapping — the most expensive operation that resets the noise and allows computing further for as long as needed.
It is the noise budget, not “slow mathematics” itself, that determines whether your task fits into FHE. A program that can be computed without a single bootstrapping vs. one that needs it at every layer differ by order of magnitude in runtime.
Layer 4. Packing: data layout matters more than the scheme choice
One ciphertext in BGV and CKKS is not a single number, but a vector of thousands of “slots.” You can pack an entire batch into it, and one operation processes thousands of values at once. But operations apply to slots element-wise, and as soon as you need to add neighbors, you have to perform a cyclic shift of the vector — a separate and costly operation.
This is what the HEIR tensor_ext dialect handles. It decides how to lay out the tensor across slots so that convolution or matrix multiplication require a minimum number of rotations. This is exactly the work that in hand-rolled FHE often takes weeks and where most users go wrong.
Layer 5. Backend: third-party libraries and hardware
HEIR does not execute anything itself — it generates code for existing implementations. The support matrix from the repository looks like this:
| Library | Language | BGV | BFV | CKKS | CGGI |
|---|---|---|---|---|---|
| OpenFHE | C++ |  |
|
|
— |
| Lattigo | Go | |
|
|
— |
| tfhe-rs | Rust | — | — | — | |
| Jaxite | JAX | — | — | — | |
There is also a separate line for accelerators. The post mentions Belfort, Niobium, Cornami, and Optalysys: companies that build hardware specifically for FHE. The academic list is long as well — Georgia Tech, CMU, UC Santa Barbara, Purdue, Edinburgh, Tsinghua and others; according to Google, four peer‑reviewed publications have already been built on HEIR.
What the four demos show
Google published four examples compiled via HEIR:
- DLRM recommender model — in collaboration with Belfort Labs, LG, and NYU.
- Fraudulent card transaction detector — with Niobium and hardshell.ai.
- Network intrusion detection based on Kitsune — anomalies are sought without revealing packet contents.
- Keyword detector in audio — again with Belfort Labs.
A common thread across all four is a small model, fixed architecture, inference without training. This is a fair choice — these are exactly the kinds of tasks today that fit into FHE.
The Kitsune scenario deserves special attention for those working with networks: an IDS that looks for anomalies without inspecting traffic content addresses the main objection to cloud-based intrusion detection systems — “you’re giving the provider all your traffic.”
What’s not in the announcement
Now the unpleasant part, the reason to dissect all this.
The August 14 post contains no performance numbers. No inference time, no comparison with plaintext, no key sizes, no traffic volume. It only states that all four demos ran on a single CPU core. The closest public reference from Google itself is the 2023 post, where a three-layer neural network compiled from TensorFlow Lite was cited as private inference in 16 seconds.
16 seconds for a three-layer network is not “slow”; it’s a different class of tasks. FHE today does not replace ordinary inference; it opens up scenarios where transmitting plaintext data to a server is not possible by law or contract, and where the answer can be waited for.
Second, what’s mentioned casually in the announcement: the stated goal of a “one-click solution for non-specialists.” This is a goal, not the current state. The fresh release tag in the repository is v2026.07.01, the codebase is nearly split 50/50 between C++ and MLIR, and the entry barrier remains suitable for someone who understands what a noise budget is.
And a third thing rarely written about in FHE announcements: homomorphic encryption hides the data, but not the fact and form of the computation. The server sees that you queried, how long it took, the ciphertext size, and which model you run. Metadata and traffic analysis remain in effect, and this must be considered separately in the threat model.
Who should poke at this now
If you have production — it’s almost certainly too early. If you’re curious how the computation that cannot be snooped looks, it’s already quite possible: the repository is open, demos are being built, dialect documentation exists.
A reasonable order to get acquainted:
github.com/google/heir— the compiler itself and pipeline examples.github.com/google/fully-homomorphic-encryption— the demo repository.- The Design section on heir.dev — description of dialects, noise analysis, and packaging; reads like a textbook on what an FHE compiler is made of.
Separately note that what’s not included in the text: there are many reviews of the form “top-N FHE solutions,” hosted on the vendors’ own accelerator domains. I did not find a single independently verified performance figure for HEIR in them, so they are not in the article.
Sources
- How Google is making private AI practical with homomorphic encryption — Google Blog, August 14, 2026
- github.com/google/heir — compiler repository, Apache-2.0
- heir.dev — Design — description of dialects and passes
- Expanding our fully homomorphic encryption offering — Google Developers Blog, 2023, from which the 16-second figure comes
- github.com/google/fully-homomorphic-encryption — demo repository
And where would you agree to pay in seconds and megabytes for the server to physically be unable to read your data? Medical datasets, banking scoring, log search at a contractor — or does this still look like an academic toy?