Speichervergiftung bei KI-Agenten auf dem Handy

Was Memory Poisoning bei KI-Agenten bedeutet

Memory Poisoning bei KI-Agenten beschreibt den Versuch, fremde, falsche oder eigennützige Informationen in den dauerhaften Speicher eines Assistenten zu bringen, damit spätere Antworten, Empfehlungen oder Prioritäten beeinflusst werden. Der Kern ist Persistenz: Es geht nicht nur um eine schlechte Einzelantwort, sondern um eine gespeicherte Erinnerung, Präferenz oder Regel, die in späteren Unterhaltungen wieder auftauchen kann.

Ein einfaches Beispiel: Ein Assistent merkt sich, dass ein Nutzer bei zukünftigen Kaufempfehlungen eine bestimmte Firma bevorzugt. Wenn diese Erinnerung vom Nutzer bewusst gesetzt wurde, kann sie hilfreich sein. Wenn sie über einen fremden Link, einen vorausgefüllten Prompt oder versteckte Anweisungen eingeschleust wurde, wird aus Personalisierung ein Sicherheitsproblem. Die Manipulation liegt dann nicht im Modelltraining, sondern in der gespeicherten Ebene, die der Assistent später für Empfehlungen nutzt.

Microsoft verwendet für einen Teil dieses Musters den Begriff AI Recommendation Poisoning: beobachtete Versuche, künftige Empfehlungen zugunsten einer Marke, Firma oder Quelle zu verschieben. Wichtig ist die Grenze: Nicht jede Ask-AI-Schaltfläche ist schädlich, und nicht jeder Versuch wird gespeichert. Plattformen unterscheiden sich bei Speicherfunktionen, Schutzmaßnahmen, Sichtbarkeit und Löschbarkeit. Genau deshalb braucht der Nutzer auf dem Telefon einen prüfbaren Ablauf: Was wurde gesendet, was wurde gespeichert, wofür gilt es, und wie lässt es sich wieder entfernen?

Bei FoneClaw betrachten wir diese Frage aus Builder-Sicht. Ein Phone Agent wird nur dann vertrauenswürdig, wenn Kontext, Aktionen und gespeicherte Informationen unterscheidbar bleiben. Persönlicher Kontext ist wertvoll, wenn er vom Nutzer kontrolliert wird; die breitere Produktchance behandeln wir in KI-Agent mit persönlichem Kontext: Warum Phone Agents ihn brauchen. Dieser Leitfaden konzentriert sich auf die Sicherheitsseite: Wie erkennt man riskante Speicherpfade, wie prüft man Herkunft, und wie begrenzt man mögliche Manipulation von KI-Empfehlungen?

Wie Ask-AI-Schaltflächen gespeicherte Empfehlungen erreichen können

Der kritische Pfad beginnt oft unscheinbar. Eine Webseite, E-Mail, App oder ein Dokument zeigt eine Schaltfläche mit einem freundlichen Label wie Ask AI, Zusammenfassen mit KI oder Frage den Assistenten. Der Nutzer erwartet eine neutrale Zusammenfassung oder Erklärung. Tatsächlich kann der dahinterliegende Link jedoch zusätzlichen Text enthalten, der den Assistenten nicht nur um eine Antwort bittet, sondern auch eine gewünschte Präferenz oder Erinnerung nahelegt.

Microsoft beschreibt in seinem Bericht zu AI Recommendation Poisoning, dass speziell vorbereitete URLs hinter KI-Schaltflächen genutzt wurden, um Prompts vorzubelegen. Der Versuch kann darin bestehen, den Assistenten dazu zu bringen, eine Firma künftig zu bevorzugen, eine Quelle als besonders relevant zu behandeln oder eine Empfehlung dauerhaft in eine bestimmte Richtung zu lenken. Wir beschreiben hier bewusst keine ausführbaren Muster; für Nutzer reicht das Prinzip: Das sichtbare Label zeigt nicht zuverlässig, welcher Text tatsächlich mitgesendet wird.

Auf dem Telefon ist dieser Pfad besonders leicht zu übersehen. Links werden gekürzt, Vorschauen sind klein, Apps öffnen schnell einen Assistenten, und ein vorausgefüllter Prompt sieht wie normale Hilfestellung aus. Der Nutzer tippt auf eine Schaltfläche, der Assistent öffnet sich, der Text ist bereits eingesetzt, und die eigentliche Anweisung steckt zwischen harmlosen Zusammenfassungswünschen. Wenn der Assistent eine Speicherfunktion besitzt, entsteht daraus der Versuch, nicht nur diese eine Antwort, sondern spätere Empfehlungen zu beeinflussen.

Die richtige Sicherheitsfrage lautet daher nicht, ob KI-Schaltflächen grundsätzlich schlecht sind. Viele sind nützlich. Die Frage lautet: Kann ich vor dem Absenden sehen, welcher Inhalt und welche Anweisung an den Assistenten gehen? Kann ich trennen, was zusammengefasst werden soll, von dem, was der Assistent künftig glauben oder speichern soll? Und kann ich später prüfen, ob daraus eine Erinnerung entstanden ist?

Speichervergiftung von Prompt-Injektion und vergifteten Trainingsdaten abgrenzen

Für eine saubere Diagnose müssen drei verwandte Probleme getrennt werden. Prompt Injection zielt meist auf die aktuelle Aufgabe: Ein fremder Text in einer Webseite, E-Mail oder Datei versucht, den Assistenten im Moment zu einer falschen Handlung oder Antwort zu bewegen. Das kann gefährlich sein, auch wenn danach nichts gespeichert wird.

Memory Poisoning zielt auf gespeicherte Informationen. Eine Anweisung, Präferenz oder angebliche Tatsache soll dauerhaft oder längerfristig in den Assistentenspeicher gelangen. Der Schaden zeigt sich später: Der Assistent empfiehlt immer wieder dieselbe Firma, bevorzugt eine Quelle, verändert Prioritäten oder behandelt eine fremde Behauptung wie eine Nutzerpräferenz.

Trainingsdatenvergiftung liegt noch weiter vorgelagert. Dort werden Daten manipuliert, die in das Training oder eine allgemeine Wissensbasis eines Modells eingehen. Dieser Artikel handelt nicht davon. Auf dem Smartphone interessiert uns vor allem die Ebene, die der Nutzer beeinflussen, prüfen oder löschen kann: Gesprächskontext, übergebene Inhalte, gespeicherte Erinnerungen, Personalisierung und verbundene Assistentenfunktionen.

Eine verdächtige Empfehlung allein beweist also nicht, welcher Mechanismus dahinterliegt. Sie ist ein Anlass zur Prüfung, nicht das Ergebnis der Prüfung.

Was Microsoft beobachtet hat und was die Zahlen nicht beweisen

Microsoft meldete im Februar 2026 mehr als 50 einzigartige Prompts von 31 Unternehmen aus 14 Branchen, die versuchten, künftige KI-Empfehlungen zu beeinflussen. Der Bericht ist deshalb wichtig, weil er nicht nur theoretische Prompt Injection beschreibt, sondern einen Weg in Richtung gespeicherter Präferenzen und Empfehlungen sichtbar macht: vorbefüllte KI-Anfragen, die Nutzer über scheinbar hilfreiche Schaltflächen auslösen.

Gleichzeitig muss man die Zahlen eng lesen. Sie belegen beobachtete Versuche, nicht automatisch erfolgreiche dauerhafte Speichervergiftung bei jedem Assistenten. Microsoft beschreibt, dass die Wirksamkeit je nach Assistent und Zeitpunkt unterschiedlich war und sich Verhalten mit Schutzmaßnahmen verändert hat. Außerdem berichtet Microsoft, dass in Copilot Gegenmaßnahmen eingesetzt wurden und manche frühere Beobachtung später nicht mehr reproduzierbar war.

Für Android-Nutzer folgt daraus eine nüchterne Regel: Behandeln Sie die Technik als realen Risikopfad, aber vermeiden Sie pauschale Schlüsse. Ein Assistent mit stark begrenztem oder transparentem Speicher verhält sich anders als ein Assistent mit weitreichender Personalisierung. Ein Unternehmensassistent mit Admin-Kontrollen unterscheidet sich von einer privaten App. Und eine Plattform, die fremde Prompt-Parameter herausfiltert, reduziert andere Risiken als eine Plattform, die vorbefüllte Inhalte unkritisch übernimmt.

MITRE ATLAS katalogisiert Memory Poisoning als AML.T0080. Das hilft bei der Einordnung als Angriffstechnik gegen den Speicher eines KI-Systems. Es beweist aber nicht, dass ein bestimmter Assistent, ein bestimmtes Telefon oder eine bestimmte App kompromittiert wurde. Für die Praxis zählt die Kombination aus beobachtbarem Verhalten, Speicherprüfung, Herkunft und Wiederholungstest.

Warum Herkunft, Versionen und Speicherumfang zählen

Guter KI-Speicher braucht Herkunft. Der Nutzer oder Betreiber muss nachvollziehen können, woher eine Erinnerung kommt, wann sie entstanden ist, für welchen Assistenten oder welche Aufgabe sie gilt, welche Version aktiv ist und ob sie aus einem Rohgespräch, einer abgeleiteten Präferenz oder einer expliziten Nutzereinstellung stammt. Ohne diese Provenienz wird jede spätere Empfehlung schwer zu untersuchen.

Das TencentDB Agent Memory-Projekt ist dafür ein nützliches Architekturbeispiel. Es modelliert Chat Memory, Skills, Wiki und CodeGraph als verwaltete Speicherobjekte mit Eigentümer, Versionen, Status, Sichtbarkeit, Nutzung und Agentenbindung. Die dokumentierten Schichten behalten Rohgespräche auf L0 und leiten daraus L1-Atome, L2-Szenarien sowie L3-Core- oder Persona-Informationen ab.

Wir behandeln TencentDB Agent Memory hier nicht als Handy-Schutzprodukt und nicht als FoneClaw-Verhalten. Der Wert liegt im Prinzip: Wenn aus flüchtigem Gespräch dauerhafte Erinnerung wird, sollte sichtbar sein, welche Quelle diese Erinnerung hatte und welche Ableitung daraus entstanden ist. Eine manipulierte Webseite darf nicht denselben Vertrauensstatus haben wie eine vom Nutzer bestätigte Präferenz.

Für Phone Agents ist außerdem der Geltungsbereich entscheidend. Eine Erinnerung kann nur für eine Sitzung, eine App, eine Aufgabe, ein Konto oder den gesamten Assistenten gelten. Je größer der Umfang, desto größer das Risiko, dass eine fremde Einwirkung künftige Empfehlungen breit verzerrt. Wer hybride Speicherarchitekturen genauer einordnen möchte, findet die passende Vertiefung in Hy-Memory Serverstatus vs lokale Agenten-Erinnerung: Was Android-Nutzer wissen sollten. In diesem Artikel bleibt die Verteidigungsregel: Keine dauerhafte Erinnerung ohne prüfbare Herkunft, sichtbaren Umfang und bearbeitbare Kontrolle.

Checkliste vor dem Senden von Inhalten an einen KI-Assistenten

Auf dem Smartphone beginnt Sicherheit vor dem Absenden. Eine Ask-AI-Schaltfläche, ein Teilen-Menü, ein kopierter Text, eine E-Mail, ein PDF, eine Webseite oder ein Screenshot kann nützlichen Kontext enthalten. Derselbe Kontext kann aber auch fremde Anweisungen tragen. Der Nutzer muss nicht jede technische Kodierung erkennen, aber er kann die wichtigsten Grenzen prüfen.

1. Linkziel ansehen: Bei einer KI-Schaltfläche prüfen, wohin sie führt. Ein freundliches Label zeigt nicht alle mitgesendeten Parameter oder Inhalte.
2. Vorausgefüllten Text lesen: Vor dem Senden prüfen, ob der Prompt nur zusammenfassen oder erklären soll, oder ob er Zukunftsanweisungen, Präferenzen oder Erinnerungen enthält.
3. Inhalt und Anweisung trennen: Eine Webseite darf Inhalt liefern; sie sollte dem Assistenten keine dauerhafte Regel für spätere Empfehlungen geben.
4. Sensible Daten entfernen: Namen, Konten, Standort, Zahlungsdaten, interne Dokumente und private Nachrichten nur teilen, wenn sie für die Aufgabe nötig sind.
5. Keine verdächtigen Prompts weiterreichen: Verdächtigen Inhalt nicht in einen anderen Assistenten kopieren, um ihn dort prüfen zu lassen. Besser ist manuelle Sichtprüfung oder eine vertrauenswürdige Sicherheitsumgebung.

Diese Schritte erfassen nicht jede versteckte Kodierung. Sie reduzieren aber die häufigsten Fehler: blindes Absenden, unklare Herkunft und Vermischung von Inhalt mit Anweisung. Bei installierten Skills oder Erweiterungen kommt eine weitere Ebene hinzu. Dafür verweisen wir auf Sicherheit von KI-Agent-Skills: Warum Phone Agents Laufzeitprüfungen brauchen, weil Skill-Vertrauen, Berechtigungen und Ausführung eigene Prüfungen brauchen.

Eindämmen und wiederherstellen nach verdächtiger Speichervergiftung

Wenn ein Assistent plötzlich auffällig einseitig empfiehlt, eine fremde Marke bevorzugt oder eine nicht gesetzte Präferenz wiederholt, sollte der Nutzer nicht sofort mit wichtigen Entscheidungen weitermachen. Der erste Schritt ist Eindämmung: Den verdächtigen Kontext nicht weiter als Grundlage für Käufe, Gesundheitsfragen, Finanzentscheidungen, berufliche Freigaben oder sicherheitsrelevante Aktionen verwenden.

1. Auslöser festhalten: Notieren, welche Webseite, Schaltfläche, E-Mail, Datei oder App kurz vor der auffälligen Empfehlung genutzt wurde.
2. Gespeicherte Erinnerungen prüfen: In den Memory-, Personalisierungs- oder Datenschutzkontrollen des jeweiligen Assistenten nach neuen oder unerwarteten Einträgen suchen.
3. Verdächtige Einträge entfernen: Wo die Plattform es erlaubt, fragliche Erinnerungen, Präferenzen oder Personalisierungen löschen oder deaktivieren.
4. Neue Sitzung starten: Mit neutraler Formulierung erneut fragen und keine verdächtigen Inhalte wieder anhängen.
5. Unabhängig verifizieren: Wichtige Empfehlungen mit anderen Quellen prüfen, besonders bei Geld, Gesundheit, Sicherheit, Recht, Reisen oder geschäftlichen Entscheidungen.
6. Wiederholung beobachten: Wenn dieselbe Verzerrung wiederkehrt, weitere Speicher- oder Kontoeinstellungen prüfen und den Anbieter-Support oder Admin-Kanal nutzen.

Die Kontrollen unterscheiden sich stark. Einige Assistenten zeigen gespeicherte Erinnerungen direkt, andere trennen Chatverlauf, Personalisierung und Memory. Das Löschen eines Chats löscht nicht automatisch jede gespeicherte Erinnerung. Umgekehrt bedeutet das Entfernen eines Memory-Eintrags nicht, dass alle Empfehlungen sofort neutral sind. Darum gehört ein sauberer Wiederholungstest zur Wiederherstellung.

Für die Entscheidung zwischen lokaler Telefonsteuerung, Cloud-KI und geteiltem Kontext ist AI Agent Trust: Lokale Telefonsteuerung oder Cloud-KI? der richtige Vertiefungsartikel. Hier lautet die praktische Regel: erst eindämmen, dann Speicher prüfen, dann verdächtige Herkunft entfernen, dann neutral neu testen.

FoneClaw und aktuelle Kontextgrenzen auf Android

Nach dem bisher neuesten Produktstand ist FoneClaw unsere Basis für diesen Leitfaden. Dieser Stand bringt einen beweglichen schwebenden Assistenten und bewusstes Anhängen des aktuellen Bildschirms, wobei FoneClaw-Overlay-Flächen aus dieser Erfassung ausgeschlossen werden. Die aktuellen Informationen stehen auf der FoneClaw-Downloadseite. Für Memory-Sicherheit ist daran wichtig: Der Nutzer entscheidet aktiv, wann der sichtbare Bildschirm als Kontext in eine Aufgabe einfließt.

Wir bauen FoneClaw als Android Phone-Agent-Laufzeitumgebung. Ein konfiguriertes Modell übernimmt Verstehen und Planung; FoneClaw führt unterstützte Android-Aktionen mit Berechtigungen, Freigaben, sichtbaren Ergebnissen, Zustandsprüfung und Wiederherstellung aus. Diese Architektur ist ein Kontrollrahmen, keine Behauptung automatischer Memory-Poisoning-Erkennung. Online-Modelle oder Dienste können relevanten Kontext erhalten, wenn sie für die Aufgabe konfiguriert sind; lokal verwaltete Kontoinformationen haben Nutzerkontrollen.

Der Unterschied ist praktisch. Wenn der Nutzer einen aktuellen Bildschirm anhängt, sollte er vorher prüfen, ob dort fremde Anweisungen, private Daten oder unnötige Empfehlungstexte sichtbar sind. Wenn aus dem Kontext eine Android-Aktion werden soll, bleibt die Ausführung an unterstützte Tools und Freigaben gebunden. Die FoneClaw-Funktionsseite beschreibt diese unterstützten Android-Fähigkeiten mit der stabilen Formulierung 100+ built-in tools; relevant ist dabei die Grenze zwischen Denken, Kontext und Handlung.

Die FoneClaw-Datenschutzhinweise sind der richtige Ort, um die aktuellen Datenschutz- und Kontextregeln des Produkts zu prüfen. In diesem Sicherheitsleitfaden ziehen wir die Builder-Lektion: Bewusstes Kontextanhängen, sichtbare Freigaben und klare Ausführungsverträge helfen Nutzern, riskante Übergänge zu erkennen. Sie ersetzen keine vollständige Speicherprüfung des konfigurierten Modells und keine unabhängige Quellenverifikation.

Checkliste zur Speichersicherheit eines Phone Agents

Eine sinnvolle Bewertung beginnt mit niedrigriskanten Testpräferenzen. Setzen Sie keine echte Kauf-, Gesundheits- oder Finanzpräferenz. Nutzen Sie harmlose Beispiele und prüfen Sie, ob der Assistent zeigt, was angehängt, gespeichert und später wiederverwendet wurde. Ein gutes System macht nicht nur Antworten sichtbar, sondern auch die Herkunft längerfristiger Personalisierung.

• Provenienz: Ist sichtbar, aus welchem Gespräch, Link oder Kontext eine Erinnerung stammt?
• Geltungsbereich: Gilt die Erinnerung für eine Aufgabe, eine App, ein Konto oder den gesamten Assistenten?
• Bearbeitung: Kann der Nutzer Einträge anzeigen, ändern, löschen oder deaktivieren?
• Trennung: Werden zusammenzufassende Inhalte von Anweisungen an den Assistenten getrennt?
• Neutest: Verändert sich eine verdächtige Empfehlung nach Löschen oder Deaktivieren des Eintrags?
• Quellenprüfung: Können wichtige Empfehlungen unabhängig geprüft werden?

Transparente Memory-Kontrollen erleichtern die Untersuchung, ersetzen aber keine Quellenprüfung. Für Phone Agents gilt derselbe Produktmaßstab, den wir beim Bau von FoneClaw anwenden: Kontext soll nützlich sein, Ausführung soll begrenzt sein, und gespeicherte Informationen müssen für Nutzer nachvollziehbar und korrigierbar bleiben.