KI-Agent-Autorisierung: Die Kontrolle gegen Prompt Injection

Die wichtigste KI-Agenten-Sicherheitskontrolle in 2026 ist kein klügerer Prompt-Filter. Es ist Autorisierung, in Code zu entscheiden, was ein Agent tun darf, bevor er irgendetwas tut. Eine Studie aus 2026, die Tausende Angriffe gegen Browser-Agenten laufen ließ, fand, dass direkte Prompt Injection in mehr als 79 % der Fälle gelang, und OWASP führt Prompt Injection inzwischen als Risiko Nummer eins für Anwendungen mit großen Sprachmodellen. Sie können die Injection nicht zuverlässig stoppen. Sie können entscheiden, was ein gekaperter Agent erreicht, und diese Entscheidung ist eine Autorisierungskontrolle, keine Modellkontrolle.

Das ist derselbe Zug, den jeder regulierte Firewall-Bestand längst gemacht hat: Man vertraut nicht dem Paket, man begrenzt, was es erreichen kann. Auf Agenten angewandt ändert das die Frage von „Können wir verhindern, dass der Agent getäuscht wird?" zu „Wenn er getäuscht wird, wie groß ist der Schadensradius?" Die erste Frage hat keine gute Antwort. Die zweite hat eine Kontrolle, die Sie bauen, testen und einem Auditor vorlegen können.

Prompt Injection ist kein Fehler, den man patcht

Es hilft, präzise zu sein, warum Filtern verliert. Ein Sprachmodell liest seine Anweisungen und die verarbeiteten Daten als einen Strom von Tokens. Wenn ein Agent eine E-Mail, eine Webseite oder ein PDF liest, um seine Arbeit zu tun, sitzt jeder Text in diesem Inhalt im selben Kontext wie Ihre Anweisungen, und das Modell kann den einen nicht zuverlässig als vertrauenswürdig und den anderen als nicht markieren. Simon Willison nannte die gefährliche Konstellation die tödliche Trias: ein Agent mit Zugang zu privaten Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und einem Weg, Daten hinauszusenden, liegt bedingungslos offen für Datenabfluss. Keine System-Prompt-Härtung beseitigt diese Offenheit, weil die Härtung im selben Strom lebt, in den der Angreifer schreibt.

Also ist „wir patchen es im nächsten Modell" kein Plan. Die Erfolgsrate sinkt mit besseren Modellen und ausdrücklichen Schutzmaßnahmen, sie geht nicht auf null, und der Angreifer hat unbegrenzte Versuche und muss nur einmal gewinnen. Für die gemessene Version siehe unsere Notiz zur KI-Agenten-Angriffserfolgsrate und wie sie ins Risikoregister gehört und die umfassendere Aufzählung im KI-Agenten-Bedrohungsmodell.

Die Vorfälle sind Autorisierungsfehler, keine Injection-Fehler

Schauen Sie, wie sich Agenten-Vorfälle in einer Post-Mortem tatsächlich lesen, und ein Muster zeigt sich. Der Agent hat sich korrekt authentifiziert. Er war eine legitime Komponente bei legitimer Arbeit. Dann führte er eine Handlung aus, die ihm nie hätte erlaubt sein dürfen, ausgelöst durch Text, den ein Angreifer in seine Eingaben gepflanzt hat. Das ist kein neuartiger KI-Fehler. Es ist ein Confused Deputy: ein vertrauenswürdiger Prozess, der dazu verleitet wird, die Autorität zu missbrauchen, die er rechtmäßig hält. Die Injection ist der Auslöser; der Schaden entsteht durch Autorität, die der Agent in diesem Moment nicht hätte haben dürfen.

Diese Umdeutung zählt, weil sie den Fix auf Boden verschiebt, den wir bereits verstehen. Man stoppt einen Confused-Deputy-Angriff nicht, indem man den Deputy klüger macht. Man stoppt ihn, indem man sicherstellt, dass der Deputy von vornherein nie autorisiert war, das Gefährliche zu tun. Ein Agent, der keine Rückerstattungen ausstellen kann, kann nicht dazu verleitet werden, eine auszustellen. Ein Agent, dessen Zugangsdaten auf ein einziges read-only Postfach begrenzt sind, lässt sich nicht überreden, die Datenbank zu löschen, weil diese Autorität nie auf dem Tisch lag. Dieselbe Logik trägt das Segmentieren eines agentengesteuerten Entwickler-Arbeitsplatzes, damit ein gekaperter Agent in einen Schadensradius eingeschlossen ist, den Sie im Voraus gewählt haben.

Behandeln Sie jede Agenten-Handlung als privilegierte Änderung

Firewall-Change-Management erzwingt diese Disziplin seit Jahrzehnten, und sie überträgt sich direkt. Eine Firewall-Änderung ist privilegiert, gescopt, protokolliert und per Konstruktion umkehrbar, und niemand vertraut darauf, dass sich der Operator einfach an die Regeln erinnert hat. Agenten-Handlungen verdienen dieselbe Behandlung, denn ein Agent, der Tools aufrufen kann, ist ein Prozess, der Änderungen mit realen Konsequenzen vornimmt.

Drei Kontrollen tragen das meiste Gewicht, und alle drei sind aus der Netzwerkwelt vertraut:

• Default-Deny bei der Tool-Autorisierung. Ein Agent startet ohne Capabilities und erhält das engste Set, das ihm die konkrete Aufgabe erlaubt, gescopt auf die Identität des aufrufenden Nutzers, nie ein breiter Service-Account. Das ist Least Privilege, angewandt auf Tool-Aufrufe statt auf Firewall-Regeln, derselbe Instinkt hinter Mikrosegmentierung.
• Egress-Kontrolle bricht das Exfiltrations-Bein. Der meiste Injection-Gewinn ist Daten, die hinausgehen. Eine Allowlist dafür, wohin ein Agent Daten senden darf, entschärft den Angriff, selbst wenn der Prompt gewinnt, genau so, wie Egress-Filterung einen kompromittierten Host eindämmt. Entfernen Sie den Exfiltrationsvektor, und die tödliche Trias fällt auf zwei Beine zusammen.
• Schreiben Sie die Autorisierung auf die Handlung. Wenn ein Agent handelt, halten Sie fest, wozu er autorisiert war, unter wessen Identität und wann, eingefroren im Moment der Handlung. Das ist dasselbe Audit-Muster hinter dem Autorisierungs-Gate für aktives Scanning, und es macht aus „Warum hat der Agent das getan?" statt einer Erinnerung einen Datensatz.

Was den Schadensradius wirklich verkleinert

Verteidigungen sind nicht gleichwertig. Manche versuchen, die Injection zu stoppen, was eine verlorene Wette ist, und manche begrenzen die Konsequenzen, was hält. Die Tabelle ist der Unterschied zwischen einer Kontrolle, die Sie im Audit verteidigen können, und einer Hoffnung, die Sie nicht verteidigen können.

Eine Autorisierungs-Checkliste für den Agenten-Start

Bevor ein Agent in die Produktion geht, sollte jeder dieser Punkte eine konkrete Antwort haben, aufgeschrieben, im Risikoregister neben den Firewall-Regeln, neben denen er jetzt sitzt.

• Schlimmster Fall. Was ist die schlimmste einzelne Handlung, die dieser Agent ohne Mensch in der Schleife ausführen kann? Lautet die Antwort „Geld ausgeben", „Daten löschen" oder „Code deployen", braucht dieser Pfad ein ausdrückliches Gate.
• Gescopte Identität. Sind die Tool-Berechtigungen des Agenten auf den aufrufenden Nutzer gescopt, oder läuft er auf einem Alles-oder-nichts-Service-Account? Service-Account-Agenten erben jede Berechtigung, die der Account hat.
• Egress. Wohin kann dieser Agent Daten senden, und ist diese Liste eine Allowlist oder „überallhin"? Überallhin ist ein stehender Exfiltrationsvektor.
• Unumkehrbarkeit. Welche Handlungen sind Einbahnstraßen, und welche davon verlangen menschliche Bestätigung pro Aufruf statt einer pauschalen Session-Freigabe?
• Audit. Können Sie im Nachhinein rekonstruieren, was der Agent tat, unter wessen Autorität und auf welche Eingabe? Werden die Argumentationskette und die Tool-Eingaben nicht protokolliert, können Sie das nicht.

Die Zweierregel als Design-Standard

Wenn Sie eine Heuristik als Ausgangspunkt wollen, ist Metas „Agents Rule of Two" eine gute: Ein unbeaufsichtigter Agent sollte höchstens zwei der drei Fähigkeiten der tödlichen Trias halten, und sobald eine Aufgabe alle drei braucht, genehmigt ein Mensch den Schritt. Ein Agent, der nicht vertrauenswürdige Webseiten liest und zusammenfasst, ist in Ordnung. Derselbe Agent, der Ihre Zugangsdaten hält und nach außen posten kann, ist es nicht, bis ein Mensch zustimmt. Es ist die Agenten-Zeit-Neufassung der Funktionstrennung, und sie passt sauber auf die Zero-Trust-Änderungssteuerung, die regulierte Bestände bereits fahren.

Warum das wichtig ist

Unter NIS2, DORA und ISO 27001 ist „wir haben es dem Modell verboten" keine Kontrolle, die ein Auditor akzeptiert, ebenso wenig wie „wir haben dem Operator gesagt, er solle vorsichtig sein" eine Antwort für eine Out-of-Scope-Firewall-Änderung ist. Autorisierung ist es. Begrenzen Sie, was der Agent darf, beschränken Sie, wohin seine Daten gehen, sichern Sie das Unumkehrbare ab und protokollieren Sie alles, und eine erfolgreiche Prompt Injection wird zu einem Ereignis, das Ihre Architektur bereits eingedämmt hat, statt zum Vorfall auf der Titelseite des Reports. Die Injection wird landen. Ob sie zählt, ist eine Entscheidung, die Sie im Autorisierungsmodell treffen, nicht im Prompt.

Bringen Sie Agenten in einen regulierten Bestand? Der kostenlose NIS2-Readiness-Check deckt genau das ab: wo die Autorität einer autonomen Komponente gescopt ist, wo nicht und was ein Auditor verlangen wird.