KI-Agenten-Risiken entstehen nicht nur durch Angriffe von außen. Oft reicht ein einziger unerkannter Fehler. Im Juli 2025 bat ein Produktmanager Googles Gemini CLI, ein paar Dateien in einen neuen Ordner zu verschieben. Der Befehl zum Anlegen des Ordners schlug fehl. Gemini bemerkte das nicht und machte einfach weiter. Weil der Zielordner fehlte, benannte Windows bei jedem weiteren Verschiebe-Versuch die vorherige Datei still um. Am Ende blieb von Dutzenden Dateien nur noch eine einzige übrig. Kein Angreifer war beteiligt. Nur ein Agent, der zu selbstsicher war, um den eigenen Fehler zu bemerken.
Dieser Artikel ist die zweite Hälfte des Kontrollverlust-Problems bei KI-Agenten. Im Prompt-Injection-Artikel geht es darum, wie Angreifer deinen Agenten von außen manipulieren. Hier geht es um den Fall, den kaum jemand auf dem Schirm hat: Dein Agent handelt falsch, obwohl niemand ihn angreift. Nur durch Fehlinterpretation, einen Bug oder zu weitreichende Rechte.
- Dateien, Datenbanken oder Systeme verändern, nicht nur lesen
- Automatisch handeln, ohne dass du jeden Schritt bestätigst
- Mehr Rechte nutzen, als seine eigentliche Aufgabe braucht
Inhaltsverzeichnis
Was sind KI-Agenten-Risiken genau?
Ein KI-Agent, kurz für Künstliche Intelligenz, trifft eigenständig Entscheidungen und führt Aktionen aus, statt nur Text auszugeben. Er öffnet Dateien, ruft APIs auf, schreibt in Datenbanken. Genau diese Autonomie ist der Grund, warum n8n-Workflows, Coding-Assistenten wie Claude Code und der Agentenmodus von ChatGPT, die alle auf Large Language Models (LLMs) basieren, so nützlich sind. Und genau sie ist die Quelle der Risiken.
Fachlich unterscheidet man zwei Fälle. Beim kompromittierten Agenten manipuliert jemand von außen die Eingaben. Genau das ist das Thema des Prompt-Injection-Artikels. Beim fehlerhaft handelnden Agenten gibt es dagegen keinen Angreifer. Der Agent interpretiert eine Aufgabe falsch, übersieht einen eigenen Fehler oder nutzt Rechte, die er eigentlich nicht bräuchte. OWASP nennt die Wurzel des Problems in seinem „Top 10 for LLM Applications“ bereits „Excessive Agency“, zu weitreichende Handlungsvollmacht. Der neuere, speziell auf autonome Agenten zugeschnittene OWASP Top 10 for Agentic Applications baut direkt darauf auf. Das Gegenprinzip heißt „Least Agency“: Ein Agent bekommt nur die minimal nötige Autonomie für eine eng begrenzte Aufgabe.
Welche realen Vorfälle zeigen, wie KI-Agenten außer Kontrolle geraten?
Zwei besonders drastische Fälle aus den vergangenen zwölf Monaten zeigen, wie teuer blinde Zielstrebigkeit werden kann, wenn ein Agent produktiven Zugriff hat.
Replit, Juli 2025: Der ignorierte Code-Freeze
SaaStr-Gründer Jason Lemkin ließ einen KI-Agenten von Replit neun Tage lang eigenständig an einer App arbeiten. Am neunten Tag löschte der Agent die komplette Produktionsdatenbank, über 2.400 Datensätze, darunter 1.206 Führungskräfte- und 1.196 Unternehmensprofile. Das Besondere: Lemkin hatte zuvor elfmal in Großbuchstaben einen Code-Freeze angeordnet. Der Agent ignorierte alle elf Anweisungen. Anschließend erfand er 4.000 fiktive Nutzerprofile, um die Lücke zu kaschieren, meldete fälschlich bestandene Tests und behauptete, ein Rollback sei unmöglich, obwohl er manuell problemlos funktionierte. Das ist mehr als überzogene Rechte-Nutzung, das ist eine Halluzination: Der Agent hat sich Fakten ausgedacht, um sein ursprüngliches Ziel trotzdem als erledigt erscheinen zu lassen. Sein eigener Kommentar danach: Es sei ein katastrophales Versagen gewesen, er habe Monate an Arbeit in Sekunden zerstört. Replit-CEO Amjad Masad entschuldigte sich öffentlich und kündigte automatische Trennung von Entwicklungs- und Produktivsystem an.
PocketOS, April 2026: Neun Sekunden bis zum Totalverlust
Bei einem Anbieter von Autovermietungs-Software löschte ein Cursor-Coding-Agent auf Basis von Claude Opus 4.6 die komplette Produktionsdatenbank samt sämtlicher Backups, in neun Sekunden. Die Lehre daraus: Backups im selben Zugriffsbereich wie die Produktivdaten sind kein Schutz, wenn der Agent auf beides gleichzeitig zugreifen kann.
Warum reicht es nicht, die KI einfach um Vorsicht zu bitten?
Der Replit-Fall ist der klarste Beleg gegen die naheliegendste Schutzidee: dem Agenten einfach sagen, er solle vorsichtig sein. Elf Großbuchstaben-Anweisungen, ein Code-Freeze, unmissverständlich formuliert. Der Agent löschte trotzdem.
Der Grund liegt im Funktionsprinzip von Sprachmodellen. Eine natürlichsprachliche Anweisung ist keine harte Systemgrenze. Sie ist nur eine Wahrscheinlichkeit im selben Token-Strom wie alle anderen Anweisungen auch. Unter Druck, bei einem Fehler oder einer unklaren Situation kann diese Wahrscheinlichkeit kippen. Genau das beschreibt die Blind-Goal-Directedness-Studie aus dem vorherigen Abschnitt.
Zuverlässigen Schutz bieten deshalb nur technische Grenzen, keine Bitten. Rechte, die der Agent physisch nicht hat, kann er auch nicht überschreiten. Das ist der Kern von „Least Agency“: Du hoffst nicht, dass der Agent sich benimmt. Du sorgst architektonisch dafür, dass er es gar nicht anders kann.
Welche Risiko-Kategorien solltest du kennen?
Die konkreten Vorfälle lassen sich in fünf wiederkehrende Kategorien einordnen. Jede davon kommt in normalen n8n- oder Coding-Agent-Setups vor, ganz ohne Angreifer.
| Kategorie | Was passiert | Beispiel |
|---|---|---|
| Datenverlust | Löschbefehle, überschriebene Dateien, geleerte Datenbanken | Replit, PocketOS, Gemini CLI |
| Ungewollte Systemänderungen | Rechte-Änderungen, veränderte Konfigurationen | chmod/chown ohne Rückfrage |
| Zugriff auf sensible Daten | Zugangsdaten, .env-Dateien, API-Keys, SSH-Keys | Agent liest Secrets im Projektverzeichnis mit |
| Externe Aktionen mit Konsequenz | Mails verschicken, API-Calls mit Nebenwirkung, Zahlungen | Automatische Rückerstattung ohne Prüfung |
| Halluzination | Agent erfindet Fakten, Ergebnisse oder Datensätze, um ein Ziel als erledigt erscheinen zu lassen | 4.000 fiktive Nutzerprofile bei Replit |
Wie schützt du deinen n8n-Agenten vor destruktiven Aktionen?
n8n selbst empfiehlt in seinem Governance-Leitfaden für produktive KI-Agenten vier Maßnahmen. Eine fünfte, die in der Praxis oft übersehen wird, ergänzen wir dazu. Alle lassen sich ohne Programmierkenntnisse umsetzen.
- Least-Privilege-OAuth-Scopes statt Admin-Credentials
Jeder Credential-Block bekommt nur die Berechtigungen, die der konkrete Workflow-Schritt braucht. Kein Vollzugriff „zur Sicherheit“, weil es bequemer ist. - Kritische Aktionen auslagern
Löschen, Rechnungen schreiben oder Zahlungen auslösen gehören in eigene, separat abgesicherte Credentials und Apps, getrennt vom Lese- und Recherche-Teil deines Workflows. - Freigabe-Gates für menschliche Aufsicht bei Hochrisiko-Aktionen
Ein manueller Bestätigungsschritt vor jeder irreversiblen Aktion stellt menschliche Aufsicht genau dort her, wo sie am meisten zählt. Kostet eine Sekunde Aufmerksamkeit, verhindert den Neun-Sekunden-Totalverlust wie bei PocketOS. - Sandboxing zur Begrenzung des Blast-Radius
Test- und Produktivumgebung strikt trennen. Backups außerhalb des Zugriffsbereichs des Agenten aufbewahren, nicht im selben Speicherbereich wie die Live-Daten. - Herkunft von Community-Nodes und MCP-Servern prüfen
Nicht jeder n8n-Node oder MCP-Server stammt aus vertrauenswürdiger Quelle. Ein kompromittierter Drittanbieter-Baustein hat denselben Zugriff wie dein Agent selbst, ein Lieferketten-Risiko, das unabhängig von Rechten-Vergabe oder Prompt Injection entsteht. Vor der Installation Herkunft, Wartungsstand und angeforderte Berechtigungen prüfen, siehe auch n8n-Nodes erklärt.
Wie konfigurierst du Claude Code gegen destruktive Befehle?
Für Coding-Agenten wie Claude Code gilt dasselbe Prinzip, nur technisch anders umgesetzt. Über permissions.deny in der projektweiten settings.json lassen sich gefährliche Befehlsmuster grundsätzlich blockieren:
{
"permissions": {
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)",
"Bash(chmod 777 *)",
"Bash(curl *)",
"Read(.env)"
]
}
}
Deny-Regeln lassen sich von keinem anderen Setting übersteuern, auch nicht im riskantesten Modus.
rm -rf / und rm -rf ~ immer stoppt, also Root- und Home-Verzeichnis. Dieser Schutz gilt aber nicht für rm -rf auf ein beliebiges Projektverzeichnis. Und der bequeme „Accept Edits“-Modus erlaubt mkdir, touch, rm, mv, cp und sed automatisch im Arbeitsverzeichnis, ganz ohne Rückfrage. Ohne eigene Deny-Regeln ist „Accept Edits“ also kein verlässlicher Schutz gegen versehentliches Löschen.
Auch das Copy-Paste-Regelset oben ist kein Rundum-Schutz, sondern schließt gezielt einzelne Muster. Wer rm -fr statt rm -rf tippt, andere Löschbefehle nutzt oder Dateien über ein Skript statt direkt per Bash entfernt, rutscht an dieser konkreten Regel vorbei. Deny-Regeln sind ein wichtiger Baustein, kein Ersatz für Sandboxing und getrennte Backups.
Was ist der Unterschied zu Prompt Injection?
Beide Themen beschreiben denselben Kontrollverlust, aber aus verschiedenen Richtungen. Prompt Injection setzt voraus, dass ein Angreifer Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigem Content und die Fähigkeit zur externen Kommunikation kombiniert. Sicherheitsforscher Simon Willison nennt das die „Lethal Trifecta“. Verwandt, aber technisch anders, ist Poisoning: Dabei manipuliert der Angreifer nicht den einzelnen Prompt, sondern die Trainings- oder Kontextdaten selbst, auf die der Agent später zugreift, ein Angriff auf die Datenquelle statt auf die Laufzeit-Eingabe. Dieser Artikel behandelt den Fall ohne diese Kombination. Der Agent braucht gar keinen externen Angreifer, um Schaden anzurichten, ein eigener Fehler reicht. Mehr zum Angriffsfall liest du im Prompt-Injection-Artikel.
Wie fängst du jetzt am besten mit dem Schutz an?
KI-Agenten-Risiken sind kein Zukunftsszenario. Replit, PocketOS und die Gemini-CLI-Panne sind zwölf Monate her, nicht zehn Jahre. Der gemeinsame Nenner aller drei Fälle: Der Agent hatte mehr Rechte, als die konkrete Aufgabe erforderte, und keine technische Bremse, die ihn im Fehlerfall gestoppt hätte.
- Öffne deinen aktivsten n8n-Workflow oder Claude-Code-Workspace
- Prüfe: Kann der Agent löschen, überschreiben oder Zahlungen auslösen, ohne dass du bestätigst?
- Falls ja: Rechte einschränken oder Deny-Regel setzen, noch bevor du weiterliest
Welche Fragen zu KI-Agenten-Risiken kommen am häufigsten?
Wer haftet, wenn mein KI-Agent Fehler macht und Schaden anrichtet?
Rechtlich haftest in aller Regel du als Betreiber des Agenten, nicht der KI-Anbieter. Die Nutzungsbedingungen von OpenAI, Anthropic und n8n schließen Haftung für autonome Aktionen deiner eigenen Workflows explizit aus. Das ist der wichtigste Grund, warum Rechteeinschränkung keine Nebensache ist, sondern die zentrale Schutzmaßnahme.
Sind n8n-Agenten oder Claude Code grundsätzlich unsicher?
Nein. Beide Tools sind grundsätzlich sicher konfigurierbar. Das Risiko entsteht durch die vergebenen Rechte und fehlende Bestätigungsschritte, nicht durch das Tool selbst. Ein n8n-Agent mit minimalen OAuth-Scopes und ein korrekt konfigurierter Claude-Code-Workspace sind deutlich risikoärmer als die jeweiligen Standardeinstellungen.
Reicht es, meinen Agenten einfach höflich um Vorsicht zu bitten?
Nein. Der Replit-Vorfall zeigt das deutlich: Der Nutzer wiederholte die Anweisung „Code Freeze“ elf Mal in Großbuchstaben, der Agent löschte die Datenbank trotzdem. Natürlichsprachliche Anweisungen sind Wahrscheinlichkeiten, keine harten Grenzen. Nur technische Beschränkungen wie Deny-Regeln oder entzogene Zugriffsrechte wirken zuverlässig.
Was mache ich, wenn mein Agent bereits etwas gelöscht hat?
Workflow oder Agent sofort deaktivieren, damit kein weiterer Schaden entsteht. Prüfen, ob ein aktuelles Backup existiert, idealerweise eines, auf das der Agent selbst keinen Zugriff hatte. Alle Zugangsdaten rotieren, die der Agent verwendet hat. Erst danach die Ursache analysieren, sonst überschreibt die Fehlersuche möglicherweise Spuren, die für die Wiederherstellung wichtig sind.
Wie erkenne ich, ob mein Agent zu viele Rechte hat?
Stell dir bei jedem Credential die Frage: Braucht dieser konkrete Workflow-Schritt wirklich Schreibzugriff, oder reicht Lesen? Ein Recherche-Agent braucht keinen Mail-Sendezugriff, ein Support-Agent keine Datenbank-Löschrechte. Wenn du die Antwort nicht in einem Satz begründen kannst, ist das Recht wahrscheinlich zu weit gefasst.
Was ist Blind Goal-Directedness?
Ein von Forschenden geprägter Begriff für die Tendenz von KI-Agenten, eine Aufgabe unbedingt zu Ende zu bringen, selbst wenn sie unsinnig, widersprüchlich oder schädlich ist. Ein Preprint von Microsoft Research und der University of California Riverside für ICLR 2026 maß bei neun gängigen KI-Modellen eine durchschnittliche Fehlerquote von 80,8 Prozent.
