Google is giving Android’s on-device artificial intelligence a stronger security boundary. Android 17 introduces AISeal, a system that uses protected virtual machines to isolate selected AI processing from the rest of the phone and make that separation verifiable.
The design matters because increasingly capable phone models may handle messages, audio, images and other personal context. Keeping that work on the device avoids some cloud exposure, but local processing still needs protection from other software running on the same hardware.
AISeal places workloads inside a protected guest
Google’s Android security and privacy overview says AISeal relies on pKVM, short for protected Kernel-based Virtual Machine. A virtual machine creates a separate execution environment, often called a guest, with its own memory and restricted channels to the main Android operating system.
The goal is to keep sensitive model inputs and computations outside the ordinary app environment. Even privileged software on the host should face a hardware-enforced boundary around a protected guest. That arrangement is stronger than relying only on an app’s promise not to read another process’s memory.
Hardware-backed isolation changes who must be trusted
Traditional software isolation depends heavily on the host operating system correctly enforcing every boundary. Protected virtualization moves critical controls into a smaller hypervisor layer supported by the processor and memory hardware. Android’s virtualization framework documentation describes pKVM as an architecture that preserves guest confidentiality and integrity even if the host Android kernel is compromised.
A smaller trusted computing base can be easier to audit than an entire mobile operating system. “Hardware-backed,” however, does not mean invulnerable. Processor flaws, hypervisor vulnerabilities, insecure communication channels and mistakes inside the protected workload can still create risk. Isolation reduces the blast radius of a compromise; it does not erase every possible defect.
Verification is part of the promise
Google describes AISeal’s environment as verifiable, meaning software can obtain evidence about what code and configuration are running inside the protected guest. This form of attestation can help a service refuse to send sensitive data when the expected security conditions are missing or altered.
Attestation is useful only when the verifier checks meaningful measurements and maintains a trustworthy reference. It can confirm that approved components loaded, but it cannot prove that an approved model always produces a safe answer or that the surrounding app uses the output responsibly. The security claim applies to execution conditions, not to the quality or truthfulness of AI-generated content.
Private Compute Core established the direction
Android has previously separated sensitive intelligence features through Private Compute Core. Google’s technical explanation of that system describes an open-source environment for features such as Live Caption and Smart Reply, with tightly controlled network communication.
AISeal develops the same privacy principle with a virtualization boundary backed by pKVM. Private Compute Core is a platform area and set of controls for privacy-preserving features; AISeal is the newer protected execution mechanism described for Android 17. The names are related, but they should not be treated as interchangeable.
Isolation addresses only part of the AI data path
A protected virtual machine can shield data while a model processes it, yet information also exists before entering and after leaving that environment. An app may collect more input than necessary, retain model output, display sensitive inferences or transmit data elsewhere. Permission design, storage encryption and network controls remain necessary around the protected guest.
Cloud-based AI creates a separate trust path. When a feature sends a request to remote servers, on-device virtualization cannot govern what happens after transmission. Google also operates Private AI Compute for some cloud-assisted workloads, but those services require their own technical and policy review. AISeal’s clearest claim concerns supported computation performed locally inside its protected environment.
Support will depend on Android 17 hardware
Virtualization relies on processor capabilities, firmware and device-maker integration. The Android 17 announcement does not make every existing handset capable of running AISeal. Availability may differ by model, region, manufacturer and the specific AI feature using the protected environment.
That variation also means the presence of Android 17 alone may not prove that a particular function runs inside AISeal. Product documentation and verifiable system information must connect a feature to the protected workload. Security-conscious applications should detect supported configurations instead of assuming identical protection across the Android ecosystem.
Mobile AI is moving beyond isolated photo filters toward assistants that can summarize communications, listen for commands and act across applications. Those capabilities increase the amount of intimate context available to a model. A successful compromise could expose not just a stored file but a stream of interpreted behavior.
AISeal is an infrastructure response to that shift. Its value will depend on which features adopt it, how clearly support is disclosed and whether independent testing confirms the boundary. The architecture provides a more defensible place to run sensitive local models, while leaving data minimization, permissions and careful product design as essential safeguards.
This article was produced with the assistance of AI and reviewed by Morning Overview editors prior to publication.
More from Morning Overview
