Die technische Vollmacht von KI-Agenten begrenzen

NIST startete am 17. Februar 2026 die AI Agent Standards Initiative und aktualisierte deren Arbeitsseite im August. Parallel untersucht das National Cybersecurity Center of Excellence in einem Konzeptpapier, wie Software- und KI-Agenten identifiziert, autorisiert und ihren Handlungen menschliche Vollmachten zugeordnet werden können. Das Dokument ist als Entwurf veröffentlicht; der Projektstatus lautet weiterhin „Reviewing Comments“. Ein fertiger NIST-Standard lässt sich daraus nicht ableiten.

Für den Betrieb lässt sich die Vollmachtsgrenze bereits bestimmen. Ein Agent kann Daten lesen, Nachrichten vorbereiten oder einen Werkzeugaufruf erzeugen. Eine geschäftliche Zustandsänderung entsteht aber erst, wenn der angeschlossene Dienst diesen Aufruf annimmt und ausführt. Dort liegt die technisch wirksame Grenze der Vollmacht. Weder eine interne Modellbegründung noch die Werkzeugbeschreibung setzt eine Zugriffskontrolle durch.

Identität, Autorisierung und Nutzlast

Für den Betrieb empfiehlt sich eine eigene verwaltete nichtmenschliche Identität des Agenten. Gemeinsam verwendete Zugangsdaten oder unverändert übernommene Benutzersitzungen erschweren die spätere Zuordnung: Welcher automatisierte Akteur handelte, auf wessen Delegation und mit welchem Auftrag? Das NCCoE-Papier behandelt genau diese Verbindung von nichtmenschlicher Identität, Autorisierung, Delegation und Auditierbarkeit, legt dafür aber noch kein verbindliches Token- oder Freigabeschema fest.

Das empfangende System sollte Identität, Berechtigung, Ziel und Parameter nach seinen eigenen Regeln prüfen. Eng gefasste Operationen lassen sich genauer begrenzen als eine allgemeine Datenbankabfrage oder ein pauschales Schreibrecht. Kurzlebige Berechtigungen können den Zugriff zusätzlich auf bestimmte Ressourcen, Aktionen, Zeiträume und Höchstwerte einschränken. Diese Architektur ist eine redaktionelle Sicherheitsableitung aus dem Entwurf, keine bereits verabschiedete NIST-Vorgabe. Bei folgenreichen Handlungen reicht eine Zustimmung zu einer Zusammenfassung nicht. Die prüfende Person sollte die tatsächlich auszuführende Nutzlast sehen. Ändern sich danach Empfänger, Betrag, Zielobjekt oder andere entscheidungsrelevante Parameter, passt die frühere Freigabe nicht mehr zu der Handlung. Eine neue Entscheidung bindet die Vollmacht wieder an den aktuellen Inhalt.

Für eine solche Begrenzung existieren bereits OAuth-Bausteine. RFC 8707 beschreibt die Bindung eines Zugriffstokens an eine bestimmte Zielressource. Ein Token für einen Dienst soll damit nicht ohne Weiteres bei einem anderen Dienst verwendbar sein. Diese Zielbindung ersetzt weder die Prüfung der erlaubten Operation noch die Begrenzung ihrer Parameter. Sie schützt auch nicht allein davor, dass ein gestohlenes Bearer-Token beim vorgesehenen Empfänger verwendet wird. RFC 9396 führt mit authorization_details genauer gegliederte Autorisierungsdaten ein. Das Zahlungsbeispiel des Standards nennt Betrag, Währung und Empfänger. Die konkrete API muss definieren, was diese Angaben bedeuten und wie sie durchgesetzt werden. Ein korrektes JSON-Objekt erteilt deshalb noch keine wirksame Vollmacht. Erst die Verbindung von erteilter Zustimmung und Prüfung durch Autorisierungs- sowie Zielsystem begrenzt die Handlung. Diese Standards liefern technische Bausteine; sie sind keine NIST-Vorgabe speziell für KI-Agenten.

Unvertrauenswürdige Eingaben

Indirekte Prompt Injection kann über eine E-Mail, ein Dokument, eine Webseite oder die Ausgabe eines anderen Werkzeugs in den Agentenkontext gelangen. OWASP führt für agentische Anwendungen unter anderem Agent Goal Hijack, Tool Misuse and Exploitation sowie Identity and Privilege Abuse. Das Risikorahmenwerk ist kein amtlicher Standard, beschreibt aber die relevanten Angriffskategorien.

Eine in einem Dokument versteckte Anweisung darf deshalb weder neue Rechte erzeugen noch das freigegebene Datenziel verändern. Eng definierte Schemas, zugelassene Ziele, isolierte Ausführung, kurzlebige Zugangsdaten und ein Nur-Lese-Modus können die Reichweite begrenzen. Sie garantieren weder Manipulationsschutz noch inhaltliche Richtigkeit. Der Zielservice muss einen nicht gedeckten Aufruf unabhängig vom Modelltext verweigern. Bei wenig vertrauenswürdigen Eingangsdaten kann der Agent zunächst nur einen prüfbaren Entwurf erzeugen, während schreibende Werkzeuge gesperrt bleiben.

Pilotbetrieb und Wiederholungen

Als begrenzte Betriebsempfehlung kann ein Pilot mit einem überschaubaren Datenraum und einem vorhandenen manuellen Ersatzweg beginnen. Zunächst wird nur ausgewertet, danach möglicherweise ein Entwurf erzeugt; erst belastbare Beobachtungen rechtfertigen eine eng begrenzte Zustandsänderung. Diese Stufenfolge steht weder bei NIST noch bei OWASP als allgemeine Norm. Sie verhindert lediglich, dass Rechte und unbekannte Betriebsrisiken gleichzeitig wachsen. Nachvollziehbar bleiben sollten Auftrag, verwendete Quellen, Autorisierungsentscheidung, Werkzeugaufruf und Ergebnis. Vertrauliche Inhalte müssen dafür nicht wahllos in eine zweite Datenhaltung kopiert werden. Geschützte Referenzen und technische Kennungen können genügen, sofern sich der ausgeführte Vorgang damit eindeutig untersuchen lässt. Welche Daten aufbewahrt werden dürfen und wie lange, folgt aus dem konkreten System und den dafür geltenden Regeln.

Mehrstufige Abläufe brauchen außerdem einen Umgang mit Wiederholungen. Bricht der Agent nach einem Werkzeugaufruf ab, kann er denselben Schritt erneut anstoßen. Bei Zahlungen, Bestellungen oder Buchungen in der Buchhaltung können so doppelte Wirkungen entstehen.

Das Zielsystem sollte fachlich identische Wiederholungen erkennen und je nach Prozess ablehnen oder auf dasselbe bereits erzeugte Ergebnis zurückführen. Der Nachweis gehört in das System, in dem die Wirkung entsteht, nicht allein in den Modellverlauf. Ein Verbindungsabbruch nach dem Aufruf lässt offen, ob die Änderung bereits ausgeführt wurde und nur die Antwort verloren ging. RFC 9110 begrenzt automatische Wiederholungen nicht idempotenter Methoden auf Fälle, in denen der Client eine idempotente Anwendungssemantik kennt oder erkennen kann, dass der erste Versuch nicht angewendet wurde. Für den Agentenbetrieb folgt daraus: Ein Werkzeugfehler allein rechtfertigt keine zweite Zahlung oder Bestellung. Ist eine sichere Wiederholung nicht durch die Anwendungssemantik gewährleistet, muss zunächst geklärt werden, ob der ursprüngliche Vorgang ausgeführt wurde.

Die AWS Builders Library beschreibt dafür einen Vertrag mit einer vom Aufrufer vergebenen Vorgangskennung. Derselbe Aufrufer kann denselben Auftrag unter dieser Kennung wiederholen. Nur gleiche Parameter zu vergleichen, wäre unzureichend: Zwei inhaltlich identische Bestellungen können absichtlich zwei getrennte Vorgänge sein. Die Kennung hält die Absicht der einzelnen Ausführung fest. Im beschriebenen Verfahren bilden das Speichern der Kennung und die fachliche Änderung eine gemeinsame atomare Operation. Andernfalls könnte entweder eine Wirkung ohne Nachweis oder ein Nachweis ohne Wirkung entstehen. Kommt dieselbe Kennung mit veränderten Parametern zurück, antwortet der Dienst mit einem Validierungsfehler. Wie lange solche Kennungen aufbewahrt werden, muss auch verspätete Wiederholungen berücksichtigen.

Daraus ergibt sich für einen wiederaufgenommenen Agentenauftrag die Empfehlung, die bestehende Vorgangskennung zu erhalten und das bereits erzeugte Ergebnis im Zielsystem abrufen zu können. Das ist ein anwendungsbezogener Vertrag, kein allgemeines Versprechen einer exakt einmaligen Ausführung beliebiger Werkzeugketten.

Widerruf und Transparenz

Ein Not-Aus ist erst wirksam, wenn er neue Schritte verhindert, wartende Aufträge an kontrollierten Punkten anhält und delegierte Zugangsdaten widerruft.

Das NCCoE-Papier behandelt Widerruf als offene Architekturfrage, definiert aber keinen fertigen Stoppschalter. Für den konkreten Betrieb liefert deshalb eine Übung den Nachweis: laufenden Auftrag stoppen, Zugänge prüfen und anschließend den Zustand im Zielsystem eindeutig feststellen. RFC 8693 macht eine Grenze delegierter Tokens deutlich: Ein Tokenaustausch verkettet deren Lebenszyklen nicht automatisch. Der Widerruf des ursprünglichen Tokens widerruft deshalb nicht zwangsläufig ein daraus bereits ausgegebenes Token für einen nachgelagerten Dienst. Ob und wie dieser Widerruf weitergegeben wird, hängt von der Umsetzung ab. Für den vorgeschlagenen Not-Aus muss daher auch geprüft werden, welche delegierten Zugriffe nach dem Stoppen des Agenten noch wirksam sind. Das Beenden seines Prozesses und das Entziehen seiner Vollmachten sind zwei getrennt nachzuweisende Vorgänge.

Die Transparenz gegenüber betroffenen Personen bleibt eine getrennte Rechtsfrage. Artikel 50 des AI Act kann bei direkter Interaktion oder bestimmten veröffentlichten Inhalten Informations- beziehungsweise Offenlegungspflichten auslösen. Eine Kennzeichnung verleiht dem Agenten keine Berechtigung; eine saubere Autorisierung erfüllt umgekehrt nicht automatisch die Transparenzpflicht.

Hinweis: Diese Einordnung ersetzt keine Prüfung des Einzelfalls.