Sicherheit von KI-Agent-Skills: Warum Phone Agents Laufzeitprüfungen brauchen

Ein bestandener Scanner ist noch kein Vertrauensbeweis

Wer einen KI-Agent-Skill, ein Plugin oder ein Tool-Paket installiert, steht vor einer einfachen Frage: Sieht dieser Zusatz nur sauber aus, oder verhält er sich auch sauber? Genau hier liegt das Problem. Statische Scanner prüfen Code, Metadaten oder bekannte Muster vor der Nutzung. Das ist wichtig, aber nicht dasselbe wie Vertrauen. Ein Skill kann bei der Installation harmlos wirken und erst später riskantes Verhalten zeigen, zum Beispiel wenn er sich selbst entpackt, Befehle nachlädt, Daten anders weitergibt als erwartet oder eine scheinbar kleine Funktion mit zu vielen Rechten verbindet.

Am 6. Juli 2026 berichtete The Hacker News über SkillCloak-artige Techniken, mit denen bösartige KI-Agent-Skills statische Scanner umgehen können sollen. Die zugehörige arXiv-Preprint-Studie zu Cloak and Detonate beschreibt Scanner-Umgehung und einen verhaltensorientierten Prüfansatz namens SkillDetonate. Diese Ergebnisse sollten als Forschungssignal gelesen werden, nicht als endgültiger Branchenstandard. Trotzdem ist die Lehre klar: Installationsprüfung ist nur der Anfang.

Für Nutzer lautet die Entscheidungsregel: Ein Skill ist nicht sicher, nur weil er in einem Verzeichnis gut aussieht, eine freundliche Beschreibung hat oder einen einmaligen Check besteht. Entscheidend ist, welche Fähigkeiten er erhält, wann er sie nutzt, welche Daten er berührt und ob der Nutzer vor riskanten Schritten etwas sieht. Sicherheit von KI-Agent-Skills muss daher von der Frage bei der Installation zur Frage während der Ausführung wandern.

Entscheidend ist, was ein Skill während der Nutzung tut

Ein verhaltensorientierter Ansatz fragt nicht nur, was ein Skill behauptet, sondern was er tatsächlich macht. Welche Dateien öffnet er? Welche Eingaben gibt er an ein Modell weiter? Ruft er externe Dienste auf? Ändert er seine Befehle zur Laufzeit? Versucht er, Daten aus einem Kontext in einen anderen zu verschieben? Solche Fragen lassen sich mit rein statischer Analyse nur begrenzt beantworten, weil das riskante Verhalten oft erst in einer konkreten Aufgabe entsteht.

Deshalb gewinnen Laufzeit-Prüfungen von Berechtigungen an Bedeutung. Ein Skill kann in einer isolierten Umgebung beobachtet werden, bevor er echte Daten sieht. Datenflüsse können begrenzt werden: Ein Skill, der eine Nachricht zusammenfassen soll, braucht nicht automatisch Zugriff auf Kontakte, Dateien und Einstellungen. Eine Ausführungsumgebung kann protokollieren, welche Funktionen aufgerufen wurden, welche Daten ein Skill gelesen hat und welche Ausgabe daraus entstand. Wo es um Einwilligung und überprüfbare Historie geht, sind Berechtigungsprotokolle von KI-Agenten ein verwandtes Muster: Nicht jede Kontrolle muss alles mitschneiden, aber kritische Schritte müssen später verständlich sein.

Auch SkillDetonate-artige Forschung sollte man nüchtern lesen. Ein verhaltensorientierter Prüfer kann viele Risiken besser sichtbar machen als ein reiner Scanner. Er beseitigt aber nicht alle Risiken. Ein Skill kann auf seltene Eingaben reagieren, erst nach mehreren Schritten aktiv werden oder harmloses Verhalten mit gefährlichen Kontexten kombinieren. Die praktische Folgerung ist deshalb nicht blinder Alarmismus, sondern gestaffelte Kontrolle: beobachten, begrenzen, bestätigen lassen und protokollieren.

Warum Phone Agents das Risiko erhöhen

Bei einem Coding Agent kann ein bösartiger Skill Quellcode, Dateien oder Entwicklerumgebungen gefährden. Bei einem Phone Agent kommt eine persönlichere Ebene hinzu. Das Smartphone hält Nachrichten, Kontakte, Benachrichtigungen, Fotos, Standort, Kalender, Konten, Einstellungen und oft auch Arbeitsprofile. Wenn ein KI-Agent-Skill dort zu viele Rechte erhält, kann der Schaden nicht nur technisch sein. Er kann private Kommunikation, Identität, Termine, Zahlungswege oder Gerätesicherheit betreffen.

OWASP beschreibt im Kontext generativer KI Risiken wie Prompt Injection, Schwächen in der Herkunft und Verteilung von Komponenten, unsichere Plugin-Gestaltung, übermäßige Handlungsmacht und Offenlegung sensibler Informationen. Das OWASP GenAI Security Project ist deshalb ein nützlicher Rahmen, um Risiken von KI-Agent-Plugins nicht nur als Malware-Frage, sondern als Rechte- und Verhaltensfrage zu sehen. Ein Phone Agent sollte nicht allein deshalb handeln dürfen, weil ein Modell eine plausible Anweisung erhalten hat.

Android-Berechtigungen sind dabei echte Systemgrenzen. Die Android-Dokumentation zu Berechtigungen unterscheidet zwischen Fähigkeiten mit unterschiedlichem Risiko und macht deutlich, dass Zugriff auf Daten und Funktionen durch die Plattform vermittelt wird. Für Phone Agents bedeutet das: Berechtigungen für Phone Agents sind nicht austauschbar mit Nutzervertrauen. Ein Zugriff auf Benachrichtigungen, Kontakte oder Standort muss anders behandelt werden als eine harmlose Gerätestatus-Abfrage. Wo sensible Telefonkontexte verarbeitet werden, gehört auch die Wahl zwischen Cloud- oder lokaler KI-Agent zur Sicherheitsentscheidung.

Ein gutes Berechtigungsmodell fragt zur richtigen Zeit

Ein praktisches Berechtigungsmodell beginnt mit dem Prinzip der geringsten Rechte. Ein Skill für Erinnerungen braucht nicht automatisch Zugriff auf alle Nachrichten. Ein Skill für Zusammenfassungen muss nicht senden dürfen. Ein Skill für Einstellungen sollte nicht mehrere Systembereiche ändern können, nur weil er einmal gestartet wurde. Gute Produkte trennen Lesen, Vorbereiten und Ausführen. Sie behandeln jede Aktion mit Wirkung auf andere Apps, Daten oder Konten als eigenen Entscheidungspunkt.

Besonders wichtig sind Abfragen im richtigen Moment. Eine pauschale Zustimmung bei der Installation ist für Phone Agents zu grob. Nutzer verstehen Risiken besser, wenn die Nachfrage im Kontext erscheint: Dieser Agent möchte die letzte Benachrichtigung lesen, diesen Kontakt verwenden, diesen Entwurf öffnen oder diese Einstellung ändern. Vor sichtbaren Folgen sollte eine Bestätigung stehen. Eine Nachricht zu formulieren ist nicht dasselbe wie sie zu senden. Eine Datei zu finden ist nicht dasselbe wie sie zu teilen. Eine Einstellung zu öffnen ist nicht dasselbe wie sie umzuschalten.

Protokolle schließen den Kreis. Nach einer Aufgabe sollte nachvollziehbar sein, welcher Skill beteiligt war, welche Berechtigung genutzt wurde, welche App betroffen war und ob der Nutzer bestätigt hat. Unternehmen brauchen darüber hinaus Richtlinien, zentrale Freigaben, Monitoring und Vorfallprozesse; Sicherheit von KI-Agenten im Unternehmen ist breiter als ein einzelner Berechtigungsdialog auf dem Telefon. Für Verbraucher reicht aber schon viel, wenn ein Phone Agent nicht im Hintergrund verschwindet, sondern seine Schritte sichtbar macht.

Checkliste: So bewerten Nutzer KI-Agent-Skills

Eine nicht alarmistische Prüfung beginnt bei der Herkunft. Wer hat den Skill erstellt? Wird er gepflegt? Welche Rechte fordert er? Passt die geforderte Berechtigung zur Aufgabe? Ein Skill, der eine Einkaufsliste sortieren soll, braucht keine umfassenden Nachrichtenrechte. Ein Skill, der Kontakte verwalten soll, sollte klar erklären, ob er nur liest, Vorschläge macht oder Änderungen schreibt. Wenn die Beschreibung vage bleibt, ist Zurückhaltung sinnvoll.

Der zweite Blick gilt dem Verhalten. Gibt es eine Vorschau, bevor eine Aktion ausgeführt wird? Wird der Nutzer vor dem Senden, Löschen, Teilen oder Ändern gefragt? Kann man sehen, welche Daten genutzt wurden? Gibt es eine Aufgabenhistorie? Lässt sich ein Skill deaktivieren, Rechte entziehen oder einzeln begrenzen? Gute Sicherheit muss im Alltag verständlich bleiben. Nutzer sollten nicht erst Entwicklerwerkzeuge öffnen müssen, um zu erkennen, ob ein Agent gerade liest, plant oder handelt.

Drittens sollte man prüfen, wie das Produkt mit Fehlern umgeht. Was passiert, wenn der Skill eine Anweisung missversteht? Was passiert bei Prompt Injection in einer Nachricht oder Webseite? Was passiert, wenn ein Skill eine externe Verbindung aufbauen will? Gibt es klare Stopps, oder läuft die Aufgabe weiter? Die beste Faustregel lautet: Je näher ein Skill an privaten Telefonaktionen arbeitet, desto stärker müssen Rechte, Bestätigung und Protokollierung sein.

Was FoneClaw aus Skill-Sicherheit lernen sollte

FoneClaw ist unabhängig von The Hacker News, den arXiv-Autoren, OWASP, Android, Google, Claude Code, OpenAI Codex, OpenClaw und Sicherheitsanbietern. Es gibt keinen Grund zu behaupten, FoneClaw sei von SkillCloak betroffen, scanne Drittanbieter-Skills oder könne Sicherheit garantieren. Der sinnvolle Bezug ist ein Produktprinzip: Ein Android Phone AI Agent sollte unterstützte Telefonaktionen sichtbar, berechtigungsbewusst und bestätigungsorientiert behandeln.

Für FoneClaw heißt das: Der Agent sollte nicht nur fragen, was der Nutzer will, sondern auch welche App, welche Daten und welche Wirkung betroffen sind. Ein Entwurf, eine Suche, eine Einstellung, eine Benachrichtigung und ein gesendeter Inhalt brauchen unterschiedliche Schutzstufen. Wenn ein Skill oder eine Erweiterung in einem Agentenablauf beteiligt ist, sollte der Nutzer erkennen können, welche Rolle sie spielt. Je stärker ein Skill auf Telefonfunktionen einwirkt, desto weniger reicht ein einmaliger Installationscheck.

Die langfristige Lehre ist klar und unaufgeregt. KI-Agenten werden nützlicher, wenn sie mehr Aufgaben übernehmen können. Sie werden aber nur vertrauenswürdig, wenn sie ihre Rechte begrenzen, riskante Schritte erklären, rechtzeitig um Zustimmung bitten und eine verständliche Historie hinterlassen. Für Phone Agents ist Sicherheit keine unsichtbare Hintergrundfunktion. Sie ist Teil der Nutzererfahrung: sehen, prüfen, bestätigen, später nachvollziehen.