When AI acts on the phone: mobile agents, a new attack surface

Up to date as of November 14, 2026. The AI features of phones change with every Android and iOS release. This article will be updated as announcements come in.

On the workstation, AI agents read emails and documents, and can take action (see our analysis Securing AI agents in the enterprise). On the phone, one more step is taken: the agent looks at the screen, taps buttons and fills in forms on the user’s behalf, in any app. Everything displayed becomes a potential instruction, and every installed app, a neighbor able to influence it.

What changes on the phone

The system assistants

In May 2026, Google presented Gemini Intelligence, which turns Android into an “intelligence system” able to automate apps on the user’s behalf. Google highlights several safeguards:

automation starts only when the user asks, and only in the apps they have allowed;
confirmation is required before a purchase;
the user can watch the actions in real time, and an indicator that cannot be dismissed shows that the agent is working;
new protections against prompt injection are being built into Android.

In September 2026, Google detailed the enterprise side: Gemini now chains tasks across apps based on the context shown on screen (calendar, emails, browser). The work profile remains isolated, so personal agents cannot reach the company’s apps and data, and administrators can configure, restrict or disable AI automation across the whole fleet.

At Apple, Apple Intelligence features and external AI services are now managed, on supervised devices running iOS 26.4 or later, through dedicated fleet-management configurations. And on November 9, 2026, iOS 27.2.1 fixed an authorization issue in App Intents, the framework that lets apps expose their actions to the system, which could allow an app to access sensitive data.

Third-party agents

Alongside these built-in assistants, open-source projects make it possible to drive a smartphone from a computer: the agent grabs screenshots through Android’s debugging interface (ADB), has them analyzed by a vision model, then sends taps and text. Their appeal is that they can automate any app. So is their weakness.

The new attacks

What the agent sees is not what the user sees

In July 2026, researchers evaluated five of these open-source agents (AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM and MobA). The Cloud Security Alliance published a summary: all of them were vulnerable to at least six of the seven attacks demonstrated, with no special privileges, only the permissions of an ordinary app. A few examples:

an almost transparent overlay (2% opacity in the tests), invisible to a human but read by the model, which gives it instructions;
instructions placed in the rounded corners of the screen or around the camera, areas nobody looks at but that appear on the screenshot;
a fake interface displayed over a legitimate app to capture the credentials the agent enters;
swapping the screenshot in the brief interval (about 210 milliseconds on average) between its capture and the moment the agent reads it;
eavesdropping on the text the agent types, passwords included;
command injection on the computer that drives the agent: text shown on screen, transcribed by the model, ends up executed on the PC or server.

The attacks on perception succeeded almost every time, whatever model was used. The researchers see an architectural problem: the agent acts on what a screenshot shows it, with no way of checking that it reflects the real state of the device.

Legitimate permissions, a hijacked context

A manipulated agent does not need flaws: it uses the permissions it was granted, in a context the attacker chose. This is the core of the risks listed by OWASP in its Top 10 for agentic applications: goal hijacking, tool misuse, identity and privilege abuse. On a phone, the agent’s “tools” are the apps themselves: messaging, payment, document storage.

Accessibility, a well-known way in

ANSSI points out that accessibility features, designed for people with disabilities, are regularly misused to read screen content and keyboard input. A malicious app with these rights can watch everything the agent does, or show it a fake interface. ANSSI recommends never granting these permissions without a legitimate reason.

Screens that leave the device

To decide, an agent must have the screen analyzed by a model. Depending on its design, this processing happens on the device, in the vendor’s protected environment, or at an online model provider. In the latter case, each screenshot, with whatever it shows (messages, documents, codes), leaves the phone: a matter of confidentiality and GDPR, just like the data behind AI projects (see Securing the data behind your AI projects).

What a company can set up right now

Inventory the AI features on the fleet: system assistants, third-party assistant apps, automation tools.
Decide, feature by feature, what is allowed, and enforce it through fleet management: Android Enterprise policies for AI automation, Apple configurations for Apple Intelligence and external AI services.
Keep work use separate: work profile or dedicated devices, so that personal agents cannot reach company data.
Control sensitive permissions: apps installed only from the official stores, review of apps that request accessibility or display over other apps.
Disable developer options and debugging on fleet devices, which agents driven through ADB depend on.
Require human approval for sensitive actions: payment, sending outside the organization, deletion, change of rights.
Monitor and test: feed mobile alerts into the SIEM, include mobile agents in the risk analysis and in penetration tests, and keep systems up to date.

For teams that build or test mobile agents

The researchers and the Cloud Security Alliance recommend, among other things, to:

never build a system command by inserting text read from the screen, and pass arguments in structured form;
not write screenshots to a temporary file readable by other apps;
mask the areas of the screen the user cannot see, and boost image contrast to reveal almost invisible text;
use dedicated test phones, isolated from production accounts and data;
favor projects that have a vulnerability disclosure process.

To secure the rest of the fleet, see our analysis The smartphone, security’s blind spot.

Sources

← All insights