Google HEIR: A Homomorphic Encryption Compiler

Google HEIR explained: a compiler for homomorphic encryption

Google HEIR is an open-source compiler toolchain that converts programs into versions that compute on encrypted data. Google presented it on 14 August 2026 as the newest tool in its Private Computing Toolkit. It matters to anyone weighing private AI inference, where a model answers a request without the server ever seeing the input.

What HEIR stands for and who maintains it

HEIR stands for Homomorphic Encryption Intermediate Representation, and Google maintains it. An intermediate representation is the internal form a compiler translates a program into on the way to its output. Google describes HEIR as an open-source toolchain and development platform, and says it announced its intentions for HEIR in 2023.

The project's stated ambition is to be the industry-standard compiler for FHE. It names four groups who can build on it: application developers, compiler engineers, hardware designers and cryptography researchers.

What fully homomorphic encryption lets a server do

Fully homomorphic encryption lets a server compute on encrypted data without ever seeing it. Google's example is a cloud service that recommends content without seeing the user's features, and the first of HEIR's four demos does that.

The post sets this against end-to-end encryption and similar standard protections. They keep user data safe from breaches, yet the provider then cannot offer any feature that relies on reading it, such as spam and virus detection.

Why converting programs by hand takes cryptographers

Google says that rewriting an existing program by hand so it uses homomorphic encryption efficiently requires a team of cryptographers. HEIR was built to overcome that usability challenge.

Annotated Python and pre-trained models: what HEIR accepts

HEIR accepts two kinds of input: a Python program with secret types marked, and a pre-trained AI model. The project page describes the first and Google's post the second. Either way, the output is a program that runs on encrypted inputs, with no plaintext step on the server.

Marking secret types in a Python program

For application developers, the workflow is to write a Python program, mark the secret types, and let HEIR compile the rest. The result is a version of the program that runs on encrypted inputs.

Python and Torch as front-end languages

Python and Torch are the front-end languages named in the project goals. A front-end language is the one a developer writes the original program in.

The first goal is to compile high-level programs into encrypted equivalents. For machine learning, Google adds that HEIR can convert a pre-trained AI model so that it accepts encrypted inputs.

The one-click goal for non-experts

Google's stated vision is a one-click solution for non-experts, and that is a goal rather than a shipped feature. As of 30 September 2026, the workflow on the project page asks the developer to mark secret types in the source program.

Which libraries and accelerators HEIR generates code for

The project goals name two kinds of code-generation target: standard FHE libraries and hardware accelerators. The project also lists support for all modern FHE schemes as a goal. A scheme is the specific encryption method a library implements.

OpenFHE and Lattigo as the library backends

HEIR generates code for standard FHE libraries, and the project page names OpenFHE and Lattigo. A homomorphic encryption library implements the encryption and the arithmetic on ciphertexts. HEIR itself is not one of these libraries; it is the compiler that emits code for them.

GPU, TPU, FPGA and custom ASIC code generation

The project goals also cover code generation for GPU, TPU, FPGA and custom ASIC hardware. The page describes several layers of abstraction where an accelerator can plug in.

One layer suits accelerators that implement high-level FHE operations such as bootstrap. Another suits those working at the level of polynomial arithmetic. A further goal is a set of lower-level dialects (sets of operations inside the compiler) for optimizing algebraic operations such as RNS (residue number system) polynomial arithmetic.

Belfort, Niobium, Cornami and Optalysys as partners

Google has partnered with companies that build accelerator hardware for homomorphic encryption, among them Belfort, Niobium, Cornami and Optalysys. The post says the demos show the results of that work. It also says Google plans to show the latency benefits of those accelerators soon.

Four private AI inference demos compiled with HEIR

Google shared four private inference applications, all compiled with HEIR, and published the source code for each in its GitHub repository. They cover recommendation, credit card fraud, network intrusion and hotword detection.

Private content recommendation with a DLRM

The first demo is a Deep Learning Recommendation Model (DLRM) that serves private content recommendations. It was joint work with Belfort Labs, LG and New York University.

Credit card fraud and network intrusion detection

The second and third demos are credit card fraud detection and anomaly spotting in encrypted network traffic, and Niobium worked on both. The fraud detector also had hardshell.ai as a partner. The network demo is the Kitsune system compiled with HEIR, which lets a service provider detect anomalies without seeing the contents of the packets.

Hotword detection for audio-triggered agents

The fourth demo is a hotword detection model compiled with Belfort Labs. Google says it could let an audio-triggered AI agent recognize its hotwords while the recordings stay private. The post words this as a possibility and does not describe a deployed product.

Latency figures on a single-threaded CPU

Google reports the latency of all four demos on a single-threaded CPU. The same passage points to the GitHub repository for the source of every example.

How much overhead does homomorphic encryption still add?

Google's answer is that the overhead is real but shrinking. The post calls it nontrivial and says the cost is rapidly decreasing.

Cost overhead as the remaining trade-off

Homomorphic encryption turns a question of what a service can do into a question of what it costs. The post frames the old choice as capability against privacy. It gives healthcare and finance as examples of critical sectors where strict regulations limit data sharing across institutions.

Google calls the technology rapidly maturing, and its stated aim is for it to be easy for developers to build with, quick to run and widespread across industry. The post gives no overhead figure, so the gap to plaintext speed is not quantified.

Cryptographic guarantees versus hardware-based ones

Homomorphic encryption rests on cryptography alone, unlike hardware-based options. Google lists differential privacy, private set membership, private information retrieval and secure enclaves among its earlier techniques. Homomorphic encryption is the latest addition to that toolkit.

Local processing and the model-leakage problem

Local processing is limited by what the local device can run and by how sensitive the provider's intellectual property is. Putting a proprietary AI model on a user's machine also risks exposing the model. The post gives both as limits of local processing, one of the alternative ways to provide the same features.

HEIR as a research platform and how to contribute

HEIR also works as a research platform. Google maintains the codebase and documentation, and the project page invites outside contributions through pull requests, the issues page and working group meetings.

Collaborations and peer-reviewed papers

The post names seven universities as HEIR collaborators, and peer-reviewed papers build on it. They are Tsinghua University, the University of Edinburgh, Purdue, Carnegie Mellon, Georgia Tech, UC Santa Barbara and the Illinois Institute of Technology, and the post says there are other collaborators too. It counts four peer-reviewed publications so far, with more in preparation.

Testing and benchmarking infrastructure

A researcher with a new FHE optimization can build it inside HEIR and reuse its benchmarking setup. HEIR supplies the compiler infrastructure and implements standard optimizations from the literature. Research and benchmarking platforms are also two of the project's listed goals.

Ways to contribute to the HEIR codebase

The project page welcomes pull requests and lists several ways to contribute. They range from code and documentation to design discussion on the issues page and FHE research. Regular working group meetings and office hours cover the project's direction.

Newcomers can start from issues tagged "Good first issue" and "Contributions welcome". One listed task is research synthesis: deciding which parts of recent FHE research papers can or should be ported into HEIR.