Google published a blog post on August 14, 2026 announcing HEIR (Homomorphic Encryption Intermediate Representation), an open-source compiler that converts trained AI models into versions that can run inference directly on encrypted data — without the server ever decrypting it. Written by staff software engineer Jeremy Kun, the post frames HEIR as the missing piece that turns a decades-old cryptographic idea into something an ordinary engineering team can actually ship.
The idea itself — fully homomorphic encryption, or FHE — isn't new. What's new is Google's bet that a compiler can replace the cryptography PhD you used to need to make it work. Hacker News gave the announcement 275 points, and the comment thread is where the useful skepticism lives: this is real progress, but it is nowhere near production-speed for general AI inference yet.
TL;DR
| Question | Answer |
|---|---|
| What is HEIR? | An open-source compiler that rewrites pre-trained models to run inference on encrypted inputs |
| What problem does it solve? | Manually adapting a model for homomorphic encryption used to require a cryptography team; HEIR automates the rewrite |
| Who built it? | Google, part of its Private Computing Toolkit, with hardware partners Belfort Labs, Niobium, Cornami, and Optalysys |
| What demos exist? | A recommendation model, a fraud detector, a network intrusion detector, and a wake-word detector |
| Is it fast? | No — HN-cited benchmarks put overhead at roughly 100x-1,000x+ slower than plaintext |
| Is it E2EE? | No — E2EE hides data from the server entirely; FHE lets the server compute on it while it stays encrypted |
| Who should care today? | Regulated sectors (healthcare, finance) with hard data-sharing restrictions, not general chat/LLM products |
What homomorphic encryption actually is
Start with the tradeoff FHE is trying to break. If you want a service to be end-to-end encrypted, the standard approach is that the server never sees your plaintext data — it's encrypted on your device, transits encrypted, and only you (or the recipient) can decrypt it. That's great for privacy, but it also means the server can't do anything with your data. It can't run spam detection, can't personalize recommendations, can't flag fraud, because to the server your data is just noise.
Homomorphic encryption changes that equation. It lets a server perform computation directly on ciphertexts — the encrypted blobs — and produce an encrypted result, all without the server ever being able to see the plaintext at any point in the process. The client alone holds the decryption key and decrypts the final answer locally. The server ran a real computation on your data. It just never once knew what the data was.
This is the distinction worth internalizing: ordinary E2EE and FHE both keep data unreadable in transit and at rest on the server. Only FHE lets the server compute on it anyway.
Why this matters more than a cryptography curiosity
FHE's guarantee is purely mathematical. That's the sell against the other common approach to private server-side compute — secure enclaves (hardware-isolated execution environments). A secure enclave's privacy guarantee ultimately rests on trusting a chipmaker's hardware to not have bugs or backdoors; enclave side-channel attacks have shown up repeatedly in cryptographic security research. FHE doesn't ask you to trust hardware at all — the ciphertext is uninterpretable without the key, full stop.
Google positions HEIR as one piece of its broader Private Computing Toolkit, alongside differential privacy, private set membership, private information retrieval, and secure enclaves — a portfolio of techniques for doing useful things with data the service provider isn't allowed, or trusted, to see in the clear.
What HEIR actually does: a compiler, not a new algorithm
Homomorphic encryption schemes have existed in usable form since roughly 2009. The blocker was never "does the math work" — it was that making an existing, working ML model run efficiently under FHE required a team of cryptographers to hand-rewrite it, because encrypted computation has wildly different cost economics from normal computation:
- Multiplication is vastly more expensive than addition under FHE, the inverse of the tradeoffs an engineer normally thinks about.
- Branching is extremely costly. A model with an
ifstatement can't just take one branch under encryption — since the server can't see which condition is true, it typically has to compute both branches and combine them, because taking a visible shortcut would leak information about the encrypted input. - Every model has to be flattened into a circuit that doesn't leak execution path, which is a fundamentally different representation than the branching, loop-heavy code most ML inference is written as today.
HEIR's contribution is a compiler intermediate representation — the same category of tool as LLVM IR in traditional compilers — that automates this rewrite. Google's framing is that it moves FHE model conversion from a bespoke cryptography research project to something "close to one-click": point HEIR at a trained model, and it produces an encrypted-inference version, without requiring the applying engineer to personally reason about ciphertext multiplication depth or circuit flattening.
That's the real news here, and it's why the HN audience — largely practitioners, not cryptographers — engaged with it at 275 points. The underlying math isn't new. Making it accessible to a normal engineering team is.
The four demos Google showed
Google, working with hardware-accelerator companies Belfort Labs and Niobium, plus academic partners including NYU, LG, and hardshell.ai, compiled four working demonstrations with HEIR:
- A Deep Learning Recommendation Model (DLRM) that serves content recommendations without the server seeing the user's raw feature data.
- A credit card fraud detector that classifies a transaction as fraudulent or not without the server seeing the transaction in plaintext.
- Kitsune, an anomaly/intrusion detector for network traffic — it flags anomalies in encrypted packet data without the service provider seeing packet contents.
- A hotword/wake-word detector for audio, so a voice-activated AI agent could recognize a trigger phrase while the underlying audio recording stays encrypted end-to-end.
Notice what these four have in common: they're all narrow, binary or low-cardinality classification tasks, not open-ended generation. That's not an accident — it's the current shape of what FHE can do at usable cost.
The research ecosystem behind it
Google says HEIR has become an active academic research platform, with contributions from Georgia Tech, Carnegie Mellon, UC Santa Barbara, Illinois Institute of Technology, Purdue, the University of Edinburgh, and Tsinghua University, producing four peer-reviewed publications so far with more in preparation. Hardware-accelerator partners building FHE-specific chips include Belfort, Niobium, Cornami, and Optalysys — Google says it plans to demonstrate latency improvements from dedicated accelerator hardware "in the near future," which is a tell that the CPU-only numbers in today's demos understate what purpose-built silicon could eventually deliver.
The honest performance reality (this is the part to not skip)
Here's where the Hacker News discussion earns its place in this post. Google's announcement is genuinely a step forward on accessibility — but several commenters, including some with FHE and privacy-preserving ML (PPML) research backgrounds, were explicit that the underlying technology "isn't commercially viable yet" for general workloads.
The numbers cited in the thread, drawn from recent academic benchmarks, are worth sitting with:
| Operation | Reported cost under FHE |
|---|---|
| Sorting 32 small integers | ~34 seconds, even on ordinary hardware |
| A single 64-bit integer division | Multiple seconds |
| HE-LRM inference (UCI/Criteo-style benchmark) | ~24 seconds to ~8 minutes, single-threaded CPU |
| "Sofar" FHE CIFAR image classification (GPU-accelerated) | ~200ms — still ~1,000x slower than cleartext, but a real speedup |
Put plainly: general FHE computation currently runs somewhere around 100x to 1,000x+ slower than the equivalent plaintext operation, depending on the workload and how much GPU acceleration has been applied. An 8-minute inference latency is not remotely close to what a chat-speed LLM product needs — that's an eternity compared to the sub-second responses users expect from something like Claude's coding workflows or any interactive assistant.
Several HN commenters also flagged a second, separate concern: skepticism about Google's institutional motives, given its ad-driven business model runs on exactly the kind of behavioral data FHE is designed to keep private from a service. Whether HEIR reaches consumer-facing Google products, or stays confined to narrow B2B/compliance use cases, is an open question the announcement itself doesn't answer.
What this does and doesn't enable, right now
| Enables today | Does not enable today |
|---|---|
| Narrow classification tasks in regulated sectors (fraud detection, diagnosis-support queries) where the compute cost is worth clearing a hard regulatory blocker | Interactive, general-purpose private chat or LLM inference |
| Cross-institution computation where raw data legally cannot be shared (banks, hospitals) | Consumer AI features where users expect sub-second responses |
| Research and academic exploration of encrypted-inference architectures | Cost-competitive replacement for plaintext inference at scale |
| Point demos proving feasibility (recommendation, fraud, intrusion, wake-word) | General-purpose model inference, e.g. arbitrary LLM prompts |
That's the real shape of "practical" here: FHE via HEIR is practical for teams that were previously blocked entirely — where the alternative wasn't "fast plaintext inference," it was "no inference at all because the data legally can't leave its silo." It is not yet practical as a drop-in privacy upgrade for products that already work well on plaintext data.
Why regulated industries are the near-term audience
Healthcare and finance are the two sectors Google specifically calls out, and it's not arbitrary. Both are bound by data-sharing regulations that often block exactly the kind of cross-institution computation that would improve outcomes — a hospital network wanting to query a shared diagnosis model without exposing patient records, or banks wanting to run a shared fraud model without exposing customer transaction histories to each other.
In those cases, the FHE compute-cost tax isn't competing against "how fast can we make this," it's competing against "we currently can't do this at all." A fraud check that takes a few extra seconds under encryption is a reasonable trade when the alternative is no cross-bank fraud detection whatsoever. That's a very different cost-benefit calculation than trying to FHE-ify a consumer chat product, which is why this class of technology reads as compliance-narrow rather than consumer-imminent for now — consistent with how AI teams already navigate stricter data privacy tooling like Microsoft Presidio for PII handling before data ever reaches a model.
How HEIR fits the wider AI-security landscape
HEIR arrives alongside a run of AI-adjacent cryptography and privacy stories this year — Anthropic's Mythos project surfacing real weaknesses in HAWK and AES-related attacks, zkSecurity's AI-assisted audit of Cloudflare's CIRCL cryptography library, and continued government movement on post-quantum cryptography standards. The common thread: as AI systems handle more sensitive data, the cryptographic foundations underneath them are getting more scrutiny, not less.
It's also a useful contrast against the AI-security incident posts on this blog — tl;dv's Firestore breach and the Tailscale/Hugging Face intrusion both happened because plaintext data sat somewhere it shouldn't have been reachable from. FHE is one (expensive, narrow) answer to that entire class of problem: if the server never has the plaintext, a misconfigured access-control rule can't leak it. That's also why sandboxing and access controls, like the practices in the Claude Code rm -rf incident sandbox guide, remain the practical near-term defense — most teams aren't going to FHE-ify their stack this year, but they can lock down what plaintext data an agent or service can reach.
FAQ
What is Google HEIR? An open-source compiler toolchain that converts a trained AI model into a version that runs inference on encrypted data, without server-side decryption. Part of Google's Private Computing Toolkit.
Is this the same as end-to-end encryption? No. E2EE keeps data unreadable to a server but prevents it from computing on that data. FHE lets the server compute on encrypted data and return an encrypted result, with the server never seeing plaintext at any point.
Is homomorphic encryption fast enough for products yet? Not for general or interactive workloads. HN-cited benchmarks put overhead at roughly 100x-1,000x+ versus plaintext, with some inference demos taking minutes on CPU.
Who benefits from HEIR right now? Regulated sectors — healthcare and finance — with data-sharing restrictions that make "slow but private" better than "impossible."
Related on explainx.ai
- Homomorphic encryption — AI Dictionary
- Claude Mythos finds cryptographic flaws in HAWK and AES
- AI-assisted cryptography audit of Cloudflare CIRCL
- Post-quantum cryptography executive orders
- Microsoft Presidio: PII detection and anonymization guide
- tl;dv Firestore breach: 181,874 meetings exposed
- Tailscale on the Hugging Face breach
- Claude Code rm -rf incident: sandbox guide
Official sources
- How Google is Making Private AI Practical with Homomorphic Encryption — Google
- HEIR project
- Hacker News discussion
Figures, demo descriptions, and attributions in this post follow Google's official HEIR announcement (published August 14, 2026, by Jeremy Kun) and the accompanying Hacker News discussion as of publication. Performance numbers are as cited by commenters and academic benchmarks referenced in that discussion — treat them as illustrative of current FHE overhead, not as Google's own official latency figures for HEIR.