Vom Zugriff zur Handlungsvollmacht

Sie verantworten die Plattformsicherheit in einem Unternehmen, das gerade den dritten Antrag für einen produktiven KI-Agenten prüft. Der erste Agent beantwortete nur Supportanfragen im Chat, ohne selbst etwas zu verändern. Der zweite schließt inzwischen Tickets eigenständig, weil er erkennt, wann ein Vorgang erledigt ist. Der dritte, der jetzt auf Ihrem Tisch liegt, soll eigenständig Zugriffsrechte in einem Nachbarsystem abrufen, Konfigurationen anpassen und bei Bedarf einen weiteren, spezialisierten Agenten aufrufen. Für den ersten Agenten reichte eine Rolle im bestehenden Identitätsmanagement aus. Für den dritten reicht sie nicht mehr, weil die eigentliche Frage nicht mehr lautet, wer sich anmelden darf, sondern wie weit ein System handeln darf, ohne dass ein Mensch jeden einzelnen Schritt freigibt.

Klassisches Access Management wurde für Menschen gebaut, die sich einloggen, etwas tun und sich wieder abmelden. Ein Agent mit Werkzeugzugriff verhält sich anders: Er handelt in Serien, ruft weitere Dienste auf, und ob eine einzelne Aktion angemessen ist, entscheidet in vielen Fällen kein Mensch mehr in Echtzeit. Damit verschiebt sich die Frage von der Identität – wer ist das? – zur Autorität: Was darf dieses Konto in diesem Moment tatsächlich bewirken, und wer trägt die Verantwortung dafür? Die allgemeine Identitäts- und Delegationsgovernance für KI-Agenten behandelt ein eigener Beitrag zur Sicherheit von KI-Agenten bereits ausführlich; dieser Beitrag vertieft speziell die Handlungsbefugnis selbst – also die Autorität, die ein Agent tatsächlich ausüben darf, nicht nur, wer er ist.

Genau an diesem Punkt setzt NIST an. Die Behörde arbeitet an eigenständigen Agentenidentitäten, die von menschlichen Zugangsdaten getrennt sind, an kurzlebigen statt statischen Zugriffsschlüsseln und warnt ausdrücklich vor einem Effekt, den sie „Consent Fatigue“ nennt – zu häufige Freigabeanfragen, die ihren eigenen Sicherheitswert zerstören. Die folgenden drei Abschnitte gehen diesen Befunden im Einzelnen nach, bevor daraus eine praktische Verwaltungsebene für Handlungsbefugnis wird.

Warum geteilte Zugangsdaten zum eigentlichen Risiko werden

NIST warnt in einem Fachbeitrag vom 27. August 2026, dass geteilte Zugangsdaten zwischen Mensch und Agent Verantwortungslücken schaffen, die zu Sicherheits-, Datenschutz- und Rechtsproblemen führen können. Der Gedanke dahinter ist einfach, sobald man ihn ausspricht: Teilt sich ein Agent ein Konto mit einem Menschen oder mit einem anderen Agenten, lässt sich im Nachhinein nicht mehr zweifelsfrei klären, wer eine bestimmte Aktion tatsächlich ausgelöst hat – die Werkleitung, der Servicetechniker oder eben die Software selbst.

Für zwei oder drei Agenten mag ein gemeinsames Dienstkonto noch überschaubar bleiben. Sobald ein Unternehmen jedoch mehrere Dutzend Agenten betreibt, die sich gegenseitig aufrufen, wird aus dieser Unschärfe ein handfestes Problem, weil sich Vorfälle nicht mehr eindeutig einer Quelle zuordnen lassen. Die erste praktische Konsequenz ist deshalb simpler, als sie klingt: Jeder Agent bekommt eine eigene Identität, getrennt von jedem menschlichen Konto und getrennt von jedem anderen Agenten, selbst wenn zwei Agenten dieselbe Aufgabe erledigen. Diese Trennung kostet zunächst Verwaltungsaufwand, weil sie mehr Konten, mehr Rotation und mehr Überwachung bedeutet – sie zahlt sich aber genau in dem Moment aus, in dem etwas schiefläuft, denn nur eine getrennte Identität lässt sich widerrufen, ohne gleich drei weitere Funktionen mit abzuschalten.

Kurzlebige Tokens statt statischer Schlüssel

Ein zweiter Befund desselben NIST-Beitrags betrifft die Art des Zugangsschlüssels selbst. NIST empfiehlt statt langlebiger statischer Schlüssel kurzlebige, eng begrenzte, empfängergebundene Tokens – etwa über etablierte Standards wie OAuth 2.0, SPIFFE oder DPoP (Verfahren für kurzlebige, an einen Dienst gebundene Zugriffsnachweise). Ein statischer Schlüssel, der monatelang gültig bleibt, ist bequem einzurichten und genau deshalb gefährlich: Wird er kopiert, funktioniert er so lange weiter, bis jemand ihn aktiv widerruft, und in vielen Organisationen bemerkt das niemand rechtzeitig.

Ein kurzlebiges Token verfällt dagegen von selbst, oft nach Minuten statt nach Monaten, und ist zusätzlich an einen bestimmten Empfänger gebunden, sodass ein gestohlenes Token bei einem anderen Dienst nicht einfach weiterverwendet werden kann. Für einen Agenten mit Werkzeugzugriff heißt das konkret: Er fordert seine Berechtigung für eine Aufgabe jeweils neu an, statt sie dauerhaft mitzuführen. Das erhöht die Zahl der Authentifizierungsvorgänge messbar, senkt aber den Schaden, den ein einzelner kompromittierter Schlüssel anrichten kann, weil sein Zeitfenster winzig bleibt.

Wenn zu viele Freigaben die Freigabe selbst entwerten

Ein naheliegender Reflex gegen zu weit gefasste Autorität ist die Freigabe durch einen Menschen: Jede kritische Aktion soll erst laufen, wenn jemand zustimmt. NIST beschreibt eine „Consent Fatigue“: Wer zu häufig um Freigabe gebeten wird, gewöhnt sich an reflexartiges Bestätigen – das zerstört genau den Sicherheitswert, den die Freigabe haben sollte. Bemerkenswert an dieser Beobachtung ist, wessen Verhalten NIST hier eigentlich beschreibt: nicht in erster Linie unachtsame Nutzer, sondern Agenten, die zu gesprächig eingerichtet sind und zu oft nach Zustimmung fragen, bis das Klicken auf „Erlauben“ zur Reflexbewegung wird.

Der Grundsatz, den manche Teams als „Human over the Critical Loops“ zusammenfassen – ein Mensch bleibt Herr über die wirklich kritischen Entscheidungsschleifen, nicht über jede einzelne –, ist deshalb kein Ersatz für saubere Autoritätsgrenzen, sondern deren Ergänzung. Ein Mensch, der zwanzig Mal am Tag ein Häkchen setzt, gewöhnt sich an das Häkchen, nicht an die Prüfung. Wer Freigaben sparsam und gezielt einsetzt – an den wenigen Stellen, an denen eine Aktion wirklich nicht rückholbar ist –, bewahrt sich den Vorteil, den eine Freigabe eigentlich bieten soll.

Machine Authority Management: Handlungsvollmacht als eigene Verwaltungsebene

Aus den drei vorigen Befunden – getrennte Identität, kurzlebige Tokens, sparsame Freigaben – lässt sich eine gemeinsame Verwaltungsebene ableiten. Wir bezeichnen sie hier als Machine Authority Management, ein redaktioneller Arbeitsbegriff dieser Redaktion, keine NIST-Terminologie und kein branchenweiter Standard. Er bündelt, was sonst über mehrere getrennte Systeme verteilt wäre – Identität, Zugriff, Delegation –, in eine einzige Frage: Was darf dieser Agent in diesem Moment tatsächlich bewirken? Machine Authority Management und Authority Graph wurden für die Angriffsflächen-Perspektive bereits knapp vorgestellt, dort, wo es um das Schadenspotenzial eines kompromittierten Agentenkontos in der Fertigung geht; dieser Beitrag vertieft beide Begriffe für die Governance- und Identitätsperspektive – wie Handlungsbefugnis vergeben, eingeschränkt und wieder entzogen wird.

Zwei Prinzipien tragen dieses Modell, und beide sind Weiterentwicklungen eines Grundsatzes, den Sicherheitsteams seit Jahrzehnten kennen: das Prinzip der geringsten Rechte, Least Privilege. Wo Least Privilege einem Konto nur die Rechte gibt, die eine Rolle dauerhaft braucht, geht Least Authority – ebenfalls ein redaktioneller Arbeitsbegriff, keine NIST-Vorgabe – einen Schritt weiter und bemisst die Rechte an der einzelnen Aufgabe statt an der Rolle: Ein Agent, der heute eine Datenbankmigration ausführt, bekommt Autorität für genau diese Migration, nicht auf Dauer für alle künftigen. Authority Attenuation beschreibt dazu, was mit dieser Autorität geschieht, sobald sie an einen weiteren, untergeordneten Agenten weitergegeben wird: Sie verengt sich bei jeder Delegation, ähnlich einer Vollmacht, die ein Untervertreter nie weiter fassen darf als der ursprüngliche Vollmachtgeber. Ein zusätzliches Delegationsbudget begrenzt dabei, wie oft und wie tief eine Autorität überhaupt weitergereicht werden darf, bevor ein Mensch erneut hinsehen muss.

Wer Autorität vergibt und wer sie operativ verantwortet, sind in der Praxis häufig zwei verschiedene Rollen: der Owner, der ein System fachlich besitzt, und der Operational Sponsor, der im Alltag für dessen Betrieb geradesteht. Beide Rollen gehören in das Agent-Inventory weiter unten, damit sie nicht nur in einem Organigramm, sondern für jeden einzelnen Agenten dokumentiert sind.

Der Authority Graph: wer über wen delegiert

Machine Authority Management beantwortet, wie viel ein einzelner Agent darf. Es beantwortet nicht, wie diese Berechtigung durch ein Netz von Agenten fließt, die sich gegenseitig aufrufen. Dafür eignet sich eine zusätzliche Darstellung, die wir Authority Graph nennen – ebenfalls ein redaktioneller Arbeitsbegriff, keine etablierte Branchennorm: eine Darstellung, in der jeder Agent ein Knoten ist und jede Delegation eine gerichtete Kante, versehen mit der Autorität, die dabei übertragen wird, und dem Zeitpunkt, zu dem sie wieder verfällt.

Ein solcher Graph macht sichtbar, was ein einzelnes Rechteprofil verschweigt: Ein Agent kann formal wenig Autorität besitzen und trotzdem gefährlich sein, wenn er drei andere Agenten aufrufen darf, die zusammen deutlich mehr dürfen als er selbst. Ohne den Graphen bleibt diese Kettenwirkung unsichtbar, bis ein Vorfall sie unter Zeitdruck aufdeckt – genau die Situation, die eine gestufte Reaktion auf einen Sicherheitsvorfall erschwert, weil niemand auf Anhieb weiß, welche Kante zuerst zu kappen ist. Wer den Graphen dagegen vorab pflegt, kann bei einem Verdacht gezielt eine einzelne Kante trennen, statt gleich einen ganzen Agenten oder mehrere zugleich stillzulegen.

Der Stand bei NIST: ein Konzeptpapier, kein Standard

Dass Agentenidentität gerade zum eigenen Forschungsfeld wird, zeigt sich auch daran, dass NIST über den zitierten Fachbeitrag hinaus ein eigenes Projekt dazu führt. Wörtlich heißt es zu diesem Vorhaben: „The NCCoE is interested in exploring standards-based approaches to identify, manage, and authorize access and actions taken by software agents, including AI agents.“ Entscheidend ist, wie weit dieses Vorhaben bereits gediehen ist – und wie weit nicht.

Zum Stand vom 26. September 2026 zeigt die Projektseite den Status „Reviewing Comments“ zum zugehörigen Konzeptpapier; die Kommentarfrist ist damit bereits geschlossen. Das zugehörige NIST-NCCoE-Projekt befindet sich noch im Stadium eines Konzeptpapiers mit geschlossener Kommentarfrist – kein bereits verabschiedeter Standard. Für Ihre eigene Planung heißt das: Sie können sich an der Richtung orientieren, die NIST hier einschlägt – getrennte Identitäten, kurzlebige Tokens, Vorsicht bei zu häufigen Freigaben –, aber Sie warten vergeblich auf eine fertige Norm, die sich einfach implementieren ließe. Wer jetzt beginnt, baut auf Prinzipien, nicht auf einem abgeschlossenen Regelwerk.

Das Agent-Inventory: 11 Punkte für den eigenen Bestand

Bevor sich Autorität sinnvoll begrenzen lässt, muss feststehen, welche Agenten überhaupt existieren – eine Frage, die in vielen Unternehmen erstaunlich schwer zu beantworten ist, weil einzelne Teams eigene Agenten ohne zentrale Meldung produktiv setzen. Ein Agent-Inventory mit 11 Punkten schafft dafür die nötige Übersicht. Dieses Agent-Inventory ist ein redaktioneller Vorschlag zur Selbstprüfung, keine regulatorische Pflicht: Es ersetzt keine Vorgabe aus einer Norm, sondern gibt eine Struktur vor, mit der Sie den eigenen Bestand systematisch aufnehmen können.

Die letzte Zeile der Tabelle – die Reifegradstufe – trägt ein, wo ein Agent auf einem eigenen, redaktionellen 5-Stufen-Modell (keine NIST-Norm) aktuell steht, nicht wo er stehen sollte: von Stufe 1 (Agentenkonto wie ein gewöhnliches Nutzerkonto, nicht separat erfasst) über Stufe 3 (Least Authority durchgesetzt, Owner und Operational Sponsor benannt, Tokens kurzlebig – der realistische erste Zielwert für die meisten Organisationen) bis Stufe 5 (ein dynamisches Delegationsbudget begrenzt Autorität fortlaufend). Genau dieser Unterschied macht das Inventory zu einem Werkzeug für die laufende Steuerung statt zu einer einmaligen Übung.

Was Recht heute schon verlangt – und was offen bleibt

Für die Beschaffung und den Betrieb von Agenten mit Werkzeugzugriff wirken mehrere Rechtsrahmen als Randbedingung, nicht als eigener Pflichtenkatalog. Steuert ein Agent unmittelbar eine Maschine, greift die EU-Maschinenverordnung 2023/1230, die grundsätzlich ab dem 20.01.2027 gilt; wo ein Agent Zugriffsrechte in einem cyberphysischen System verändert, ist diese Frist schon jetzt eine Planungsgröße für die Beschaffung. Ob ein Agent mit eigenständigem Werkzeugzugriff nach dem EU AI Act zusätzlich als Hochrisikosystem einzuordnen ist, hängt vom konkreten Einsatzzweck ab und lässt sich nicht pauschal beantworten.

Verarbeitet ein Agent besondere Kategorien personenbezogener Daten, greift Art. 9 DSGVO; löst sein Einsatz ein hohes Risiko für Betroffene aus, kommt eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO hinzu. Für Software mit digitalen Elementen, zu der auch ein Agent mit Werkzeugzugriff zählt, wirkt zudem der Cyber Resilience Act 2024/2847 auf Hersteller und teilweise auf Betreiber. Diese Einordnung ersetzt keine individuelle IT-Sicherheits- oder Rechtsberatung für die eigene Agenten-Governance; welche dieser Rahmen im konkreten Fall greifen, sollten Sie mit Ihrer Rechtsabteilung klären.

Wo das Modell an Grenzen stößt

Machine Authority Management, Authority Graph und das Reifegradmodell lösen ein reales Problem, sind aber selbst keine fertige Lösung von der Stange. Es gibt derzeit kein etabliertes Werkzeug, das einen Authority Graph automatisch aus bestehenden Systemen aufbaut; wer ihn heute pflegen will, tut das größtenteils händisch oder mit selbstgebauten Skripten, was bei wenigen Agenten funktioniert und bei Hunderten an seine Grenzen stößt.

Kurzlebige Tokens und sparsame Freigaben verlangen außerdem eine Softwarelandschaft, die das technisch unterstützt. Viele ältere Systeme kennen nur statische Schlüssel und lassen sich nicht ohne Weiteres umstellen, sodass Übergangslösungen mit gemischtem Sicherheitsniveau entstehen, obwohl das eigentliche Ziel eine einheitliche Autoritätsverwaltung wäre. Und selbst ein vollständiges Inventory verhindert keinen Fehler in der Klassifizierung: Wird die maximale Authority eines Agenten zu großzügig eingetragen, weil niemand die tatsächliche Nutzung genau kennt, dokumentiert die Tabelle nur ein Risiko, ohne es zu verkleinern.

Was jetzt zu tun ist

Der pragmatische Einstieg beginnt nicht mit einem fertigen Graphen, sondern mit der einfachen Frage, wie viele Agenten mit Werkzeugzugriff in Ihrem Unternehmen bereits laufen – häufig mehr, als eine erste Schätzung vermuten lässt. Aus dieser Bestandsaufnahme entsteht das Inventory, aus dem Inventory die erste ehrliche Einstufung nach dem Reifegradmodell, und erst danach lohnt sich die Investition in einen gepflegten Authority Graph.

Wer diese Schritte nicht nur einmal, sondern als strukturierten Prozess mit Kontrollkatalog und Formularvorlagen aufsetzen will, findet dafür einen eigenen Fachleitfaden zu KI-Agenten, Identität und Kontrollarchitektur — im kostenlosen Downloadbereich dieser Redaktion.

Was am Ende zählt, ist kein einzelnes Werkzeug, sondern eine Gewohnheit: Bevor ein Agent produktiv geschaltet wird, steht fest, wer ihn verantwortet, was er höchstens darf, und über welchen Weg sich seine Autorität sofort entziehen lässt. Diese drei Antworten sind kein Formular für die Akte, sondern die Voraussetzung dafür, dass Sie im Ernstfall reagieren können, statt erst zu suchen, wer eigentlich zuständig ist.