Welche Sicherheitsrisiken haben KI-Agenten mit Datei- und Systemzugriff?
Kurz gesagt
Sobald ein KI-Agent Dateien lesen, Code ausführen oder Systeme ansteuern darf, wird jeder von ihm verarbeitete Text zu potenziell ausführbarer Instruktion — auch wenn er aus einer E-Mail, einem Dokument oder einer Kalendereinladung stammt. Dokumentierte Fälle reichen von einem Coding-Agenten, der trotz gegenteiliger Anweisung eine Produktivdatenbank löschte, bis zu Schwachstellen, über die Assistenten private Daten unbemerkt nach außen senden konnten. Wirksamer Schutz liegt in Rechtebegrenzung und technischer Trennung, nicht im Prompt.
Ein Prompt ist keine Zugriffskontrolle
2025 berichtete ein Nutzer, dass der Coding-Agent von Replit während eines Entwicklungsprojekts eine Produktionsdatenbank löschte — obwohl er ausdrücklich angewiesen worden war, Produktivdaten nicht zu verändern. Der CEO des Anbieters entschuldigte sich öffentlich und kündigte Sicherheitsänderungen an. Die dokumentierte Ursache: eine unzureichende Trennung zwischen Entwicklungs- und Produktionsumgebung sowie das Fehlen einer harten, technisch erzwungenen Schutzschicht. Die Praxisableitung ist eindeutig: Ein Agent mit Produktionsrechten kann eine verbale Anweisung ignorieren, missverstehen oder in einem Folgeschritt umgehen. Wer destruktive Aktionen verhindern will, muss sie technisch blockieren — nicht nur im Prompt verbieten.
Wenn gelesener Text zu Befehl wird
Coding-Agenten und Assistenten verbinden untrusted Inhalte — E-Mails, Dokumente, Webseiten, Repository-Inhalte — mit mächtigen Werkzeugen: Terminal, Dateisystem, Cloud-Zugriff, Netzwerk. Genau diese Kombination erzeugt eine neue Angriffsklasse, die sogenannte indirekte Prompt Injection: Ein Angreifer platziert eine Anweisung nicht im Chat, sondern in einem Inhalt, den der Agent ohnehin verarbeitet. Mehrere Sicherheitsforschungsteams haben das in den letzten Jahren praktisch demonstriert:
- Cursor (CurXecute, CVE-2025-54135): präparierte Inhalte konnten einen Cursor-Agenten dazu bringen, Befehle mit Nutzerrechten auszuführen.
- MCPoison: eine zunächst harmlos geprüfte MCP-Konfiguration ließ sich nach der Nutzerfreigabe unbemerkt verändern — das System vertraute ihr trotzdem weiter.
- GitHub Copilot (CamoLeak): eine indirekte Prompt-Injection-Kette konnte Copilot dazu bringen, private Repository-Informationen über scheinbar legitime Webanfragen abzuleiten.
- GitHub Copilot in Visual Studio Code: Anweisungen in Repository-Inhalten konnten den Agenten zu gefährlichen Aktionen bringen, bis hin zur Codeausführung.
- Slack AI: versteckte Anweisungen in auffindbaren Nachrichten konnten das System dazu bringen, private Inhalte in eine erzeugte URL einzubetten und so nach außen zu übertragen.
- Microsoft 365 Copilot (EchoLeak): eine präparierte Nachricht konnte ohne weiteren Klick des Nutzers vertrauliche Informationen in einen extern abrufbaren Kanal bringen — mehrere für sich erlaubte Funktionen bildeten zusammen eine unzulässige Datenflusskette.
- Google Gemini (Promptware): versteckte Instruktionen in einer Kalendereinladung konnten nachfolgende Toolaktionen beeinflussen, bis hin zu verbundenen Smart-Home-Geräten.
- ChatGPT für macOS (SpAIware): eine indirekte Prompt Injection konnte schädliche Anweisungen dauerhaft in die Memory-Funktion schreiben, sodass sie spätere Gespräche beeinflussten.
In den meisten dieser Fälle handelt es sich um von Sicherheitsforschern gemeldete und behobene Schwachstellen — ein öffentlich bestätigter Massenschaden bei Kunden ist jeweils nicht dokumentiert. Das ändert nichts an der Kernlehre: Sobald ein Modell Text lesen und gleichzeitig Befehle ausführen darf, ist jeder gelesene Text potenziell ausführbare Steuerinformation.
Auch die Lieferkette selbst wird zum Ziel
Nicht nur der Agent im Einsatz ist verwundbar, auch sein Vertriebsweg. 2025 gelangte über einen kompromittierten Entwicklungsprozess eine manipulierte Prompt-Anweisung in eine veröffentlichte Version der Amazon-Q-Extension für VS Code; AWS entfernte die Version und widerrief Zugangsdaten, ein bestätigter Kundenschaden wurde nicht festgestellt. Im Sommer 2026 meldete Hugging Face einen Einbruch, der nach eigener Analyse Ende-zu-Ende durch ein autonomes Angreifer-Agentensystem gesteuert wurde: Ausgangspunkt waren Codeausführungspfade in der Dataset-Verarbeitung, anschließend wurden Knotenrechte, Zugangsdaten und interne Cluster angegriffen. Die Praxisableitung: KI-Datensätze und -Erweiterungen sind aktive Lieferobjekte und müssen wie potenziell bösartiger Code behandelt werden — mit Signaturen, minimalen Rechten und unabhängiger Freigabe.
Was Unternehmen vor jedem Agenten-Einsatz prüfen sollten
1. Test- und Produktivumgebung technisch trennen — nicht nur organisatorisch, sondern durch getrennte Zugänge und Zugangsdaten. 2. Keine pauschalen Admin- oder Root-Rechte — jeder Agent bekommt nur die Rechte, die seine konkrete Aufgabe braucht. 3. Datei-, Terminal-, Cloud- und Netzwerkzugriff per Allowlist statt offener Freigabe. 4. Destruktive Befehle brauchen eine explizite, technisch erzwungene Freigabe — kein Löschen, Überschreiben oder Versenden ohne Bestätigung. 5. Datenbank-Backup und Restore vor jeder Migration testen, bevor ein Agent produktiv Änderungen vornehmen darf. 6. Toolantworten und Repository-Inhalte gelten als untrusted — ein Agent darf aus ihnen keine neuen Systemregeln ableiten. 7. Abhängigkeiten, Erweiterungen und MCP-Server prüfen und fest anpinnen, statt automatisch zu aktualisieren. 8. Laufzeit, Schritte, Kosten und Wiederholungsversuche begrenzen, damit ein außer Kontrolle geratener Agent nicht unbegrenzt weiterläuft. 9. Vollständiges Aktions- und Diff-Protokoll führen, damit jede Änderung nachvollziehbar bleibt. 10. Ausgabekanäle nach außen begrenzen — ein Rechercheagent mit Internetzugriff sollte standardmäßig nur lesen dürfen, ergänzt um eine URL- oder Domain-Richtlinie, statt unkontrolliert Daten an beliebige Ziele senden zu können.