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.

Die praktische Sicherheitsfrage stellt sich trotzdem schon heute. 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. Eine interne Modellbegründung oder die Werkzeugbeschreibung ist keine Zugriffskontrolle.

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.

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. Entscheidend bleibt, dass der Zielservice einen nicht gedeckten Aufruf unabhängig vom Modelltext verweigert. 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 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.

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. 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.