Android AISeal: What's Protected Now and What Comes Later
Android AISeal is rolling out a hardware-isolated personal-context storage foundation; in-vault models and agents remain future work.
Direct answer: Android AISeal is Google's new hardware-isolated architecture for protecting the personal context used by on-device AI. Google says the foundational storage layer is rolling out now: sensitive context can be kept inside a protected virtual machine separated from the main Android operating system. Models, autonomous agents, direct neural-processor access and confidential-cloud connections inside that vault are still future work, and Google has not published a phone-by-phone availability list.
The important distinction is simple: AISeal is beginning with protected storage, not a finished personal assistant sealed completely inside a secure enclave. That makes the announcement meaningful for Android privacy architecture without turning Google's roadmap into a current device feature.
What is Android AISeal?
Google calls the architecture Android on-device AI seal, or AISeal. It creates a centrally managed protected environment for personal context such as information derived from messages, email, calendar events and cross-app interactions.
The vault runs in a protected virtual machine, or pVM, built on the Android Virtualization Framework and the protected Kernel Virtual Machine hypervisor. Google says this separates sensitive AI workloads from the host operating system so the protected data remains cryptographically isolated even if the host OS is compromised.
That is an architectural objective, not a promise that every Android attack is impossible. Boot integrity, hardware support, implementation quality, access policy and the code allowed inside the protected environment all remain part of the trust boundary.
What AISeal capability is rolling out now?
Google identifies hardware-isolated personal-context storage as the foundational milestone that is actively rolling out. The protected database stores and indexes context locally in encrypted form. Google's current reference implementation uses AppSearch, while the architecture can support another database supplied by a device manufacturer.
AppSearch itself is Android's on-device structured-data indexing and search system. The ordinary AppSearch documentation describes app-specific and shared index options with permission controls; the AISeal announcement adds a protected-VM boundary around the personal-context use case. It does not mean every existing AppSearch database automatically moves into AISeal.
How does pKVM isolate the vault from Android?
Android normally relies on application sandboxes and SELinux policies inside the operating system. AISeal adds a lower-level isolation boundary through virtualization.
The Android Open Source Project explains that pKVM keeps the hypervisor at a more privileged processor level and uses stage-two memory protection to restrict the host kernel's access to protected guest memory. When the host donates memory pages to a protected virtual machine, the hypervisor changes their ownership and blocks the host from reading them through its normal page tables.
That separation is why Google describes the vault as remaining isolated even after a full host-OS compromise. It is stronger than placing the database in another Android app process, but it still depends on supported hardware, verified boot, the hypervisor and the protected workload behaving as designed.
Are AI models and autonomous agents already running inside AISeal?
No—not as the current milestone described by Google. The October 7 announcement places four major capabilities in its future-work section:
- In-vault inference: running foundation models inside the protected virtual machine through future AICore integration.
- Autonomous agents: allowing system-level assistants to combine private context and local inference inside the vault.
- Direct NPU assignment: giving the protected environment a private path to the phone's neural processing hardware.
- Confidential-cloud extension: connecting the protected device environment to a manufacturer's confidential cloud service through an end-to-end encrypted path.
Google uses a schedule-summary example to illustrate how the completed design could work. That example should not be read as proof that a shipping Android assistant already queries email, messages and calendars entirely inside AISeal today.
Can several services share the same protected vault?
Google designed AISeal as a multi-tenant environment so a protected database, model and assistant can eventually share one pVM without exposing all raw context to one another. Internal access controls are intended to separate those services while reducing the memory and battery cost of running several isolated environments.
Multi-tenant does not mean unrestricted sharing. The security value depends on the access rules between components and on limiting what can leave the vault. Google says outbound controls are designed to allow the intended answer—not the raw underlying context—to cross back to Android.
Which Android devices support AISeal?
Google has not published an eligible-phone list or a device-by-device rollout schedule. It says MediaTek has announced support for the pKVM-backed architecture on the Dimensity 9600 Pro, while Qualcomm's Snapdragon chipsets will support it through Android Virtualization Framework. Google is also working with device manufacturers.
A supported chipset name is not proof that every phone using that family has AISeal enabled, that every manufacturer exposes the same protected services or that an owner can turn it on through a current settings screen. Device hardware, system image, OEM integration and service rollout all matter.
How is AISeal different from Gboard's protected learning system?
Both announcements use hardware-backed isolation, but they answer different privacy questions. AISeal is an Android on-device vault intended to keep personal context inside a protected virtual machine. Google's recent Gboard system sends selected encrypted training examples to policy-bound trusted execution environments on servers.
See Erawish's Gboard private-learning privacy guide for that server-side training design. The two approaches should not be merged into a claim that all Google AI data stays on the phone or that every Android model now runs inside AISeal.
What remains unknown?
- The exact phones, Android builds, countries and accounts receiving protected storage first.
- Whether owners will see a dedicated AISeal setting, permission screen or activity history.
- Which personal-context sources each manufacturer will allow into the vault.
- When in-vault model execution, autonomous agents, direct NPU access and confidential-cloud links will ship.
- How independent researchers and device owners will verify a particular phone's enabled components and access policies.
Bottom line
AISeal gives Android a hardware-isolated foundation for storing the personal context future assistants may need. The current news is the protected storage architecture and its active rollout—not a complete agent operating invisibly inside every Android phone. Until Google and manufacturers publish exact device and service details, treat chipset support and future-work diagrams as architecture signals rather than proof of a feature on a particular handset.