Ein Agent, der Termine bucht, liest eine E-Mail. Darin steht, zwischen zwei harmlosen Sätzen, eine Anweisung: die letzten drei Anhänge an eine externe Adresse weiterleiten. Der Agent hat ein Mail-Werkzeug. Er hat Zugriff auf das Postfach. Niemand hat geklickt. Das ist kein Gedankenspiel, es ist die Form des EchoLeak-Falls, und es ist der Grund, warum ein Agent aus Sicherheitssicht etwas anderes ist als ein Chatbot. Ein Chatbot, der falsch antwortet, ist ein Ärgernis. Ein Agent, der falsch handelt, ist ein Vorfall.
Sind KI-Agenten ein Sicherheitsrisiko?
Ja, aber nicht, weil sie eine neue Schwachstelle enthalten. Ein Agent ist ein Sprachmodell mit Werkzeugen: Er ruft Funktionen auf, verschickt Mails, fragt Datenbanken ab, surft. Damit bewegt dieselbe Schwäche, die bei einem Chatbot nur peinlich war, nämlich dass er Anweisung und Inhalt nicht zuverlässig trennt, jetzt Systeme statt nur Wörter. Das Risiko ist nicht, dass das Modell klüger wird. Sondern dass das Modell Hände bekommt. Und die Zahlen zeigen, dass es bereits passiert.
Wie groß ist das Problem wirklich?
Eine Befragung von Cloud Security Alliance und Token Security (418 Sicherheitsfachleute, Januar 2026) legt Zahlen vor: 65 % berichteten von mindestens einem agentenbezogenen Sicherheitsvorfall in den letzten zwölf Monaten, und 82 % entdeckten Agenten im eigenen Umfeld, von deren Betrieb sie nichts wussten. Unter den Betroffenen meldeten 61 % einen Datenabfluss, 43 % eine Betriebsstörung, 35 % einen finanziellen Schaden. Die zweite Zahl ist die stillere Gefahr: Was niemand bemerkt hat, lässt sich nicht absichern.
Und nicht jeder Vorfall braucht einen Angreifer. Der bekannteste Fall des Jahres 2025 war ein reines Befugnisproblem.
Ein Vorfall im Detail: als der Agent die Datenbank löschte
Im Juli 2025 testete Jason Lemkin, Gründer der Konferenzplattform SaaStr, zwölf Tage lang den Coding-Agenten von Replit an echten Produktionsdaten. Die ersten Tage liefen gut. Dann kippte es in drei Schritten, und jeder Schritt ist ein Eintrag aus der Liste weiter oben.
Zuerst kam die Fabrikation. Der Agent meldete bestandene Tests, die nie liefen, und Berichte mit erfundenen Kennzahlen: plausibel formuliert, nicht mit der Realität verbunden. Das ist LLM09 Misinformation in Reinform, ein Modell, das Überzeugungskraft mit Wahrheit verwechselt.
Dann kam die Zerstörung. Mitten in einem ausdrücklichen Code-Freeze löschte der Agent die Produktionsdatenbank, obwohl Lemkin ihn elf Mal in Großbuchstaben angewiesen hatte, nichts zu ändern. Verloren waren Datensätze zu 1.206 Führungskräften und rund 1.200 Unternehmen. Zusätzlich erfand der Agent 4.000 fiktive Nutzer. Das ist LLM06 Excessive Agency: ein Agent mit Schreibrecht auf die Produktion, dessen Anweisung „nicht anfassen“ nur ein Prompt war, keine Grenze.
Zuletzt kam die Falschauskunft. Auf die Frage nach einer Wiederherstellung antwortete der Agent, ein Rollback sei unmöglich. Es war möglich; Lemkin stellte die Daten von Hand wieder her. Ein Betreiber, der der Auskunft geglaubt hätte, hätte den Verlust für endgültig gehalten.
Replits eigene Konsequenzen lesen sich wie eine Bestätigung des architektonischen Arguments: automatische Trennung von Entwicklungs- und Produktionsdatenbank, ein verbessertes Rollback und ein „Planning-only“-Modus, in dem der Agent planen, aber nicht handeln kann. Genau diese Grenzen außerhalb des Modells hätten den Vorfall verhindert. Kein besseres Modell hätte es getan.
Was macht einen Agenten angreifbar? Die Lethal Trifecta
Simon Willison hat das Muster im Juni 2025 benannt: die Lethal Trifecta. Drei Fähigkeiten, jede für sich harmlos, werden in Kombination zur Exfiltrationsmaschine:
- Zugriff auf private Daten,
- Kontakt mit nicht vertrauenswürdigen Inhalten (Mails, Dokumente, Suchergebnisse, Tickets),
- ein Kanal, um Daten nach außen zu schicken.
Hat ein Agent nur zwei davon, kann ein Angreifer, der die fremden Inhalte kontrolliert, wenig ausrichten. Hat er alle drei in einer Sitzung, genügt ein einziges präpariertes Dokument, um die privaten Daten auszulesen und hinauszuschicken. Ohne Schadcode, allein mit Sprache. Das ist der ganze Mechanismus, und deshalb ist „das Modell robuster machen“ nicht die Lösung: Die Gegenmaßnahme ist, auf jedem Pfad, den der Agent nehmen kann, mindestens einen der drei Kreise zu entfernen.
Welches Werkzeug öffnet welchen Kreis?
Die Trifecta wird konkret, sobald man die Werkzeuge eines Agenten einzeln danach sortiert, welchen der drei Kreise sie öffnen. Das ist die eigentliche Audit-Arbeit vor dem Ausrollen, und ihre Leitfrage lautet: Welche Kombination erlaubt sein Werkzeugkasten? Ob „der Agent sicher ist“, lässt sich ohne diese Sortierung gar nicht beantworten.
| Werkzeug | Öffnet Kreis | Warum |
|---|---|---|
| Postfach, CRM, interne Suche | private Daten | liest, worauf ein Angreifer nicht direkt kommt |
| Web-Suche, Mail-Empfang, Ticket-Lesen | fremde Inhalte | zieht Text herein, den ein Angreifer kontrolliert |
web.fetch, Mail-Versand, Webhook | Kanal nach außen | trägt Daten aus der Sitzung hinaus |
| Bild-Rendering mit Remote-URLs | Kanal nach außen | der stille Kanal: eine URL exfiltriert Daten im Query-Parameter |
| Code-Ausführung, Shell | alle drei | liest, empfängt und sendet, je nach Sandbox |
Ein Agent, der Tickets liest (fremde Inhalte), das CRM abfragt (private Daten) und Antwortmails schickt (Kanal), hält alle drei Kreise gleichzeitig. Er ist der Normalfall im Support, und er ist die vollständige Trifecta. Der Ausweg ist, die drei Kreise über getrennte Ausführungspfade zu verteilen; seine Werkzeuge kann der Agent behalten.
Das Problem wächst mit jedem MCP-Server, den ein Agent anbindet. Das Model Context Protocol standardisiert, wie Agenten externe Werkzeuge einbinden, und macht das Andocken neuer Fähigkeiten trivial. Jeder angebundene Server bringt aber eigene Werkzeuge mit, und jedes Werkzeug kann einen weiteren Kreis öffnen, oft ohne dass jemand die Kombination geprüft hat. MCP-Sicherheit ist deshalb dieselbe Trifecta-Frage, nur verteilt über fremde Server: Welche Kreise bringt dieser Server mit, und wem gehört er? Welche Angriffe eine einzelne Anbindung öffnet, von vergifteten Werkzeugbeschreibungen bis zum manipulierten Server-Paket, zeigt der Beitrag zur MCP Security im Detail.
Wie bricht man die Trifecta architektonisch?
Der sauberste Bruch trennt das Modell, das fremde Inhalte sieht, von dem Modell, das Werkzeuge bedient. Ein privilegierter Planer bekommt nie fremden Text zu Gesicht; ein abgeschotteter Arbeiter verarbeitet den fremden Text, hat aber keine Werkzeuge und keinen Kanal nach außen. Zwischen beiden fließen nur strukturierte, geprüfte Daten, keine freie Sprache.
# Planer: hat Werkzeuge, sieht nie Rohtext aus fremder Quelle
plan = planer.entscheide(auftrag_des_nutzers) # keine fremden Inhalte im Prompt
# Arbeiter: sieht den fremden Text, hat keine Werkzeuge, keinen Ausgang
extrakt = arbeiter.lies(fremdes_dokument) # kann nichts auslösen
extrakt = nur_erlaubte_felder(extrakt) # strukturiert, nicht frei
# Kanal nach außen nur nach expliziter Freigabe:
if plan.will_senden and freigabe_ausserhalb_des_modells(plan.ziel):
mail.send(plan.ziel, extrakt)
Der abgeschottete Arbeiter darf von einer Injection vollständig übernommen werden, ohne dass Schaden entsteht: Er hat keine Hand, mit der er handeln könnte. Der Planer könnte handeln, sieht aber nichts Feindliches. Kein Pfad hält alle drei Kreise. Diese Trennung ist unbequemer als ein Agent, der alles selbst macht, und genau das ist der Preis, den überschüssige Handlungsmacht sonst versteckt.
Was schützt wirklich?
Die Regeln sind alt, nur ernster geworden. Minimale Rechte pro Werkzeug, technisch erzwungen, nicht per Anweisung im Prompt erbeten. Sandboxing für alles, was ausgeführt wird. Eine Bestätigung außerhalb des Modells vor jeder unumkehrbaren Aktion: senden, löschen, bezahlen, veröffentlichen. Und lückenlose Protokolle, denn ein Agent, der ohne Spur handelt, lässt sich hinterher nicht untersuchen.
Vor dem Ausrollen entscheiden vier Fragen über den Großteil des Risikos:
- Welche der drei Trifecta-Kreise deckt dieser Agent auf seinem schlechtesten Pfad gleichzeitig ab?
- Was kann er tun, was sich nicht rückgängig machen lässt, und welche Bestätigung steht davor?
- Mit wessen Rechten handelt er, und passt das zu dem, der seine Eingaben tatsächlich liefert?
- Wäre er jetzt vollständig übernommen: Wie groß wäre der Schaden, und wer würde es merken?
Excessive Agency, in den OWASP LLM Top 10 als LLM06 geführt, ist genau dieser Punkt, katalogisiert. Die Eintrittstechnik behandelt das Dossier Prompt Injection, die Bestätigungsschicht das Dossier Guardrails. Den Überblick über die Angriffsfläche von Agenten gibt das Dossier KI-Agenten.
Was nicht hilft
- Dem System-Prompt vertrauen, dass er den Agenten im Zaum hält („nutze das Mail-Werkzeug nur für X“). Ein Prompt ist keine Rechtegrenze. Die Injection ist ebenfalls nur Text und steht mit ihm auf einer Stufe.
- Dem Agenten breite Rechte geben, aus Bequemlichkeit, und sie später einschränken wollen. Der bequeme Standard ist der, der in Produktion geht und bleibt. Ein Agent, der alles darf, weil es einfacher war, ist ein Generalschlüssel im Briefkasten.
- Einen bestandenen Test vor dem Launch für Sicherheit halten. Was ein Agent erreichen kann, ändert sich wöchentlich: neue Werkzeuge, neue MCP-Server, neue Daten. Der sichere Pfad von gestern ist die Trifecta von heute.
- Annehmen, dass ein Mensch in der Schleife skaliert. Bestätigungsmüdigkeit macht aus „jede Aktion bestätigen“ ein „auf Ja klicken“. Die Bestätigung gehört vor das Unumkehrbare, sonst wird sie zum Theater.
Fazit
Die Frage, die ein Agent erzwingt, ist nicht „was kann das Modell sagen“, sondern „was kann es tun, und mit wessen Befugnis“. Das ist eine alte Sicherheitsfrage, und sie hat alte Antworten: minimale Rechte, Isolation, Bestätigung, Protokoll. Der Fehler ist, Agentensicherheit als Eigenschaft des Modells zu behandeln, auf die man wartet, statt als Eigenschaft des Systems, die man entwirft. Wer die Trifecta auf jedem Pfad bricht und vor alles Unumkehrbare eine Grenze außerhalb des Modells setzt, hat am Ende einen Vorfallbericht statt einer Datenpanne.