Agentenautorisierung

Sicherheitsziel

Agentenautorisierung ist die Kontrolle, die über eine einzelne, vollständig aufgelöste Aktionsanfrage entscheidet. Sie beantwortet an einer Stelle eine Frage: Wer fragt, in wessen Autorität, um genau was zu tun, an welcher Ressource, mit welchen Parametern, an welches Ziel oder Publikum, in welchem Mandanten- oder Workspace-Scope, für welche Aufgabe, zu welchem Zeitpunkt und unter welcher Policy-Version.

Diese Kontrolle wiegt in KI-Systemen deshalb so schwer, weil die Sprachinterpretation eines Modells probabilistisch ist, die Folgen einer Aktion aber nicht. Alle auf dieser Seite dokumentierten Angriffsmuster laufen am selben Punkt zusammen: Das Modell kann beeinflusst werden, und ob daraus eine Sicherheitsauswirkung wird, entscheidet sich außerhalb des Modells. AI-Agent-Prompt-Injection, Ausbreitung über mehrere Agenten und Tool Output Injection enden alle dort.

Diese Seite ist die Referenz für diese Kontrolle. Sie ist kein allgemeiner IAM-Leitfaden und wiederholt bewusst nicht, was zu Least Privilege, menschlicher Freigabe oder Informationsflusskontrolle gehört.

Authentifizierung ist keine Autorisierung

Zu wissen, welcher Nutzer, Agent oder welches Tool eine Anfrage gesendet hat, belegt eine Identitätsaussage. Es belegt keine Erlaubnis für den angefragten Vorgang. In agentischen Systemen geht diese Unterscheidung leicht verloren, weil ein Aufruf über einen authentifizierten Kanal von einer Komponente desselben Deployments kommt und die empfangende Seite Zugehörigkeit als Erlaubnis behandelt.

Modellentscheidung ist keine Autorisierungsentscheidung

Ein Modell kann Text erzeugen, der wie ein Autorisierungsergebnis aussieht. Es kann behaupten, ein Nutzer habe etwas freigegeben, eine Policy erlaube eine Aktion, ein Empfänger sei intern oder eine Datei sei nicht sensibel. Nichts davon ist eine Autorisierungsentscheidung, es ist generierter Inhalt über Autorisierung.

Die praktische Regel ist eng und strikt: Ein sicherheitsrelevanter Fakt, der aus Modellausgabe stammt, ist eine Eingabe für die Validierung, niemals eine Eingabe für die Erlaubnisentscheidung.

Der Lernartikel AI Agents und Tool Calling führt diese Trennung von Vorschlag und Entscheidung im gesamten Agenten-Kreislauf ein.

Agentenidentität ist nicht der initiierende Principal

Bei fast jeder Agentenaktion sind zwei Identitäten beteiligt, und sie zusammenzuziehen ist einer der folgenreichsten Modellierungsfehler in diesem Bereich. Die handelnde Agenten- oder Workload-Identität ist die ausführende Laufzeit. Der initiierende Principal ist der Mensch, Dienst oder Workload, dessen Aufgabe die Aktion überhaupt ausgelöst hat.

Die Zero-Trust-Leitlinie von Microsoft zu Least Privilege für KI-Agenten, ausdrücklich Herstellerdokumentation, beschreibt eigene, unterscheidbare Identitäten für Agenten und die Bindung ihrer Berechtigungen an die Aufgabe und an den Nutzer, für den sie handeln, statt an geteilte oder stehende Zugangsdaten. Der architektonische Punkt gilt allgemein: Beide Identitäten erfassen und die delegierte Autorität eines Nutzers niemals stillschweigend in stehende Autorität des Agenten umwandeln.

Was eine Autorisierungsentscheidung binden muss

Eine Entscheidung ist nur so präzise wie die Fakten, die sie bindet. Ein brauchbares Minimum für agentische Aktionen ist die folgende Menge, vor der Bewertung aufgelöst und mit der Entscheidung protokolliert.

Wo Entscheidung und Durchsetzung liegen

Zwei Komponenten lohnen die Trennung auch in kleinen Systemen. Der Decision Point bewertet eine aufgelöste Anfrage gegen Policy und liefert eine Entscheidung mit Begründung. Der Enforcement Point liegt auf dem Ausführungspfad und führt den Vorgang ohne Allow-Entscheidung für genau diese Anfrage nicht aus.

Der Ablauf ist linear, das Vertrauensmodell ist es nicht. Nutzeraufgabe und vorgeschlagene Aktion sind Anfrageinhalt und bleiben variabel; sie sagen, was gewünscht ist, nie, was erlaubt ist. Resolver, Decision Point und Enforcement Point sind Systemkomponenten, und die Identitäts-, Session-, Delegations- und Policy-Fakten, die sie verwenden, werden außerhalb des Prompts aus vertrauenswürdigen Quellen aufgelöst. Eine Systemkomponente macht die von ihr verarbeiteten Inhalte nicht vertrauenswürdig, und die nachgelagerte Ressource liefert Daten und Ergebnisse mit eigenem Vertrauensstatus, die selbst extern beeinflusst sein können.

Die Entscheidung sollte so nah wie praktikabel an der folgenreichen Aktion liegen, damit die bewertete Anfrage auch die ausgeführte Anfrage ist.

Eine Prüfung im Orchestrator garantiert keine nachgelagerte Durchsetzung

Eine Autorisierungsprüfung im Orchestrator schützt den Ausführungspfad des Orchestrators. Sie begrenzt nicht, was das Zielsystem von einem Credential akzeptiert, das es auf anderem Weg erreicht. Wo das Zielsystem der eigentliche Enforcement Point ist, muss die Aktion auch dort autorisiert werden.

Verfügbarkeit einer Fähigkeit ist keine Erlaubnis

Tool-Discovery beantwortet, was der Agent sehen kann. Autorisierung beantwortet, ob diese Aufgabe es nutzen darf. Systeme vermischen beides häufig, indem ein registriertes Tool jeder Session angeboten und Registrierung als Einwilligung behandelt wird.

Die Menge der überhaupt angebotenen Tools zu reduzieren ist wertvoll, gehört aber zu Least Privilege. Die Autorisierung muss jeden Aufruf weiterhin einzeln bewerten.

Tokenbesitz ist keine universelle Autorität

Tokens transportieren häufig delegierte Autorität und werden häufig überinterpretiert. Ein Token belegt, was der Aussteller für welches Publikum, mit welchen Scopes oder Rollen und für welche Dauer zugesichert hat. Es ist keine allgemeine Erlaubnis, überall im Namen des Inhabers zu handeln.

RFC 8707, Resource Indicators for OAuth 2.0, wird hier eng verwendet: Der Standard definiert, wie ein Client bei der Tokenanforderung die konkret angestrebte geschützte Ressource signalisiert, was die Ausstellung von Tokens mit passender Publikumsbindung unterstützt. Das ist ein nützlicher Mechanismus gegen breit gültige Tokens. Es ist keine Aussage, dass OAuth für Agentenautorisierung erforderlich wäre oder dass ein Token-Mechanismus Agentensicherheit allein löst.

Delegation ist keine unbegrenzte Identitätsübernahme

Handelt ein Agent für einen Nutzer, ist Delegation mit erhaltenem Kontext das brauchbare Modell, nicht Identitätsübernahme. Delegation erfasst, wer delegiert hat, was delegiert wurde, für welche Aufgabe, Ressource und Aktion und für wie lange. Identitätsübernahme verwirft das und hinterlässt eine Anfrage, die von direktem Nutzerhandeln nicht unterscheidbar ist.

Ein häufiger Fehler ist die stille Hochstufung: Eine Aufgabe startet unter delegierter Nutzerautorität, stößt auf eine Berechtigungslücke und fällt auf das breitere Dienst-Credential zurück. Dieser Rückfall sollte eine ausdrückliche, policy-gesteuerte Entscheidung sein, kein impliziter Wiederholungsversuch.

Autorisierungskontext darf nicht vom Modell verfasst sein

Die Fakten, von denen eine Entscheidung abhängt, müssen aus einer vertrauenswürdigen Quelle stammen. In agentischen Systemen liegt die Abkürzung nahe, das Modell sie zusammenstellen zu lassen, weil es sie ohnehin als Text im Kontext hat.

Muss ein Wert im Modell entstehen, weil nur das Modell kennt, was der Nutzer wollte, gilt er als Vorschlag: gegen eine autoritative Quelle aufgelöst, validiert und dann autorisiert. Auflösung und Validierung sind nicht dasselbe wie Vertrauen.

Exact-Action-Autorisierung

Exact-Action-Autorisierung heißt, dass die Entscheidung fällt, nachdem die Parameter konkret sind, und zwar über die Anfrage, die tatsächlich ausgeführt wird. Eine breite Erlaubnis, E-Mails zu senden, sollte keine beliebige Kombination aus Empfänger, Anhang, Text und Datenquelle autorisieren.

Veraltete Autorisierung und Time-of-Check-Lücken

Ein zu einem Zeitpunkt freigegebener Plan kann gegen andere Fakten ausgeführt werden. Das Ziel kann sich anders auflösen, ein Parameter kann durch einen späteren Schritt überschrieben werden, die Klassifikation eines Anhangs kann sich ändern, die Delegation kann abgelaufen sein oder die Policy kann aktualisiert worden sein.

Hat sich ein ausführungsrelevanter Fakt wesentlich geändert, ist die korrekte Reaktion, die Ausführungsanfrage erneut zu autorisieren, statt sich auf die frühere Entscheidung über den Plan zu stützen.

Confused Deputy an Privilegiengrenzen

Eine höher privilegierte Komponente, die tätig wird, weil der Aufrufer authentifiziert ist, ist ein Confused Deputy. Die Identität des Aufrufers steht fest; die Frage, ob dessen delegierter Scope den angefragten Vorgang abdeckt, wurde nicht gestellt.

Jede Privilegiengrenze im System braucht diese Prüfung, auch interne Grenzen, die wie Implementierungsdetails wirken.

Autorisierung pro Hop in Multi-Agent-Systemen

Delegation über Agenten hinweg darf Autorität nicht verstärken. Ein nachgelagerter Agent sollte höchstens die für seine Teilaufgabe nötige Teilmenge erhalten, und jeder Hop sollte einen eigenständig durchsetzbaren Scope haben statt eines per Konvention geerbten.

1. 01
   Begrenzte Teilmenge pro Hop

   Der an einen nachgelagerten Agenten übergebene Scope ist eine Teilmenge des vorgelagerten Scopes, abgeleitet aus der Teilaufgabe statt vollständig kopiert.

2. 02
   Erhaltener initiierender Principal

   Principal und Aufgabe reisen in überprüfbarer Form mit der Delegation, nicht als Fließtext in einer Nachricht.

3. 03
   Eigenständige Durchsetzung

   Jeder Hop autorisiert die empfangene Anfrage; kein Hop behandelt ein vorgelagertes Allow als ausreichend für die eigene Aktion.

4. 04
   Keine erneute Ausweitung

   Eine nachgelagerte Komponente kann keine breitere Berechtigung anfordern als die empfangene Delegation, und Versuche werden abgelehnt und protokolliert.

Die Angriffssicht darauf, was ohne diese Kontrolle passiert, steht in Multi-Agent-Prompt-Injection; diese Seite ist die Kontrollreferenz, nicht die Bedrohungsbeschreibung.

Menschliche Freigabe ist eine Schicht, kein Basismodell

Menschliche Freigabe ist für ausgewählte folgenreiche Aktionen wertvoll und ein schlechter Ersatz für ein Autorisierungsmodell. Fehlt die Basisentscheidung, wird die Freigabe zum einzigen Gate, und sie ist das Gate, das sich durch Masse am leichtesten abnutzt.

Eine Freigabe, die etwas wert ist, ist konkret und informiert: Sie nennt Ressource, Parameter und Ziel, die verwendet werden. Freigabe-UX, Qualität der Einwilligung und Ermüdung gehören zur Human-in-the-Loop-Kontrolle, nicht auf diese Seite.

Abgrenzung zu benachbarten Kontrollen

Autorisierung ist eine von mehreren Kontrollen, die an der Aktionsgrenze zusammentreffen. Die Zuständigkeiten getrennt zu halten macht jede einzelne prüfbar.

Die Zusammensetzung auf Sequenzebene behandelt die Tool-Chain-Analyse; ein Kettenergebnis autorisiert keinen Aufruf vorab.

Deny by Default und Fail Closed

Fehlt ein sicherheitsrelevanter Fakt oder ist er mehrdeutig, ist die sichere Reaktion eine Ablehnung mit Begründungscode. Unsicher ist ein System, das den fehlenden Fakt aus modellgeneriertem Text ergänzen lässt, denn das macht aus einem Verfügbarkeitsproblem eine Umgehung der Autorisierung.

Jede dieser Bedingungen erzeugt eine sichtbare, zurechenbare und prüfbare Ablehnung, und genau das macht Deny-on-Missing-Context später messbar.

Widerruf und kurzlebige Autorität

Autorisierungsentscheidungen ergehen gegen einen veränderlichen Zustand. Zwei operative Eigenschaften zählen hier, beide bewusst knapp gehalten, weil der Lebenszyklus von Zugangsdaten allgemein zu Least Privilege und Identitätsverwaltung gehört.

Die Herstellerdokumentation von Microsoft zu Least Privilege für KI-Agenten behandelt bedarfsgerechte und zeitlich begrenzte Rechteerhöhung für Agentenidentitäten statt dauerhaft stehender Rechte. Für die Autorisierung ist der Punkt enger: Der Enforcement Point muss den aktuellen Zustand abfragen, damit ein Entzug bei der nächsten Entscheidung wirkt und nicht erst bei der nächsten Erneuerung eines Credentials.

Durchgespieltes Szenario: eine routinemäßige Lieferantenrechnung per E-Mail

Das Szenario ist synthetisch, begrenzt und umkehrbar. Es soll zeigen, dass Vorschlag, Autorisierung und Ausführung drei getrennte Sachverhalte sind, und keine Technik demonstrieren.

Was das Szenario belegt und was nicht

Ein einzelner eingegrenzter Durchlauf zeigt, dass ein Gate für eine Anfrage gehalten hat. Aussagen über Abdeckung erfordern die Messungen im Testabschnitt mit genannten Nennern.

Autorisierungstelemetrie

Autorisierungstelemetrie macht die Kontrolle untersuchbar. Das Minimum ist ein Eintrag pro Entscheidung, der Vorschlag, aufgelösten Kontext, Entscheidung und Ergebnis miteinander verbindet.

Werden diese zu einem Ereignis zusammengezogen, lässt sich ein blockierter Versuch nicht mehr von einer abgeschlossenen Aktion unterscheiden, und genau diese Unterscheidung braucht eine Untersuchung.

Tests und Metriken

Jede Kennzahl unten wird getrennt mit genanntem Nenner berichtet. Es gibt keinen zusammengesetzten Autorisierungswert, weil eine einzelne Zahl verbirgt, welche Eigenschaft versagt hat.

Revocation Enforcement Time wird als operative Latenz statt als Quote berichtet: die Zeit zwischen einem Entzug und dem ersten Enforcement Point, der die entzogene Autorität nicht mehr akzeptiert. Auch der Nutzen bei legitimen Aufgaben wird getrennt berichtet und nie in eine Sicherheitszahl eingerechnet, denn ein System, das alles ablehnt, erreicht bei jeder Blockquote den Bestwert.

Um diese Eigenschaften kontrolliert zu üben, ist das Lab Agentenautorisierung eine deterministische Simulation von Exact-Action-Autorisierung, Bindung an Principal und Delegation, Neuautorisierung nach wesentlichen Parameteränderungen und keiner Ausweitung je Hop.

Incident Response und häufige Fehler

Geht eine Agentenaktion schief, besteht die erste Aufgabe darin, zu bestimmen, welcher von vier Fehlern vorliegt, denn die Behebung unterscheidet sich vollständig.

Zur Quellennutzung: Die Microsoft-Seiten sind Hersteller- und Produktdokumentation und werden als solche gekennzeichnet; produktspezifisches Verhalten wird nicht über dieses Produkt hinaus verallgemeinert. Die OWASP Top 10 for Agentic Applications 2026 dienen als benachbartes Risikoframework für Identitäts- und Rechtemissbrauch, nicht als Autorisierungsstandard. RFC 8707 wird eng für ausdrückliche Ressourcenangabe und Publikumsbindung verwendet, ohne die Aussage, OAuth sei erforderlich oder ausreichend. NIST SP 800-207 wurde geprüft und bewusst weggelassen, weil seine Begriffe für Entscheidungs- und Durchsetzungspunkte über die hier bereits beschriebene Architektur hinaus keine zusätzliche Aussage stützen. Passendes Material zur Angriffsseite steht in der Angriffsbibliothek, etwa zu indirekter Prompt Injection und persistenter Prompt Injection.

Häufige Fragen