Android 17 Built a Sealed Room for On-Device AI

There is a fight about on-device AI that mostly happens in headlines. One side says letting an assistant read your screen to be helpful is the future. The other side screenshots the same sentence and calls it surveillance, one outlet literally ran “Android 17 is the most compelling reason to give up your privacy.” While that argument runs, Android 17 shipped the piece of architecture that is the actual answer to it.

Google did name it. They call it AISeal with pKVM, and the announcement is a paragraph of assurances: “verifiable, hardware-backed, on-device isolation.” That paragraph is true, and it is also the marketing version. What AISeal actually is you only get from the source, and what is there is more precise, and more interesting, than either side of the fight. Once I worked out the shape of it, it reorganized half of the other things I had found in the 16-to-17 diff. This is the one I would not skip.

What AISeal is#

AISeal is a confidential-computing sandbox for on-device personal-data AI. In plain terms it is a protected virtual machine, isolated by the hypervisor, that runs three things, described in the source itself:

• an AppSearch database for personal data “that should not be accessible from the host OS,”
• an on-device AI inference service for large models,
• AI agents that resolve user requests using that data.

The whole design, on one page:

The grounded details make it concrete rather than aspirational, and they are all in the native host service config. It runs as an AVF protected VM on Microdroid, with the protected-VM flag on by default. It is sized for real work: about 300 MB of RAM and 16 GB of encrypted storage, enough for on-device models plus a personal-data corpus. Its storage is unlocked per user, with a key handed in when the user unlocks the device, the same shape as credential-encrypted storage. It is multi-tenant: AI providers run as tenants inside the VM and expose their services over a controlled vsock channel, and a host app reaches a named tenant only through that one path. It is implemented as a Rust host service plus a Java system service and a manager API.

One thing to be precise about. The AISeal framework is new in 17, absent in 16, and switched on in the release config. The virtualization substrate it rides on, AVF and Microdroid, is older. So AISeal is not a new sandbox technology. It is the new-in-17 thing that finally points that sandbox at a real product surface.

Why it is the center of 17’s AI story#

This is the piece that reorganized the rest of what I found in 17. On its own, each of the AI and privacy pieces in 17 looked like a separate thread. The protected-VM work looked like quiet plumbing. Personal Context looked like another assistant framework gathering screen signals. AppSearch was just a database. The new intelligence roles and the screen-context permission were access control. AISeal is the thing they all connect to, and Google’s own framing names the umbrella: Private Compute Core and Private AI Compute.

Personal Context gathers the signals. AppSearch, now inside the sealed VM, stores them. The inference service and the agents, inside the same VM, process them. The roles and the screen-context appop gate who is allowed to do any of it. AISeal is where the personal data actually lives and gets worked on, behind the wall. Once you see that, the scattered pieces stop being scattered. They are one architecture, and AISeal is its center.

What is actually protected, and what is not#

The claims here go wrong in both directions, so it is worth being precise.

What the protected VM gives you is real, and now formally so. Data sitting in that encrypted store, and the AI computation running over it, are protected from the host OS by the hypervisor, including from a host kernel that has been compromised. That is not marketing: pKVM, the hypervisor underneath this, is certified to SESIP Level 5, which Google describes as the first software security system designed for large-scale deployment in consumer electronics to meet that bar. The assurance level evaluates resistance to attackers Google’s own writeup calls “highly skilled, knowledgeable, well-motivated, and well-funded” with possible insider knowledge and access. The Android system, and any app on it, cannot reach into that VM and read what is inside.

But “the OS cannot see your personal data” is too strong a claim. Two things bound it.

First, the data has to get into the VM somehow, and that path runs through the host. The screen context that feeds this is captured by host-side code, Personal Context, running through VoiceInteractionManagerService in the normal Android OS, gated by the new screen-context permission. So the host does see your data at the moment it is captured. What AISeal seals is the storage and the computation, not the capture. Stated precisely: your personal-data store and the AI that runs on it are sealed from the rest of the OS, not that your data is never visible to it.

Second, the AI provider is inside the wall, not outside it. The tenant that runs in the VM is, on a Google device, the assistant stack, Google’s own pKVM writeup names “Gemini Nano for local personal data processing” as exactly this kind of payload, and it does process your data. That is the job. AISeal isolates your data from the platform and from every other app on the device. It does not isolate it from the AI provider you chose to use. If your worry was whether a random app or a compromised system could read your personal corpus, the answer this builds is no. If your worry was whether the assistant itself sees your data, the answer is yes, and that is the thing you turned on.

And the trust base is not zero. AISeal does not invent its own attestation; it rides on AVF’s protected-VM trust base, the hypervisor, the protected-firmware boot path, and the DICE chain that proves the VM is the genuine one. “Even if the OS is compromised” holds specifically for the confidentiality of what is in the VM’s memory. It is a strong property, scoped to a real thing, and, with the SESIP Level 5 certification, an independently evaluated one.

The accurate version is still a strong one. Android 17 ships a hardware-isolated enclave that protects your on-device personal-data store and the AI computation over it from the rest of the operating system and from every other app, with the AI provider you chose operating inside that enclave.

Two ways to read it#

You can read this as the privacy answer to on-device AI, and you would be right. If AI is going to run on a growing pile of your personal data, doing it inside a hardware-sealed enclave the rest of the system cannot peer into is a genuinely better design than the alternative, that data sitting in normal storage that anything with the right permission can read. This is real confidential computing applied to a real problem.

You can also read it as the infrastructure that makes large-scale on-device personal-data AI normal, and you would also be right. A persistent, 16-gigabyte, encrypted personal corpus with AI agents standing ready to act on it is a substantial thing to build into a platform, sealed or not. The seal is about who else can see it. It is not a statement about how much of your life ends up in there in the first place.

Which one you lead with says more about what you were already worried about than about the architecture, and both hold at once. It is a privacy-protective design, and it is a large expansion of on-device personal-data AI, and those are not in tension. They are the same feature described from two angles. (Notice, too, that Google’s blog calls what goes in here “ambient data.” The source calls it “personal data that should not be accessible from the host OS.” The code is blunter than the marketing, and the code is right.)

What ships, and what does not yet#

One last piece of honesty about what is actually in 17. AOSP ships the runtime: the sealed VM, the host service, the manager API, the storage. The tenants, the actual AI models and agents, are off-tree, supplied by whoever owns the assistant on a given device. That is the same OEM-neutral pattern Personal Context uses. And the broader pipeline that would feed it is still partly staged behind flags. So what 17 contains is the architecture, switched on and ready, more than a finished user-facing product. You will see it light up over the next releases, not all at once.

That is why it is worth understanding at the architecture level now, while the decisions are visible in AOSP and checkable, rather than later through a settings toggle and a marketing paragraph. So I will leave it as a question rather than a verdict. Is this the privacy answer to on-device AI, the thing that lets it run on your personal data without the rest of the system reading along? Or is it the architecture that quietly makes a large encrypted vault of your personal life a standard part of the phone? I think it is honestly both, and I would like to know which half you find yourself reacting to.

Found by diffing the Android 16 and 17 source trees and confirmed against AOSP and Google’s own announcements. Sources: AISeal framework source (frameworks/base, 17 tag) · AISeal native host service (frameworks/native, 17 tag) · Google: “AISeal with pKVM” announcement · Google: pKVM achieves SESIP Level 5.