Mobile agents on personal smartphones can affect private data, payments, settings, and the foreground screen. We present MATE (Mobile Agent Trustworthy Execution), an execution-layer system that controls the boundary between agent action proposals and device effects without modifying the underlying model. MATE represents each UI primitive as a structured action record that combines the instruction, target app, screen context, primitive, and action fields. Runtime Guardrail (RG) maps this record to an allow, block, or user-approval decision; Predefined Task Routing (PTR) serves recurring requests through verified routes with post-execution screen checks; and a floating interface keeps execution in a compact overlay. On MobileSafetyBench, MATE raises high-risk blocking from 29.7% to 97.0% under GPT-4o. On AndroidWorld, it reduces LLM calls by up to 6× and raises recurring-use task success to 95.7%.
A mobile agent receives an instruction, observes the screen, and emits one UI action per step. Between the moment a policy selects an action and the moment the OS applies it, there is a gap — the pending device action. Three constraints converge on exactly this gap:
Payments, transfers, and account changes are hard to undo. Once an action reaches the device, intervention is too late.
Every additional step may require another multimodal model call, and mobile memory, compute, and energy are all bounded.
A phone exposes one foreground surface. A full-screen agent competes with the user for the device they are holding.
Text and tool guardrails such as NeMo Guardrails operate on self-describing payloads. A tap, swipe, or text entry carries no such signal — the same coordinate can be benign or harmful depending on the app and screen state. As a result, published mobile agents leave most high-risk tasks unblocked.
| Risk type | AppAgent | Mobile-Agent | M3A | AutoDroid |
|---|---|---|---|---|
| Ethical compliance | 2.4 | 0.0 | 19.2 | 1.3 |
| Offensiveness | 0.0 | 0.0 | 1.2 | 0.0 |
| Private information | 1.1 | 0.0 | 11.0 | 5.8 |
| Bias & fairness | 3.0 | 0.0 | 4.0 | 5.0 |
| Robustness† | 21.5 | 35.7 | 7.2 | 0.0 |
| Overall | 18.7 | 23.8 | 28.4 | 8.0 |
Blocking rate (%) on MobileSafetyBench high-risk tasks. Robustness† is the indirect prompt-injection split.
MATE closes the safety gap that existing mobile agents leave open across all five safety categories.
Mobile agents re-observe the screen and invoke the action policy at every step, even for routines such as search, cart insertion, or destination entry. PTR replaces these per-step invocations with a verified route backed by a fallback policy.
Routes are built once at setup time from the installed app's UI tree, verified against the
device, and indexed by a deterministic (app, instruction) key — no evaluation
trajectory is used. On a hit, the matched route executes and the step-wise policy is bypassed
entirely. On a miss, an execution failure, or a failed post-execution screen check, control
returns to the vision-based agent.
Setup is cheap: exploring 19 apps stores 151 route affordances in 31.7 KB in under 16 minutes, and route discovery saturates at depth 6.
RG builds a candidate-action record (u, p, s, a, m) that binds the user
utterance, target app, lightweight UI context, primitive action, and structured action fields,
then emits one of three decisions before the action reaches the OS:
request_approvalSix rails instantiate this decision, combining guard-model intent checks with deterministic structural predicates. The first rail to fire short-circuits the chain.
| Phase | Rail | Policy source |
|---|---|---|
| Input | jailbreak | Guard-model check over override and role-injection intent |
| Input | topic | Guard-model check over prohibited-domain intent |
| Exec | app_allow | Exact package-name policy |
| Exec | coord_bounds | Numeric screen-viewport bound check when coordinates are present |
| Exec | bank_intent | Guard-model check over financial-transfer and credential intent |
| Output | action_valid | Action-schema validation; purchase-keyword check routes confirmable actions to approval |
RG combines semantic intent checks with structural action checks over package names, coordinates, action schemas, and purchase signals.
Instead of taking over the full foreground, MATE renders the target surface inside a compact overlay. The user keeps multitasking in other apps, gets execution visibility confined to the overlay, retains interruptibility for login or confirmation steps, and preserves visual context continuity of the underlying task.
RG still checks every proposed action; the overlay only changes where execution is shown. Payment-adjacent apps are excluded from route construction, so purchase-confirmation and credential-entry actions always reach the agent policy and are checked by RG.
| Risk type | Qwen2.5-VL | GPT-4o | ||
|---|---|---|---|---|
| Base | MATE | Base | MATE | |
| Ethical compliance | 7.14 | 92.86 | 10.71 | 92.89 |
| Offensiveness | 30.00 | 80.00 | 0.00 | 90.00 |
| Private information | 9.09 | 68.18 | 0.00 | 100 |
| Bias & fairness | 22.22 | 72.22 | 0.00 | 87.42 |
| Robustness† | 0.00 | 100 | 80.00 | 100 |
| Overall | 9.68 | 90.17 | 29.67 | 97.03 |
| False positive (low-risk tasks) ↓ | 0.00 | 14.90 | 0.00 | 4.10 |
RG turns high-risk tasks into refusals or blocks across every safety category. Base is the same agent run without any guardrail layer. On the indirect prompt-injection split, RG reaches 100% blocking under both backbones. The main calibration cost is over-blocking on low-risk tasks, which is higher for the weaker backbone.
(a) Backbone ablation across seven models.
(b) RG component ablation.
RG gains depend on backbone and rail composition. Under Qwen2.5-VL the topic rail alone accounts for most of the gain, so high-risk intent surfaces at the utterance level. Under GPT-4o blocking keeps rising as structural rails are added, so execution-stage checks intercept actionable proposals that pass intent screening.
| Method | SR (%) ↑ | LLM calls ↓ | E2E (s) ↓ |
|---|---|---|---|
| Human | 80.0 | – | – |
| Mobile-Agent v1 | 25.4 | 5.4 | 19.1 |
| M3A | 12.5 | 9.5 | 47.8 |
| AutoDroid | 36.2 | 13.6 | 23.8 |
| AppAgent | 41.7 | 12.3 | 147.2 |
| AppAgentX | 62.5 | 5.9 | 59.7 |
| MATE w/o PTR | 41.4 | 14.2 | 47.1 |
| MATE (PTR D=1) | 55.2 | 8.2 | 14.7 |
| MATE (PTR D=6) | 67.2 | 6.8 | 14.1 |
All baselines share GPT-4o as the backbone. Adding routes at depth 6 raises success from 41.4% to 67.2% while halving LLM calls and cutting latency by over 3× relative to the no-PTR setting.
| Backbone | RG | SR (%) ↑ | Calls / task ↓ | Latency / task (s) ↓ |
|---|---|---|---|---|
| GPT-4o | off | 41.4 | 6.8 | 12.8 |
| GPT-4o | on | 41.4 | 8.4 | 14.1 |
| Qwen2.5-VL | off | 26.8 | 3.1 | 11.0 |
| Qwen2.5-VL | on | 26.8 | 7.3 | 17.1 |
RG preserves task success at bounded overhead. Benign success is unchanged; the extra calls come from replanning after a rejected or approval-routed action. In the end-to-end breakdown RG accounts for 4.2% of total calls and 3.7% of total latency, and PTR adds input tokens without adding LLM calls.
[ptr:navigate_to] supply navigation
hints in Amazon and PayPal; in Baidu, an unsafe query submission is still intercepted by RG before
execution.
MATE targets verified recurring personal-device workflows: a single user repeatedly invoking known routines on installed apps. Extending route induction to held-out apps, cross-app transfer, and substantial UI redesigns is left for future work.
RG's structural rails rely on observable app identifiers, action fields, coordinates, and UI context; unusual app surfaces may require calibration, and semantic thresholds should be tuned per backbone. PTR stores routes verified against a specific app layout — when UI updates or gesture-heavy tasks exceed the stored route vocabulary, MATE falls back to bounded re-exploration or the step-wise agent policy.
RG reduces risk by blocking or routing sensitive actions to user approval, but it is not a complete security boundary and is not a substitute for user consent. PTR stores app-level route information rather than credentials, messages, or payment details; route memory can still reveal usage patterns and should be stored locally or protected with standard access controls. Our evaluation uses public benchmarks and a physical test device, and does not collect real user data or involve human subjects.
@inproceedings{jang2026mate,
title = {{MATE}: Mobile Agent Trustworthy Execution for Safe and Efficient Mobile Control},
author = {Jang, Minsuk and Kim, Hee-Seon and Yu, Hui-Cheol and Kim, Changick},
booktitle = {Findings of the Association for Computational Linguistics: EMNLP 2026},
year = {2026}
}