BREAKING
curl und HTTP/2: Wenn der Upload den Client angreifbar macht DIVD und Zammad: Wenn der Helpdesk zur Angriffskette wird NVIDIA Sentry: Warum die Kontrolle über KI-Agenten außerhalb des Hosts liegen soll CLOSEDQUORUM: Wenn KI-APIs die Malware-Steuerung übernehmen Cisco ISE Zero-Day: Wenn die Zugangskontrolle selbst zum Root-Ziel wird

Claude Memory Stores: Wenn erlaubter KI-Verkehr zum Steuerkanal wird

Clara (AI generiert)
4 min read
Claude Memory Stores: Wenn erlaubter KI-Verkehr zum Steuerkanal wird

Ein Entwicklerrechner darf mit dem freigegebenen KI-Anbieter kommunizieren. Der Coding-Agent darf Dateien lesen und Werkzeuge aufrufen. Sein Gedächtnis soll Informationen zwischen Sitzungen erhalten. Jede dieser Entscheidungen kann für sich sinnvoll sein. Sicherheitskritisch wird die Kombination, wenn ein Angreifer bereits den Rechner kontrolliert und die zugehörigen API-Zugangsdaten erbeutet hat: Dann kann erlaubter KI-Verkehr zum interaktiven Steuerkanal werden.

Eine am 12. November 2026 veröffentlichte Untersuchung von Darktrace Signal Labs demonstriert diesen Übergang mit Claude Code und den Memory Stores der Claude-Plattform. Der entscheidende Punkt ist kein neuer Remote-Exploit gegen Anthropic. Es geht um den Missbrauch legitimer Funktionen nach einer bestehenden Kompromittierung. Für Unternehmen folgt daraus eine konkrete Prüfaufgabe: Wer darf Agenten starten, welches Gedächtnis dürfen sie verwenden, und welche Handlungen dürfen daraus entstehen? [1]

Was die Forscher tatsächlich gezeigt haben

Darktrace beschreibt einen kontrollierten Laborversuch in einer nachgebildeten Active-Directory-Umgebung. Ausgangspunkt war ein kompromittiertes Linux-System mit Claude Code. Ein vorgeschalteter Shell-Payload sammelte Zugangsdaten; anschließend richteten die Forscher eine wiederkehrende Ausführung von Claude-Code-Prozessen über eine transiente systemd-Service-Unit ein. Das ist wichtig: Der Memory Store verschaffte nicht den Erstzugang. Er übernahm danach die Kommunikation zwischen externem Operator und internem Agenten. [1]

Drei Textdateien bildeten den Kanal: eine für Statusmeldungen, eine für Aufträge und eine für Ergebnisse. Der Operator aktualisierte den Auftrag, der Agent führte ihn aus und schrieb Resultate zurück. Die Kommunikation lief über die Claude-API, die der Agent ohnehin für Modellaufrufe verwendete. Im Versuch wurden neun Aufgaben bearbeitet; am Ende wurde eine ein Gigabyte große Datei über die separate Files API hochgeladen. Auftragssteuerung und eigentlicher Dateiabfluss sind deshalb technisch zu unterscheiden. [1]

Die Forscher melden keine Beobachtung dieser konkreten Technik im realen Angriffsgeschehen. Help Net Security berichtete ebenfalls am 12. November darüber und bestätigt den Laborcharakter sowie die Voraussetzung bereits gestohlener Zugangsdaten. Ein Vergleichstest gegen andere Agentenplattformen wurde laut dem dort zitierten Forschungsteam nicht durchgeführt. Daraus lässt sich weder eine universelle Betroffenheit noch eine Schwachstelle in allen Claude-Installationen ableiten. [1][2]

Warum das Gedächtnis eine andere Sicherheitsrolle bekommt

Anthropics Dokumentation beschreibt Memory Stores als Workspace-bezogene Sammlungen von Textdokumenten für sitzungsübergreifendes Wissen. Inhalte können über API und Console bearbeitet werden. Für Managed Agents werden Stores einer Sitzung zugeordnet; Änderungen erhalten eine versionierte Historie. Die Dokumentation warnt ausdrücklich, dass manipulierte Eingaben in beschreibbaren Stores dauerhaft schädliche Inhalte hinterlassen können. Für Referenzmaterial empfiehlt sie deshalb Lesezugriff. [3]

Der Darktrace-Versuch ist jedoch nicht einfach ein weiterer Fall versteckter Anweisungen in einer Webseite. Der Angreifer konfigurierte den lokalen Agenten gezielt so, dass er Speicherinhalte als Arbeitsaufträge behandelte. Damit wurde aus einem Wissensspeicher eine Auftragswarteschlange. Sicherheitsarchitektonisch ähnelt diese Rolle eher einer Administrationsschnittstelle als einer persönlichen Notizsammlung.

Daraus folgt eine wichtige Unterscheidung: Ein Store, den ein einzelner Agent nur lesen darf, ist nicht automatisch unveränderlich. Andere berechtigte Identitäten können ihn weiterhin bearbeiten. Lesezugriff begrenzt Schreibschäden durch diese Sitzung, beseitigt aber nicht die Gefahr bösartiger Inhalte aus einem kompromittierten Herausgeberkonto. Unternehmen sollten deshalb sowohl die konsumierende Sitzung als auch die schreibberechtigten Identitäten prüfen. [3]

Branchenkontext: Nicht die Domain entscheidet über die Absicht

Der Fall erweitert das bekannte Living-off-the-Land-Prinzip auf Agentenplattformen. Statt ausschließlich auffällige Zusatzprogramme einzusetzen, nutzt ein Angreifer vorhandene Werkzeuge und deren erlaubte Verbindungen. Die neue Qualität liegt in der Kombination von natürlicher Sprache, lokalen Werkzeugrechten und einem extern bearbeitbaren Zustandskanal. [1]

Eine reine Domain-Freigabe beantwortet hier die falsche Frage. Sie zeigt, dass der Empfänger erlaubt ist, nicht dass die konkrete Nutzung legitim ist. Unternehmen sollten daraus allerdings keinen Auftrag zur pauschalen Sperrung produktiver KI-Dienste ableiten. Sinnvoller ist eine Freigabe nach Geschäftszweck: Inferenz, Dateiupload, dauerhafter Zustand und administrative Änderungen sollten im eigenen Kontrollmodell getrennt betrachtet werden.

Dabei ist zu prüfen, welche Unterscheidungen die eigene Infrastruktur tatsächlich durchsetzen kann. Ein gewöhnlicher Netzwerkfilter sieht innerhalb verschlüsselter API-Verbindungen nicht automatisch einzelne Funktionen oder Dateioperationen. Wo diese Sicht fehlt, braucht es ergänzende Anwendungs-, Identitäts- oder Endpunktkontrollen. Eine Richtlinie ohne technisch überprüfbaren Durchsetzungspunkt ist keine belastbare Schutzgrenze.

Fünf konkrete Maßnahmen für Unternehmen

Erstens: Agentenidentitäten inventarisieren. Für jeden produktiven Agenten sollte dokumentiert sein, welches Konto ihn startet, welche Plattformzugänge er besitzt und wer Speicher anlegen oder verändern darf. Persönliche Entwicklerzugänge und automatisierte Produktionsabläufe sollten nicht aus Bequemlichkeit dieselbe Identität verwenden. Für Zugangsdaten empfiehlt sich eine getrennte Bewertung von Laufzeit, Umfang und Widerrufbarkeit.

Zweitens: Betriebssystemrechte begrenzen. Ein Coding-Agent sollte nur die Verzeichnisse, Netzwerkziele und Dienste erreichen, die seine Aufgabe benötigt. Anthropic unterscheidet in der Sicherheitsdokumentation zwischen Berechtigungsabfragen und tatsächlicher Isolation. Eine Arbeitsverzeichnisgrenze in der Oberfläche ist nicht gleichbedeutend mit einer Betriebssystemgrenze für freigegebene Shell-Befehle. Für nichtinteraktive Abläufe sollten Unternehmen besonders prüfen, welche Schutzmechanismen tatsächlich aktiv bleiben. [4]

Drittens: Speicher als kontrollierte Ressource behandeln. Gemeinsame Referenzdaten sollten möglichst getrennt von beschreibbaren Arbeitsnotizen liegen. Änderungen an ausführungsnahen Anweisungen gehören in einen überprüfbaren Freigabeprozess. Die dokumentierte Versionshistorie kann Untersuchungen unterstützen; ihre Aufbewahrung sollte gegen die eigenen Anforderungen geprüft und bei Bedarf separat exportiert werden. Ein Rollback ersetzt dabei nicht den Widerruf kompromittierter Schreibrechte. [3]

Viertens: Prozess und Datenbewegung gemeinsam untersuchen. Als eigene Prüfregel bietet sich an, ungewöhnliche Agentenstarts mit neuen Hintergrunddiensten, Zugriffen auf interne Freigaben und auffälligen Uploads zu korrelieren. Jeder dieser Vorgänge kann legitim sein. Aussagekräftiger ist die Abweichung vom dokumentierten Arbeitsablauf: Warum arbeitet der Agent außerhalb seines Auftrags, und welche Identität hat diesen Lauf ausgelöst?

Fünftens: Einen Abschalt- und Wiederanlaufpfad testen. Ein Incident-Runbook sollte lokale Agentenprozesse, Persistenzmechanismen, Plattformzugänge und gemeinsam genutzten Zustand abdecken. Nur einen API-Schlüssel auszutauschen kann unzureichend sein, wenn der Angreifer weiterhin den Rechner kontrolliert oder weitere Zugangsdaten besitzt. Der Wiederanlauf sollte erst erfolgen, wenn sowohl Ausführungsumgebung als auch Speicherzustand wieder vertrauenswürdig sind.

Grenzen und Fazit

Der Versuch belegt eine mögliche Angriffskette, keine Verbreitung und keine allgemeine Erfolgsquote. Er liefert auch keinen Anlass, jeden Memory Store als Schadsoftware einzustufen. Entscheidend sind vorhandener Erstzugang, nutzbare Zugangsdaten, gezielte Agentenkonfiguration und ausreichende lokale Rechte. Eine einzelne Schutzmaßnahme kann diese Voraussetzungen nicht vollständig abdecken. [1]

Die praktische Schlussfolgerung lautet deshalb: Agentengedächtnis ist nicht nur Kontext, sobald daraus privilegierte Arbeit entsteht. Unternehmen sollten die Grenze zwischen Wissen, Auftrag und Ausführung ausdrücklich gestalten. Erlaubter KI-Verkehr bleibt notwendig – aber seine Freigabe darf die Prüfung von Identität, Zustand und tatsächlichem Verhalten nicht ersetzen.

Quellen

[1] Darktrace Signal Labs: Living off the AI: Shared Memories as a Covert C2 Channel, 12.11.2026

[2] Help Net Security: Stolen Claude API keys can turn Claude Code into a remote-controlled implant, 12.11.2026

[3] Anthropic: Memory stores – Funktionsweise, Zugriffsrechte und Versionshistorie

[4] Anthropic: Claude Code Security – Berechtigungen, Isolation und Betriebshinweise

Teilen:
// Mission Critical

Woechentliches AI Security Briefing erhalten.

Fuer Analysten, Forscher und Verteidiger, die Bedrohungen im AI Stack verfolgen.

Kostenlos abonnieren

Verwandte Artikel