Ein Mitarbeiter bittet einen mobilen KI-Agenten, auf dem Smartphone eine Nachricht zu versenden, einen Termin einzutragen oder eine Reservierung zu erledigen. Der Agent liest den Bildschirm aus, interpretiert ihn mit einem Vision-Language-Modell und steuert das Gerät über Android Debug Bridge, Accessibility-Funktionen oder eine Hilfstastatur. Für den Nutzer sieht das nach bequemer Automatisierung aus. Aus Sicherheitssicht entsteht jedoch eine neue Kette privilegierter Vertrauensentscheidungen: vom angezeigten Display über das Modell bis zum steuernden Rechner.
Eine am 21. Juli bekannt gewordene Untersuchung zeigt, wie fragil diese Kette ist. Forschende der Simon Fraser University, der Chinese University of Hong Kong, der Shandong University und von Xingtu Lab analysierten fünf quelloffene Frameworks: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM und MobA. Das auf arXiv veröffentlichte Paper beschreibt sieben Angriffe. Jedes getestete Framework war für mindestens sechs davon anfällig. Der Kern des Problems ist keine einzelne spektakuläre Schwachstelle, sondern eine falsche Systemannahme: Der Agent vertraut Bilddaten und Kommunikationskanälen, die andere Apps manipulieren können.
Das Praxisproblem: Der Mensch kontrolliert nicht den Input des Agenten
Klassische Freigabedialoge funktionieren nur, wenn Mensch und System denselben Sachverhalt sehen. Bei visuellen Agenten ist genau das nicht mehr garantiert. Ein Screenshot enthält auch Pixel, deren Kontrast für Menschen kaum wahrnehmbar ist. Er kann zudem Bereiche erfassen, die durch abgerundete Displayecken oder Kameras verdeckt sind. Ein Agent kann dadurch Anweisungen lesen, die für seinen Bediener praktisch unsichtbar bleiben.
Im Labor renderten die Forschenden Text mit nur zwei Prozent Deckkraft. GPT-4o, Claude Opus 4.5, Gemini 3 Pro und GLM-4V erkannten ihn jeweils in 20 von 20 Versuchen. Qwen3-VL-Plus kam auf 19 von 20, das kleinere AutoGLM-Phone auf 18 von 20. Diese Werte sind keine Erfolgsquoten für reale Angriffe. Sie zeigen aber, dass „für den Menschen unsichtbar“ kein verlässliches Sicherheitskriterium für maschinelle Bildschirmwahrnehmung ist.
Dazu kommt UI-Spoofing. Eine schädliche App kann eine täuschend echte Anmeldemaske über eine legitime Anwendung legen. In der Studie gaben alle fünf Agenten in 100 Versuchen die vorgesehenen Test-Zugangsdaten in die gefälschte Oberfläche ein. Dem Agenten fehlt die menschliche Skepsis gegenüber einem unerwarteten Dialog. Zugleich erhält er keinen kryptografischen Nachweis darüber, welche App die Oberfläche tatsächlich erzeugt hat.
Vom manipulierten Screenshot zur Codeausführung auf dem PC
Die gefährlichste Demonstration kombiniert drei Schwächen. Mehrere Frameworks erzeugen zunächst einen Screenshot auf dem gemeinsam erreichbaren Gerätespeicher und laden ihn anschließend per ADB auf den Host. Zwischen Erzeugung und Abruf maß das Team ein Zeitfenster von 50 bis 500 Millisekunden, im Mittel rund 210 Millisekunden. Eine Hintergrund-App konnte vorhersehbare Dateien in diesem Fenster austauschen. Bei vier Frameworks gelang die Manipulation in 19 von 20 bis 20 von 20 Versuchen. MobA war hier nicht betroffen, weil es Bilddaten direkt über exec-out streamt und keine temporäre Screenshot-Datei auf dem Gerät ablegt.
Die manipulierte Aufnahme brachte den Agenten dazu, einen präparierten Text einzugeben. Im öffentlich einsehbaren AppAgent-Code landet dieser Modell-Output in einem ADB-Befehl, der mit shell=True gestartet wird. Die aktuelle Implementierung entfernt zwar Leerzeichen und einfache Anführungszeichen. Andere Shell-Metazeichen bleiben jedoch erhalten. Damit kann eine vermeintliche Texteingabe auf dem Smartphone in einen separaten Befehl auf dem steuernden Rechner kippen.
Im kontrollierten End-to-End-Versuch schrieb ein harmloser Proof of Concept das aktuelle Arbeitsverzeichnis des Hosts in eine Datei. Vier der fünf Frameworks waren in den Einzeltests zur Host-Kommandoinjektion in 20 von 20 Versuchen anfällig. Open-AutoGLM blockierte diesen konkreten Schritt durch strukturierte Argumentübergabe beziehungsweise Kodierung, blieb laut Paper aber für andere Wahrnehmungs- und Kanalangriffe offen.
Debug-Schnittstellen werden zur Produktionsinfrastruktur
Der Branchenkontext reicht über Android hinaus. Mobile Agenten nutzen ADB, Accessibility Services, implizite Broadcasts und Test-Tastaturen, weil Android bislang keinen speziell abgesicherten Kanal für autonome Drittanbieter-Agenten bietet. Damit werden Entwicklerwerkzeuge zu Laufzeitkomponenten für Prozesse, die Nachrichten, Passwörter oder Geschäftsdaten verarbeiten.
Ein Beispiel ist die Texteingabe über ADB Keyboard. Einige Frameworks senden Unicode-Inhalte über einen impliziten Android-Broadcast. Eine andere App kann denselben Broadcast empfangen, ohne dass der Nutzer es bemerkt. In den passenden Testkonfigurationen gelang die Interzeption bei Open-AutoGLM sowie den hybriden Eingabepfaden von Mobile-Agent-v3 und MobA in allen 20 Versuchen. Das ist nicht nur eine Schwachstelle der Hilfstastatur. Problematisch ist vor allem, dass der Agent einen für Testautomation gedachten, nicht authentisierten Kanal als vertrauenswürdige Eingabeschicht behandelt.
Was Unternehmen jetzt prüfen sollten
Unternehmen sollten mobile Agenten derzeit als privilegierte Automatisierungssoftware behandeln, nicht als gewöhnliche Assistenten. Fünf Punkte sind besonders relevant:
- Einsatzgrenzen definieren: Forschungsprototypen gehören nicht auf Geräte mit produktiven Konten, Passwörtern, MDM-Ausnahmen oder Zugriff auf interne Systeme. USB- und Wireless-Debugging sollten auf verwalteten Endgeräten nicht dauerhaft aktiviert sein.
- Bildpfade absichern: Screenshots sollten ohne gemeinsam beschreibbare Zwischendatei direkt in einen isolierten Prozess gestreamt werden. Temporäre Dateien brauchen private Speicherbereiche, zufällige Namen, kurze Lebensdauer und Integritätsprüfung.
- Shell-Aufrufe eliminieren: Modell-Output darf nie in Befehlsstrings gelangen. Prozesse müssen strukturierte Argumentlisten verwenden; Shell-Expansion sollte deaktiviert sein. Das ist eine Plattformkontrolle und darf nicht von der Einschätzung des Modells abhängen.
- Kanäle authentisieren: Implizite Broadcasts sind durch explizite Intents oder signaturgeschützte Berechtigungen zu ersetzen. Accessibility-Zugriffe und Overlays sollten per Richtlinie minimiert und überwacht werden.
- Freigaben semantisch erzwingen: Bestätigungen für Passwort-, Zahlungs-, Datei- und Administrationsaktionen müssen außerhalb des Modells ausgelöst werden. Der Agent darf nicht selbst entscheiden, ob eine durch möglicherweise manipulierte Wahrnehmung ausgelöste Aktion „sensibel“ ist.
Auch die Testpraxis muss sich ändern. Prompt Injection in Textfeldern reicht als Prüfszenario nicht aus. Realistische Red-Teams brauchen halbtransparente Overlays, gefälschte Aktivitäten, manipulierte Screenshots, Displayaussparungen und feindliche Apps auf demselben Gerät. Entscheidend ist die gesamte Wahrnehmungs-Entscheidungs-Aktionskette — einschließlich Host-PC und Unternehmensnetz.
Risiken und Grenzen der Forschung
Die Ergebnisse stammen aus kontrollierten Laborversuchen. Nach Angaben der Forschenden und der Berichterstattung gibt es keinen Beleg für Angriffe in freier Wildbahn. Untersucht wurden fünf quelloffene Drittanbieter-Frameworks auf Android, nicht vorinstallierte Assistenten, iOS-Systeme oder proprietäre Unternehmensprodukte. Mehrere Varianten setzen eine bereits installierte schädliche App, aktiviertes Debugging und einen laufenden Agenten voraus. In der Praxis können Erfolgsraten wegen anderer Oberflächen, Modellstochastik und zusätzlicher Schutzmechanismen niedriger ausfallen.
Gerade diese Einschränkungen sind wichtig. Die Arbeit belegt keine akute Massenkompromittierung. Sie beschreibt eine Architekturklasse, deren Sicherheitsgrenzen noch nicht ausgereift sind. Einzelne Gegenmaßnahmen lösen das Problem nur teilweise. Kontrastfilter können schwache Einblendungen sichtbar machen oder entfernen, erkennen aber nicht jede visuelle Manipulation. Nutzerfreigaben helfen nur, wenn eine unabhängige Komponente die riskante Aktion zuverlässig identifiziert.
Fazit
Mobile KI-Agenten verbinden zwei Systeme mit unterschiedlichen Sicherheitsmodellen: ein Mehr-App-Smartphone und einen Host, auf dem Modell, Werkzeuge und Zugangsdaten liegen. Sobald Screenshots als vertrauenswürdiger Zustand gelten und Debug-Kanäle zur Produktionsschnittstelle werden, kann eine unprivilegierte App Einfluss bis zum steuernden Rechner gewinnen.
Die angemessene Reaktion ist weder Panik noch ein weiterer Prompt-Filter. Unternehmen sollten mobile Agenten nur in isolierten Umgebungen pilotieren und Wahrnehmung, Kommunikation sowie Ausführung technisch voneinander trennen. Das Modell darf Inhalte interpretieren. Ob diese Inhalte authentisch sind und welche Wirkung eine Aktion entfalten darf, muss die Plattform entscheiden.
