How agentic attacks could change mobile app security

The mobile attack chain is already starting to change

There is an important evidence boundary around agentic attacks and mobile applications that might surprise you. In publicly documented malicious campaigns reviewed for this post, we found no evidence that the threshold for a fully agentic, end-to-end attack against a mobile application has been crossed. No documented case shows an AI agent independently taking a mobile attack from reconnaissance and reverse engineering through exploitation and execution of the attacker's ultimate objective.

Of course, any absence of an end-to-end example doesn't mean AI has yet to enter the mobile attack chain. Public evidence points instead to AI taking over individual stages that previously required more human involvement. PromptSpy provides the clearest public Android example so far.

Case studies: PromptSpy and GeminiAutomationAgent

ESET identified PromptSpy in February 2026 as the first known Android malware to incorporate generative AI directly into its runtime execution flow. One component sends information about the visible interface of the compromised device to Google's Gemini model. The model interprets the current screen and returns instructions that the malware can translate into Android gestures. [1]

Google Threat Intelligence Group later documented an autonomous module called GeminiAutomationAgent. The module repeatedly captures the current Android UI state, sends the information to Gemini alongside an objective, and converts the model's response into actions such as clicks and swipes. The resulting process creates a model-in-the-loop cycle that can respond as conditions on the device change. The malware was able to dynamically parse the natural-language reasoning of the LLM into actionable spatial coordinates and Android accessibility commands. [2]

Clearly, PromptSpy doesn't represent a fully agentic mobile attack. Human control remains elsewhere in the operation, including through a VNC capability that allows an attacker to view and control the device remotely. ESET had also not observed PromptSpy in its telemetry when its analysis was published and noted that the malware could potentially have been a proof of concept.

The narrower finding is important enough on its own. AI-driven adaptation has reached malicious Android execution. An attacker no longer has to predefine every interaction with a changing mobile interface or monitor every part of the attack stage. They can use models that interpret the current state and decide what action should follow. Our broader conclusion is that the full mobile attack chain doesn't need to become agentic before the economics of attacking mobile applications begin to change.

Why mobile makes the agentic attack problem sharper

Attackers can get direct access to the mobile client runtime. They can download the application, decompile it, inspect its logic, instrument it, modify its environment, rerun it, compare the result, and adapt. Defenders don't control the device on which the attacker performs the analysis and experimentation, or if the app has been repackaged and hosted on a site used for sideloading.

Mobile also differs architecturally from web deployments.

With a web application, controls can in some cases be introduced dynamically between the application and the client using a reverse-proxy model. A compiled mobile application has already been distributed onto the device. While threat intelligence can be pushed to a mobile device, and devices can run AI models for security locally, equivalent runtime protection and obfuscation can't simply be inserted into the mobile client dynamically from the network in the same manner as with web apps.

Protection therefore needs to travel with the mobile application into environments assumed to be under attacker control. Agentic systems increase the pressure on that model because repeated experimentation can require less human attention.

Read more: When mobile and AI collide: Why app security cannot reuse the web playbook

Consider a conventional reverse-engineering loop. An attacker inspects the application. Part of the application is unclear, so the attacker tests a hypothesis. A protection triggers. A hook fails. The application behaves differently than expected. Our attacker works out why, changes their approach, and tries again.

Historically, those transitions consumed human time and attention. Agentic systems increasingly target the transitions themselves. A model can interpret the result of an experiment, suggest or generate another approach, and continue the process without requiring a human to reverse engineer or assess every result manually.

The same exposure extends to AI assets embedded inside mobile applications.

An on-device model used for fraud detection is one example. If an attacker can reverse engineer how the model contributes to a risk decision, inspect the surrounding business logic, or manipulate the inputs and runtime conditions on which the model depends, the AI model becomes part of the attack path.

Promon Shield already protects  embedded on-device AI models and AI-driven application logic at rest and at runtime to defend against tampering, theft, and code injection. Agentic attacking can reduce the human work required to probe those assets repeatedly.

New attack logic still depends on concrete techniques

A more adaptive decision layer doesn't remove the need to interact with the real application. Some agents can discover a new attack path, chain multiple techniques, switch tools when one fails, and customize campaigns for each target. But successful progression still depends on performing actions against the application and its runtime.

Typically, an agent would need to understand protected code. The attack may require attaching instrumentation, hooking a function, modifying execution, running the application in an emulator, repackaging the client, interfering with an integrity check, or manipulating the surrounding environment.

Any decision layer can change dramatically while many of the underlying tactics, techniques, and procedures remain recognizable. For mobile defense, the mission moves attention away from trying to identify every possible future agent, tool, malware family, or generated script. A more durable question is whether the protection covers the techniques an attacker must use to manipulate the application.

Case study: Promon's facial recognition research

Promon has applied the same principle to mobile malware for some time. We focus on detecting the techniques an attack depends on rather than relying only on recognizing a known malware family or variant.

Previous Promon research has argued that detecting and preventing malware techniques provides a more fundamental protection layer than waiting to identify every new threat individually. [3] Promon's 2025 research into attacks against facial recognition provides a practical proof point. [4]

Promon's Security Research team tested app-level and system-level tools used to manipulate facial recognition flows on iOS and Android. Shield for Mobile detected all the app-level tools identified in the research out of the box, including tools the team had not encountered before, because its runtime controls covered the methods those tools used.

The report also makes it clear that Shield did not detect the system-level attacks tested at that time.

Learn more: Biometric authentication attacks

The difference between recognizing a specific attack tool and detecting the underlying techniques becomes more important as attack decision-making becomes agentic. A defender can't assume which tool an agent will choose, what code an agent will generate, or which attack path the agent will try next.

A novel threat does not automatically require a novel underlying technique. Runtime controls can therefore retain value when an agent produces an attack chain the defender has never seen before, provided the attack depends on techniques covered by those controls, and a defense-in-depth approach is employed that maintains resilience if one control is bypassed.

How code protection changes under AI-driven code analysis

Agentic analysis also changes some of the economics behind reverse engineering.

Application protection has never depended on making reverse engineering mathematically impossible. The objective is to increase the work required to understand and manipulate an application until the required cost, time, and complexity deters the attacker.

Machine analysis changes several inputs in that calculation.

A model does not become tired after repeated attempts. Automated systems can retry quickly. Multiple agents can explore separate hypotheses in parallel. Failed experiments can feed directly into another round of analysis.

Learn more: Increased automation in attacks

Machine analysts also interpret code differently from human reverse engineers. Models maintain context differently, make different mistakes, and can sometimes infer structure or intent from code in ways that do not depend on the same visual or cognitive cues used by a person.

Code protection therefore faces a developing research question:

How should protection evolve when the analyst is increasingly a model rather than a person?

Two studies published in June 2026 illustrate both sides of the problem.

Case studies: Android LLMs and Acoda

One study evaluated whether off-the-shelf LLMs could identify and classify obfuscation in Android applications through semantic reasoning. The approach did not depend only on predefined signatures or models trained specifically to recognize obfuscation. The results suggest that protected Android code itself can become an object of automated model analysis. [5]

Acoda approached the problem from the defensive direction. Its researchers developed semantics-preserving transformations specifically intended to interfere with LLM-based code analysis. Across seven models, the paper reported attack success rates of up to 70%, using transformations designed to induce refusal or misanalysis behaviors in target models, while preserving program behavior. [6]

A machine analyst introduces defensive considerations that don't necessarily arise in exactly the same form when the analyst is human. Protection designed to slow a human reverse engineer needs to evolve as automated reasoning becomes a larger part of the attack process.

The immediate defensive objective remains familiar: raise the cost and complexity of analysis, interfere with clean experimentation, and make successful progression through the attack chain harder to automate.

Read more: App Threat Report 2026 Q1: The State of Code Obfuscation Against AI

Protect the techniques. Verify the state.

Mobile applications don't need to identify whether a human or an AI system initiated an attack technique before responding to the technique.

For example, a hook created by an agent is still a hook. Runtime instrumentation is still instrumentation. A repackaged client remains a repackaged client. An emulator doesn't become trustworthy because an AI system selected the emulator.

Promon Shield operates at a more fundamental layer by assuming the app runs in a hostile environment and then raising the bar for reverse engineering and runtime abuse, maintaining resilience to techniques such as hooking, instrumentation, tampering, repackaging, and emulation.

Agentic experimentation doesn't remove those obstacles. Faster retries still must contend with protection inside the application. New code still has to work against the real runtime. A different attack path still has to produce a useful result.

Making each successful step more expensive increases the work an agentic system must perform before the attack can progress.

Read more: AI-powered mobile app attacks: What app shielding can and can't stop

Make runtime state a condition for backend trust

Client protection, however, addresses only one part of the attack path.

Attackers ultimately want the compromised client to produce a useful outcome. Their objective might be access to sensitive data, performing an unauthorized transaction, bypassing entitlements, manipulation of AI-driven decisioning, or direct interaction with  backend APIs. The server therefore needs evidence about the state of the client before trusting the interaction and releasing sensitive data or functionality.

Promon Verify™ extends the trust model to the API layer by validating whether requests originate from a genuine application operating in an untampered runtime state. Backend trust does not have to depend only on the existence of a session or on a request having the expected shape. Verify can continuously attest the runtime state of the client behind the interaction.

Requiring runtime evidence prevents successful client-side manipulation from automatically becoming trusted backend access. An agent may reproduce expected session behavior or generate a correctly formed request.

The backend can still require evidence that the request originated from the genuine application and that the client passes integrity checks before sending sensitive data. The attacker still has to cross the trust boundary.

When the attacker becomes a loop, defense needs one too

The remaining challenge is response time.

When experimentation can continue without a human reviewing every failed hook, altered runtime condition, or unexpected application response, mobile defense can't depend entirely on a slower cycle of detection, manual investigation, development work, and a future application release.

Putting a better AI model on the defensive side is not, by itself, the answer. The defensive loop needs to become shorter.

Promon's runtime intelligence model starts with autonomous protection inside the application. The protected application generates trusted runtime signals at the point of attack. Runtime signals can then enrich fraud ecosystems and security tools. Findings are scored and can inform changes in detection, policy, and response.

Protect → Collect → Analyze → Adapt

Promon Insight for App Security™ adds visibility by turning Shield detections into structured runtime telemetry that security, fraud, and SOC teams can use. Promon Insight for App Risk™ provides actionable runtime decisioning, scored by Persistent App-ID that can even survive if the app is re-installed. Promon Control™ allows  security and fraud teams to adjust protection behavior, policies, and threat responses for mobile apps in production without re- shielding or re-submitting to the app store.

Read more: Learn globally, act locally: Why app security needs a runtime intelligence loop

Two loops, different objectives

The offensive and defensive loops have different objectives.

• An attacker uses repeated experimentation to find a route through the application and turn each result into information for the next attempt.

• The defender uses runtime protection to preserve application integrity while attacks happen, and runtime intelligence to turn evidence from protected applications into better protection and response.

The speed of the offensive loop increases the cost of relying on slow defensive feedback. An agentic attacker does not need to invent a completely new technique on every attempt. The attacker needs only to test combinations, learn from the result, and make the next attempt cheap enough to continue.

Any absence of a documented end-to-end agentic mobile campaign therefore sets an evidence boundary. The absence doesn't set a starting date for defensive preparation.

PromptSpy has already demonstrated AI-driven adaptation inside malicious Android execution. Research shows that models can analyze protected Android code. The next stages of agentic capability can reduce the human effort involved in examining an application, testing protections, interpreting failures, and selecting another route.

Mobile defense should address the parts of the attack chain that remain necessary regardless of who, or what, makes the next decision.

Protect the code. Detect manipulation while the application runs. Verify the runtime state before the backend grants access. Collect evidence from attacks occurring in the field and use the evidence to adapt protection and response policies.

AI doesn't need to own the entire mobile attack chain before the economics of attacking the application begin to change. When the attacker becomes a loop, defense needs one too.

References

[1] ESET Research, ESET Research discovers PromptSpy, the first Android threat to use generative AI, February 19, 2026.

[2] Google, GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access, May 11, 2026.

[3] Promon, Mobile malware threats in 2025: How mobile app vendors can stay safe, April 2, 2025.

[4] Promon, App Threat Report 2025 Q4: The State of Facial Recognition Security, December 3, 2025.

[5] Luca Ferrari et al., Evaluating LLMs for Obfuscation Detection and Classification in Android Apps, June 12, 2026.

[6] Hongzhou Rao et al., Acoda: Adversarial Code Obfuscation for Defending against LLM-based Analysis, June 10, 2026.