Skip to content
PERMISSION/PROTOCOL
Back to incident tracker

2026-10-11

MediumPrimary

Prompt Injection Can Make an Android Agent Commit Attacker-Directed Message Writes

Ahn and Lee report controlled Android-agent tests in which a Qwen2.5-7B planner selected attacker-directed message actions and an AppFunction inserted.

Android AppFunctions / Qwen2.5-7BGovernance bypassControlled agent-action researchAppFunction provider before a message write is committed

What happened

Committing a message to an attacker-selected destination and payload in the experimental provider

Why it matters

Author-reported local in-memory message writes; no durable storage or external delivery established.

Missing authorization check

Independent authorization for committing a message to an attacker-selected destination and payload in the experimental provider

Would PP block it?

The enforcement point would need to verify the caller, resolved operation, target, parameters and approved task before execution. This is a conditional assessment, not a demonstrated PP prevention result for this case.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-10-11

    The cited source discloses the behavior documented in this record.

Technical breakdown

  • Ahn and Lee report controlled Android-agent tests in which a Qwen2.5-7B planner selected attacker-directed message actions and an AppFunction inserted matching messages into an in-memory provider store. Without the provider check, attack-target messages committed in 10 of 10 recorded attack trials. A separate application-source monitor withheld selected attack writes but also blocked benign work and carried source records into later tasks. These were local fixture writes, not externally delivered messages or a production compromise.
  • Committing a message to an attacker-selected destination and payload in the experimental provider
  • Author-reported local in-memory message writes; no durable storage or external delivery established.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Governance bypass. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
AppFunction provider before a message write is committed
Still needs
PP does not repair the underlying application or sandbox, infer valid authority from a prompt, or cover direct effects that bypass an integrated gate. Separate isolation and least-privilege controls remain necessary.
Receipt required for
Committing a message to an attacker-selected destination and payload in the experimental provider

An independent authorization boundary could hold the described operation when the exact action is routed through an integrated enforcement point.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop