Geführtes Sicherheitslab

Agentenautorisierung

Eine geführte Übung zur Autorisierung konkreter Agentenaktionen: Authentifizierung von Autorisierung trennen, die exakte Anfrage an initiierenden Principal und delegierten Scope binden, geänderte Parameter neu autorisieren und verhindern, dass Delegation über Hops Autorität ausweitet.

Konzeptionelle SimulationAdvanced15 Minuten2026-09-26

Konzeptionelle Simulation

Diese Übung nutzt redaktionell festgelegte, deterministische Beispiele mit fiktiven Namen und neutralen synthetischen Inhalten. Sie ruft keine Tools, APIs, Identitätsanbieter, Agenten oder Modelle auf und sagt nicht voraus, wie sich ein reales Modell verhält.

Schritt 3 von 63/6

Lernziele

Authentifizierung von Autorisierung trennen.
Die Identität des handelnden Agenten vom initiierenden Principal und vom delegierten Nutzer- oder Aufgaben-Scope unterscheiden.
Die angefragte Aktion und die Parameter des Modells als Vorschlag behandeln, nicht als Autorisierungsfakten.
Eine exakte Anfrage anhand der von der Anwendung erfassten Policy-Fakten bewerten.
Erkennen, wann eine breite Fähigkeit, ein registriertes Tool, ein gültiges Credential oder eine frühere Erlaubnis für die vorgeschlagene Anfrage nicht ausreicht.
Neu autorisieren, wenn sich ausführungsrelevante Parameter, Ressourcen oder Ziele wesentlich ändern.
Ausweitung von Autorität über Agenten- und Tool-Hops verhindern.
Autorisierungsentscheidungen von getrennten Kontrollen für Informationsfluss, Ausgabevalidierung und menschliche Freigabe unterscheiden.

Voraussetzungen

Lab Tool-Output-Injection (empfohlen)
Lab Vertrauensgrenzen und Modellkontext (empfohlen)

Szenario wählen

Jedes fiktive Szenario zeigt, was das Modell sieht, und getrennt davon die Identitäts-, Delegations-, Berechtigungs-, ACL- und Freigabefakten der Anwendung. Autorisierungsentscheidungen gehören zu den Fakten der Anwendung.

Authentifiziert, aber außerhalb des ScopesEine angemeldete Support-Mitarbeiterin bittet den Agenten, einen synthetischen Fall zusammenzufassen. Der Agent ist authentifiziert und sieht ein Fallverwaltungs-Tool, schlägt aber vor, einen anderen Kundendatensatz außerhalb des delegierten Fall-Scopes zu ändern.Exakte Aktion innerhalb der DelegationDer angemeldete Nutzer darf den Status eines synthetischen Tickets ändern, der Agenten-Workload darf diese Operation in seinem Auftrag ausführen, und exaktes Ticket sowie neuer Statuswert liegen im Aufgaben-Scope. Keine separate Flussbeschränkung greift.Vom Modell verfasste FreigabebehauptungDie vorgeschlagene Aktion des Modells enthält einen Hinweis, der Nutzer habe eine folgenreiche Änderung bereits freigegeben. Der Freigabe- und Berechtigungsspeicher der Anwendung enthält keinen solchen Eintrag für diese Anfrage.Parameter nach einer Erlaubnis geändertEin Versandentwurf an einen erlaubten synthetischen Empfänger wurde zuvor autorisiert. Vor der Ausführung ändert sich das Ziel auf eine andere Adresse, und das Modell schlägt vor, die geänderte Anfrage ohne neue Entscheidung auszuführen.Begrenzte Delegation je HopEin übergeordneter Agent delegiert eine lesende Teilaufgabe an einen Sub-Agenten. Die Anwendung erfasst initiierenden Principal, übergeordnete Aufgabe und eine echte Teilmengen-Delegation auf eine erlaubte Ressource. Der Sub-Agent schlägt nur diesen Lesezugriff vor.

Pfad der Aktionsanfrage und Vertrauensfluss

Eine Anfrage wird authentifiziert, das Modell schlägt eine Aktion vor, ein Policy Decision Point bewertet die exakte Anfrage und das Ziel-Tool setzt sie durch. Identität, Policy und Durchsetzung sind Systemkomponenten; Anfragen und Vorschläge bleiben variabel.

Anfrage der angemeldeten NutzerinVariabler Inhalt->
Identitätsanbieter (Authentifizierung)Systemkomponente->
ModellSystemkomponente->
Vorgeschlagener Tool-AufrufVariabler Inhalt->
Policy Decision PointSystemkomponente->
Durchsetzung im Fall-ToolSystemkomponente

Modellsichtbarer Anfrageinhalt

Was das Modell liest. Es enthält keine Autorisierungsfakten.

Anfrage der Nutzerin
Bitte fasse Fall K-310 zusammen.
Verfügbare Tools
case-management: read_case, update_record

Anwendungsseitige Autorisierungsfakten

Erfasst von Identitätsanbieter, Delegationsdienst, Berechtigungs- und Freigabespeicher, ACL und Ziel-Policy außerhalb des Modelltexts.

Initiierender Principal: support-user-ana (authentifizierte Sitzung)
Identität des handelnden Agenten: Agenten-Workload support-assistant, am Fall-Tool authentifiziert
Delegierter Scope: Fall K-310 im Auftrag von support-user-ana lesen
Angefragte Ressource und Operation: update_record auf Kundendatensatz R-588, nicht Teil von Fall K-310
Berechtigungsstatus: Keine Berechtigung für support-user-ana oder diese Aufgabe, R-588 zu ändern