Eindämmen statt abwehren – Agenten-Sicherheit für alle, die Rechte vergeben

Du hast einem Assistenten Zugriff auf deinen Kalender und dein Postfach gegeben. Er soll dir montags die Woche zusammenfassen und Antworten auf Kundenmails vorbereiten. Praktisch, spart eine halbe Stunde.

In einer Einladung von außen steht in der Beschreibung ein Absatz, den du nie liest. Weiße Schrift auf weißem Grund, oder einfach weit unten nach dreißig Leerzeilen.

Die Frage, um die es in dieser Lesson geht: Woran soll der Assistent erkennen, dass dieser Absatz nicht von dir ist?

Er kann es nicht. Deine Anweisung und der fremde Absatz landen im selben Kontextfenster, in derselben Form: als Text. Es gibt keine Markierung, die eine echte Anweisung von einer eingeschleusten unterscheidet, weil beides dieselbe Sache ist.

Wer schon einmal mit Datenbanken zu tun hatte, kennt das Muster. Bei SQL-Injection schreibt jemand in ein Formularfeld nicht seinen Namen, sondern einen Befehl. Die Datenbank kann nicht unterscheiden, was Abfrage und was Eingabe ist, und führt beides aus.

Prompt Injection ist dasselbe Problem eine Ebene höher. Und bis hierhin trägt der Vergleich. Der Unterschied steckt in der Lösung.

Simon Willison, der den Begriff maßgeblich geprägt hat, formuliert den Kern so: Modelle folgen nicht nur unseren Anweisungen, sondern bereitwillig jeder Anweisung, die es ins Modell schafft. Sie sind nicht in der Lage, die Wichtigkeit einer Anweisung zuverlässig danach zu beurteilen, woher sie kam.

Warum das jetzt gefährlich wird und vorher nicht

Bei einem Chatbot war der Schaden begrenzt. Im schlimmsten Fall sagte er etwas Dummes. Ein Agent sagt nicht, er tut. Er öffnet Postfächer, schreibt in Repositories, ruft Schnittstellen auf, verschickt Mails. Dieselbe Lücke, plötzlich mit Händen.

Der zweite Fall ist der eigentliche Angriff. Der Angreifer schreibt einmal etwas an eine Stelle, die dein Agent irgendwann liest, und wartet. Er braucht keinen Zugang zu deinem System, kein Passwort, keine Einladung.

Oberflächen, die dein Agent liest

• E-Mails von außen, samt Signatur, Fußzeile und Anhang
• PDFs, etwa Bewerbungen, Rechnungen, Angebote
• Webseiten, die der Agent zum Recherchieren aufruft
• Tickets und Issues, die jeder anlegen kann
• Kalendereinladungen von fremden Adressen
• README-Dateien und Repositories, die der Agent durchsieht
• Geteilte Dokumente, bei denen jemand anderes Schreibrecht hat
• Wissensdatenbanken, in die Inhalte automatisch einfließen

So unauffällig sieht das aus

Beide sind echt in dieser Form vorgekommen. Ausschnitt B enthält übrigens ein Detail, auf das wir in Schritt 6 zurückkommen: Das vorangestellte Additionally hat in einem dokumentierten Fall gereicht, um die Erkennung eines großen Anbieters auszuhebeln.

Bleiben wir beim Beispiel, das diese Lesson trägt: Ein Agent liest das Team-Postfach und legt Antworten als Entwurf an. Harmlos, oder?

Sind alle drei da, passt der Angriff in drei Sätze. Der Angreifer schreibt eine Anweisung in einen Inhalt, den der Agent verarbeitet. Der Agent führt sie aus. Private Daten verlassen das Haus.

Der Kanal nach außen ist größer, als du denkst

• Eine Mail verschicken, klar
• Eine Schnittstelle aufrufen, auch klar
• Ein Bild anzeigen. Die URL kann die Daten enthalten, und der Abruf allein reicht schon
• Einen Link rendern, auf den jemand klickt
• In ein öffentliches Repository oder einen öffentlichen Kommentar schreiben

Der Bildpunkt ist der, den fast alle übersehen. Es braucht keinen Versand, es reicht, dass eine Adresse abgerufen wird. Genau so läuft eines der vier Muster aus Schritt 6.

Die Trifecta sagt dir, wo du stehst. Sie sagt dir nicht, was du tun sollst. Diese Lücke füllt eine Regel, die Meta im Oktober 2025 veröffentlicht hat, inspiriert von Willisons Trifecta und der gleichnamigen Regel aus dem Chromium-Projekt.

Ein Agent soll innerhalb einer Sitzung höchstens zwei dieser drei Eigenschaften erfüllen: er verarbeitet nicht vertrauenswürdige Eingaben [A], er hat Zugriff auf sensible Systeme oder private Daten [B], er kann Zustand ändern oder nach außen kommunizieren [C].

Unser Postfach-Agent, dreimal umgebaut

Erinnerst du dich an den Agenten, der Mails liest und Antworten als Entwurf anlegt? Der ist bereits eine Rule-of-Two-Lösung, und zwar die dritte Variante. Er liest fremde Mails [A], er sieht das Postfach [B], aber er verschickt nichts. Der Entwurf wartet auf einen Menschen.

Was die Regel nicht ist

• Kein Sicherheitsversprechen. Meta hat die Beschriftung nach öffentlicher Kritik von "safe" auf "lower risk" geändert. Die Regel schließt die schwersten Folgen aus, nicht alle.
• Kein Ersatz für Least Privilege, sondern eine Ergänzung dazu. Das steht so im Originalbeitrag.
• Kein Verbot. Braucht ein Agent wirklich alle drei, sagt die Regel: dann nicht autonom. Dann braucht er Aufsicht, mindestens eine menschliche Freigabe.
• Kein Schutz gegen alles andere. Halluzinationen, schlichte Fehler und Verwechslungen deckt sie nicht ab. Dafür ist sie nicht gebaut.

Wichtig ist außerdem, wie weit [B] gefasst ist. Es geht nicht nur um personenbezogene Daten, sondern um jedes sensible System. Ein Produktivsystem, das der Agent umkonfigurieren kann, zählt genauso.

Angriffe auf Agenten sehen von außen unterschiedlich aus und laufen innen gleich. Es gibt einen Weg hinein und einen Weg hinaus. Wenn du beide für deinen Agenten benennen kannst, hast du das Wesentliche verstanden.

In der ersten Spalte steht immer jemand, der nie mit dir gesprochen hat. In der dritten steht etwas, das du selbst eingerichtet hast, weil es nützlich war. Der Angriff verbindet nur beides.

Zwei Beobachtungen, die sich wiederholen

Erstens: Ein einziges Wort kann eine Erkennung aushebeln. In einem dokumentierten Fall war der Schutzmechanismus eines großen Anbieters aktiv und verweigerte die Ausführung. Dann wurde der Anweisung ein unscheinbares Wort vorangestellt, etwa im Sinne von "außerdem". Danach verweigerte das Modell nicht mehr, sondern formulierte seine Ausgabe um. Merk dir das, wenn dir jemand eine Erkennungsrate nennt.

Zweitens: Das Leck entsteht oft an einer Stelle, die mit Sicherheit nichts zu tun hat. Ein Assistent, der seine Änderung speichert, bevor der Mensch bestätigt, ist eine Bequemlichkeitsentscheidung. Sie sorgt aber dafür, dass ein eingebettetes Bild geladen wird, bevor irgendjemand hingesehen hat. Damit sind die Daten weg, ohne dass jemand auf etwas geklickt hat. Prüf bei deinen Werkzeugen, was passiert, bevor du bestätigst.

Die naheliegende Idee ist ein Filter. Ein Modul davor, das eingehenden Text auf Injections prüft und Verdächtiges blockiert. Es gibt Produkte dafür, und sie fangen etwas ab.

Als Hauptverteidigung tragen sie nicht. Ein Forscherteam mit Beteiligung von OpenAI, Anthropic, Google DeepMind und der ETH Zürich hat im Oktober 2025 zwölf veröffentlichte Verteidigungen gegen Jailbreaks und Prompt Injection systematisch angegriffen. Ergebnis: Bei den meisten lag die Erfolgsquote der Angriffe über 90 Prozent. Die Mehrheit dieser Verteidigungen hatte ursprünglich Erfolgsquoten nahe null gemeldet.

Was tatsächlich hilft

Die Zeile mit dem Protokoll ist die, die am häufigsten halbherzig umgesetzt wird. Ein Log, das nur festhält, dass ein Werkzeug aufgerufen wurde, hilft dir nach einem Vorfall nicht weiter.

Die dritte Zeile ist der Unterschied. Sie beantwortet die Frage, die nach einem Vorfall als erste kommt: Warum hat er das gemacht?

Wer einen Agenten freigibt, vergibt Rechte. Und wer Rechte vergibt, hat die Fragen zu beantworten, wenn etwas passiert. Drei reichen für den Anfang.

1. Welche Rechte hat dieser Agent tatsächlich? Nicht welche er laut Beschreibung braucht, sondern welche im Zugangssystem eingetragen sind. Der Unterschied ist regelmäßig groß.
2. Wo endet der Schaden im schlimmsten Fall? Wenn eine fremde Anweisung durchkommt und der Agent alles tut, was er darf: Was ist dann weg, und wen betrifft es?
3. Wer haftet, wenn es passiert? Mit Namen, nicht mit Abteilung.

Das Inventar zum Mitnehmen

Eine Zeile pro produktivem Agenten, und darüber die drei Trifecta-Kreuze aus Schritt 4. Mehr braucht es nicht, um in einer Governance-Runde auskunftsfähig zu sein. Was nicht im Inventar steht, existiert für die Aufsicht nicht, läuft aber trotzdem.

Wo die Fachwelt sich uneinig ist

Ehrlichkeitshalber: Ob Prompt Injection grundsätzlich lösbar ist, ist offen. Teile der Anbieterlandschaft arbeiten daran in der Annahme, dass es geht. Andere behandeln es als Eigenschaft der Bauform, mit der man dauerhaft leben muss. Diese Lesson steht auf der zweiten Seite, weil du heute entscheiden musst und nicht in drei Jahren.

Auch die Rule of Two ist nicht unumstritten. Strikt befolgt macht sie Produkte spürbar unbequemer, und gute Produkte brauchen mehr Nuance als eine Regel. Nimm sie als Ausgangspunkt, von dem du bewusst abweichst, nicht als Dogma.

Die sieben Regeln auf einen Blick