Least Privilege

Sicherheitsziel

Least Privilege ist die Kontrolle, die festlegt, wie viel Befugnis überhaupt existiert: welche Identitäten ein Agenten-Deployment besitzt, welche Rollen und Scopes diese Identitäten tragen, welche Ressourcen, Tools, Daten und Ziele über sie erreichbar sind und wie lange all das bestehen bleibt. NIST definiert Least Privilege als Gewährung nur der minimalen Zugriffsrechte, die zur Erfüllung der zugewiesenen Aufgaben erforderlich sind, und die Kontrolle AC-6 in NIST SP 800-53 Rev. 5 formuliert die allgemeine Anforderung im Kontrollkatalog. Beides ist nicht agentenspezifisch - und genau deshalb anwendbar: Es definiert die Eigenschaft, die jedes Agenten-Deployment erben sollte, keinen Agentenmechanismus.

Für KI-Agenten ist diese Eigenschaft überproportional wichtig, weil die Sprachinterpretation des Modells probabilistisch ist, die Befugnis dahinter jedoch nicht. Eine erfolgreiche Injektion, ein Abruffehler oder ein schlichtes Missverständnis erzeugt keine neuen Rechte. Es kann nur über Befugnisse wirken, die bereits existieren. Deren Reduktion ist die Kontrolle dieser Seite.

Identitäts- und Policy-Fakten werden out-of-band aus verlässlichen Quellen aufgelöst, und Umgebung, Reichweite und Scope sind systemseitig durchgesetzte Beschränkungen und kein modellgenerierter Text. Die Nutzeraufgabe bleibt variabler Inhalt, und eine Systemkomponente macht den Inhalt, den sie trägt, nicht vertrauenswürdig. Eine engere Umgebung verändert die maximale Auswirkung dessen, was der Agent versucht; sie verändert nicht, welche Anfrage erlaubt ist - das bleibt Aufgabe der Autorisierung zum Ausführungszeitpunkt.

Diese Seite ist bewusst kein allgemeiner IAM-Artikel. Jeder Abschnitt ist auf Agenten-Workflows, Modellbeeinflussung und Schadenausbreitung zugeschnitten.

Bedrohungsmodell: Beeinflussung wirkt über bestehende Befugnisse

Das Bedrohungsmodell ist einfach und dasselbe, auf das jeder Angriffsartikel dieser Seite hinausläuft: Das Modell kann durch verarbeitete Inhalte beeinflusst werden, und die Folgen dieser Beeinflussung werden durch die in diesem Moment verfügbare Befugnis bestimmt.

Least Privilege senkt nicht die Wahrscheinlichkeit von Beeinflussung. Es reduziert die Menge der Wirkungen, die Beeinflussung erreichen kann - eine andere und unabhängig prüfbare Eigenschaft. Die Angriffsperspektive dokumentieren AI-Agent-Prompt-Injection, Multi-Agent-Prompt-Injection und persistente Prompt Injection.

Stehende Befugnis vs. aufgabenbezogene Befugnis

Stehende Befugnis ist das, was eine Identität jederzeit kann, unabhängig von jeder Aufgabe. Aufgabenbezogene Befugnis ist das, was eine konkrete Aufgabe, Sitzung oder Delegation verfügbar macht - und nur für deren Dauer. Agenten-Deployments lassen typischerweise die erste wachsen und vernachlässigen die zweite, weil stehende Grants einfacher zu verdrahten sind.

Das Ziel ist nicht, stehende Befugnisse abzuschaffen - das ist selten möglich - sondern sie auf das zu verkleinern, was das Deployment wirklich immer braucht, und alles andere in begrenzte, aufgabenabgeleitete Grants zu verlagern.

Effektive Berechtigungen und aggregierte Befugnisse

Die Befugnis, die ein Agent tatsächlich hält, ist die Summe von allem, was an ihm hängt: direkte Rollen, Gruppenmitgliedschaften, Tool-Registrierungen, nachgelagerte Berechtigungen, die über seine Credentials erreichbar sind, und Integrationen, die in seinem Namen handeln. Die konfigurierte Rolle ist oft nur ein kleiner Teil dieser Summe.

Die Hersteller-Leitlinie von Microsoft zu Least Privilege für KI-Agenten, hier als Hersteller-Leitlinie gekennzeichnet, empfiehlt, die aggregierten beziehungsweise effektiven Berechtigungen von Agentenidentitäten zu prüfen statt nur der direkt zugewiesenen Rollen. Der Punkt verallgemeinert sich: Reviews effektiver Zugriffe, nicht Konfigurationsreviews, sind die Einheit der Absicherung.

Eigene Workload-Identität vs. geteilte Credentials

Ein Agent, der über ein geteiltes Credential handelt, erbt alles, was dieses Credential kann, und lässt keine Möglichkeit, seine Aktionen gesondert zuzuordnen. Eine eigene Workload-Identität ist die Voraussetzung für Scoping, Review und Widerruf auf Agentengranularität.

Die Zero-Trust-Leitlinie von Microsoft für KI-Agenten, ebenfalls Hersteller-Leitlinie, beschreibt dedizierte Agentenidentitäten, die an Aufgabe und Nutzer gebunden sind, statt geteilter oder stehender Credentials; die Begleitleitlinie behandelt verwaltete Identitäten und Workload-Verbund als Wege, Secrets gar nicht erst zu verteilen. Der architektonische Punkt hängt nicht am Hersteller: ein Agent, eine Identität, begrenzt auf die tatsächliche Arbeit dieses Agenten.

Trennung von Lese- und Schreibrechten

Die meisten Agentenaufgaben sind leselastig: abrufen, zusammenfassen, vergleichen, entwerfen. Wenn dieselbe Identität auch Schreib-, Sende-, Lösch- oder Kaufrechte trägt, trägt jede Leseaufgabe still Folgebefugnisse mit, die sie nicht braucht.

Die Lese-/Schreibtrennung ergänzt die Autorisierung, ersetzt sie aber nicht: Eine Read-only-Umgebung braucht weiterhin Autorisierung, um zu entscheiden, welche Lesevorgänge erlaubt sind, und ein Schreibschritt braucht vor der Ausführung eine Exact-Action-Prüfung.

Ressourcen-, Mandanten- und Workspace-Scoping

Scope beantwortet, wo die Befugnis einer Identität gilt. Je enger der Scope, desto kleiner die Menge der Objekte, die ein beeinflusster Agent berühren kann - unabhängig davon, welche Berechtigungen er innerhalb des Scopes hat.

Minimierung der Tool- und Aktions-Exposition

Jedes registrierte Tool erweitert den Aktionsraum, der dem Modell zur Verfügung steht. Die Minimierung der Tool-Exposition fragt, welche Tools eine Aufgabe tatsächlich braucht, und entfernt den Rest aus der Sitzung, sodass ein gesteuerter Plan eine Aktion, die das Deployment nie beabsichtigt hat, nicht einmal benennen kann.

Die Hersteller-Leitlinie von Microsoft empfiehlt, nicht geprüfte Tools, Integrationen und mandantenübergreifende Pfade standardmäßig abzulehnen, statt alles zu registrieren, was eines Tages nützlich sein könnte. Zwei Grenzen gelten hier. Erstens ist Exposition Reichweite, keine Erlaubnis: Ein nicht verfügbares Tool reduziert, was versucht werden kann, während die Autorisierung entscheidet, ob ein verfügbarer Aufruf laufen darf. Zweitens schlägt Exposition pro Aufgabe die Exposition pro Deployment: Der sichere Standard ist die kleinste Tool-Menge, die die aktuelle Aufgabenklasse erfordert.

Minimierung des Datenzugriffs

Datenzugriff ist die Eingabeseite der Befugnis. Ein Agent, der nur einen Workspace lesen kann, kann Inhalte außerhalb weder offenlegen noch verändern noch sich von ihnen steuern lassen, und ein Agent, der ein Secret nie sieht, kann es nicht preisgeben.

Die Grenze zur Informationsflusskontrolle ist wichtig: Dieser Abschnitt entscheidet, welche Daten der Agent überhaupt erreichen kann; die Informationsflusskontrolle entscheidet, ob erreichte Daten zu einem bestimmten Ziel gelangen dürfen. Beides wird benötigt, und beide versagen unabhängig voneinander.

Ausgehende und Netzwerk-Reichweite

Die ausgehende Reichweite bestimmt, mit welchen Zielen die Tools eines Agenten überhaupt sprechen können: welche Hosts, welche Protokolle, welche externen Dienste. Ihre Reduktion verkleinert die Menge der Orte, an die beeinflusstes Verhalten etwas senden könnte.

Die Grenze zur Egress-Kontrolle ist explizit: Diese Seite behandelt die Reduktion der Reichweite - dass ein Pfad zu den meisten Zielen gar nicht existiert. Welche Ziele, Protokolle und Ports ein erlaubter Pfad erreichen darf, entscheiden Netzwerk- und Egress-Beschränkungen; ob bestimmte Daten ihn überqueren dürfen, entscheidet die Informationsflusskontrolle. Ein Agent ohne Pfad zu externen Hosts kann über sie nichts exfiltrieren, aber ein Agent mit Pfad braucht weiterhin eine Flussrichtlinie dafür, was ihn überqueren darf.

Just-in-Time- und zeitgebundene Erhöhung

Manche Aufgaben brauchen wirklich mehr Befugnis als die tägliche Grundlinie: eine Migration, ein einmaliger Export, ein administrativer Eingriff. Die Least-Privilege-Antwort ist eine Erhöhung, die für einen Zweck angefordert, für ein begrenztes Fenster gewährt und automatisch zurückgenommen wird - statt einer dauerhaft breiteren Umgebung.

Die Hersteller-Leitlinie von Microsoft beschreibt Just-in-Time- und zeitgebundene Befugnisse für Agentenidentitäten, und die Begleitleitlinie behandelt Privileged-Access-Management für Erhöhungsworkflows. Das Prinzip ist älter als jedes Produkt: Die stehende Umgebung klein halten und jede Ausnahme temporär, explizit und prüfbar machen.

Credential-Lebensdauer vs. Befugnis-Lebensdauer

Auf jedem Grant laufen zwei Uhren, und ihre Verwechslung erzeugt stille Überprivilegierung. Die Credential-Lebensdauer ist, wie lange das Secret oder Token technisch gültig bleibt. Die Befugnis-Lebensdauer ist, wie lange der Grant dahinter überhaupt existieren sollte. Ein kurzlebiges Token auf einer dauerhaft breiten Rolle bleibt dauerhaft breite Befugnis - nur fortlaufend neu ausgestellt.

Die Hersteller-Leitlinie von Microsoft behandelt kurzlebige Tokens und verwaltete Identitäten zur Verkürzung der Credential-Lebensdauer; die ergänzende Disziplin für die Befugnis-Lebensdauer ist Ownership und Review, behandelt im Lebenszyklus-Abschnitt weiter unten.

Delegierte Befugnis vs. Workload-Befugnis

Ein Agent hält meist Befugnisse zweier verschiedener Arten. Delegierte Befugnis ist eine begrenzte Teilmenge der Rechte eines Nutzers, dem Agenten für eine Aufgabe übergeben. Workload-Befugnis ist das, was der Dienst selbst darf, unabhängig von jedem Nutzer.

Wie eine konkrete Anfrage unter beiden Quellen bewertet wird - einschließlich der Erhaltung des initiierenden Principals - gehört zur Agentenautorisierung.

Mandantenübergreifende, Gast- und Integrationspfade

Befugnisse enden selten an der Mandantengrenze. Gast-Einladungen, Verbundzugriff, Marketplace-Integrationen und Automatisierungsplattformen können die effektive Reichweite einer Identität jeweils in andere Mandanten tragen oder durch eine zweite Tür zurück in den eigenen.

Die referenzierte Hersteller-Leitlinie empfiehlt, nicht geprüfte mandantenübergreifende Pfade standardmäßig abzulehnen. Die allgemeine Regel ist dieselbe wie bei Tools: Ein Pfad, der nicht erfasst und geprüft wurde, sollte für den Agenten nicht existieren.

Berechtigungsvererbung und transitive Reichweite

Effektive Berechtigungen sind transitiv. Eine Rolle impliziert Scopes, eine Gruppe impliziert Rollen, ein Credential impliziert nachgelagerte Berechtigungen, und eine Integration impliziert alles, was ihre eigenen Credentials können. Jeder Schritt ist lokal plausibel; die Komposition ist es, die zählt.

Transitive Reichweite ist der Grund, warum Reviews effektiver Berechtigungen Credentials und Konnektoren folgen müssen statt bei Rollenzuweisungen zu stoppen - und warum eine neue Integration eine Befugnisänderung ist, kein Feature-Change.

Permission Creep, veraltete Grants und Ownership

Grants sammeln sich an, weil Hinzufügen leicht und Entfernen beängstigend ist. Aufgaben enden, Prototypen werden Produktivsysteme, Teammitglieder wechseln, und die Umgebung des Agenten behält jedes Recht, das es je brauchte. Veraltete Grants sind stehende Befugnis ohne aktuelle Begründung - reine Angriffsfläche.

Die Hersteller-Leitlinie von Microsoft empfiehlt, Agentenberechtigungen erneut zu prüfen, wenn sich Workflows, Tools oder Datenumfang ändern. Access-Review-Werkzeuge können den Rhythmus automatisieren; die Beurteilung, was der Agent noch braucht, können sie nicht liefern.

Break-Glass und betriebliche Ausnahmen

Der Betrieb braucht manchmal Befugnisse außerhalb der normalen Umgebung: ein Vorfall, eine Wiederherstellung, ein dringender Fix. Die Least-Privilege-Antwort ist nicht, die stehende Umgebung für diese Fälle zu verbreitern, sondern einen engen, überwachten Ausnahmepfad zu definieren.

Abgrenzung zur Agentenautorisierung und anderen Kontrollen

Der wichtigste Satz dieser Seite: Least Privilege entscheidet, wie viel Befugnis existiert; die Agentenautorisierung entscheidet, ob eine konkrete Anfrage sie nutzen darf. Ein Least-Privilege-System kann innerhalb seiner Umgebung trotzdem eine schlechte Anfrage autorisieren, und eine perfekte Autorisierungsschicht über einer riesigen Umgebung lässt einen riesigen Schadensradius, falls diese Schicht versagt.

Deny by Default für ungeprüfte Fähigkeiten

Deny by Default hat auf dieser Seite eine konkrete Bedeutung: Eine Fähigkeit - ein Tool, eine Integration, ein Scope, ein mandantenübergreifender Pfad, ein Ziel - die nicht erfasst, bewertet und freigegeben wurde, steht dem Agenten nicht zur Verfügung. Verfügbarkeit ist das Ergebnis eines Reviews, nicht der Ausgangspunkt.

Das ist eine Provisionierungsdisziplin und ergänzt das anfragezeitliche Deny by Default der Agentenautorisierung: Die eine regelt, was existiert, die andere regelt, was läuft.

Praxisbeispiel: Gleiche Beeinflussung, zwei Befugnisumgebungen

Das Beispiel ist synthetisch, begrenzt und nicht operativ. Es soll zeigen, dass identische Modellbeeinflussung unter verschiedenen Befugniskonfigurationen verschiedene Folgen erzeugt. Es demonstriert keine Technik.

Was das Beispiel beweist - und was nicht

Ein Praxisbeispiel zeigt einen Mechanismus, keine Abdeckung. Die Absicherung kommt aus Inventar, Review und Messung in den nächsten beiden Abschnitten.

Telemetrie, Inventar und Review effektiver Zugriffe

Least Privilege wird gepflegt, nicht installiert. Die betriebliche Grundlage ist ein aktuelles Inventar von Identitäten, Grants, Tools, Credentials und Integrationen, plus Telemetrie, die zeigt, was davon tatsächlich genutzt wird.

Tests und Metriken

Jede Kennzahl wird separat mit angegebenem Nenner berichtet. Es gibt keinen zusammengesetzten Least-Privilege-Score, weil eine einzelne Zahl verdeckt, welche Dimension sich verschlechtert hat.

Der Erfolg gutartiger Aufgaben wird separat als Nutzen berichtet und nie in eine Sicherheitszahl gefaltet: Ein Deployment, dessen Agenten nichts können, erreicht bei jeder Befugniskennzahl die Bestnote. Kontrollierte Tests - simulierte Beeinflussung gegen repräsentative Aufgaben - messen, ob die Umgebung und nicht das Modell die Folge verhindert hat.

Zum Üben der Bewertung von Berechtigungsrahmen eignet sich das Lab Least Privilege.

Incident Response und typische Fehler

Nach einem Beeinflussungsereignis oder einer unbefugten Aktion sind die Least-Privilege-Fragen Fragen der Reichweite: Was konnte die betroffene Identität berühren, was hat sie berührt, und was muss schrumpfen, damit das nächste Ereignis kleiner wird.

Zur Quellennutzung: Die NIST-Definition und AC-6 sind allgemeine, maßgebliche Leitlinien und nicht agentenspezifisch; sie werden für das Prinzip genutzt, nicht für Agentenaussagen. Die Microsoft-Seiten sind Hersteller-Leitlinien und als solche gekennzeichnet; produktspezifisches Verhalten wird nicht verallgemeinert. OWASP ASI03 wird als benachbarter Risikorahmen für Identitäts- und Privilegienmissbrauch zitiert, nicht als Least-Privilege-Standard. Auf dieser Seite werden keine Statistiken oder Benchmark-Zahlen behauptet. Das anfrageseitige Gegenstück dieser Kontrolle ist unter Agentenautorisierung dokumentiert, und die angriffsseitige Motivation liegt in der Angriffsbibliothek.

Häufige Fragen