Least-Privilege ist eines der ältesten und verlässlichsten Konzepte der Sicherheit. Geben Sie einer Identität genau die Zugriffe, die sie braucht, nicht mehr, und der Schadensradius einer Kompromittierung bleibt klein. Für menschliche Konten und langlebige Service-Accounts hält das Modell recht gut stand: Rollen werden geprüft, Berechtigungen werden eng gefasst, Zugriffszertifizierungen laufen im Quartalsrhythmus.
KI-Agenten brechen dieses Modell leise auf. Ein Agent erhält ein Credential, ein Tool, eine MCP-Server-Verbindung – und von diesem Moment an ist sein Verhalten dynamisch. Er entscheidet zur Laufzeit, welche Ressourcen er liest, welche er schreibt, welches Tool er als Nächstes aufruft. Die Berechtigung, die Sie an Tag eins festgehalten haben, beschreibt eine Obergrenze, nicht das, was der Agent tut. Und weil Agenten produktiv sind, fällt diese Obergrenze tendenziell großzügig aus: breite Datenbankrollen, Schreibzugriff „für alle Fälle”, ein Service-Account, der über ein halbes Dutzend Workflows geteilt wird. Das Ergebnis ist ein Bestand, in dem der erlaubte Zugriff und der tatsächlich genutzte Zugriff still auseinanderdriften, Tag für Tag.
Unabhängige Branchenforschung erfasst das Ausmaß des blinden Flecks: Rund 82 % der Organisationen geben an, KI-Agenten im Betrieb zu haben, von denen sie nichts wussten (CSA/Token Security, n=418). Auf einem Bestand, den Sie nicht sehen können, lässt sich Least-Privilege nicht durchsetzen.
Least-Privilege-Drift definieren
Least-Privilege-Drift ist die wachsende Lücke zwischen dem Zugriff, der einem Agenten erlaubt ist, und dem Zugriff, den er beobachtbar nutzt. Sie hat zwei Fehlerrichtungen, und nur eine davon ist offensichtlich.
Die offensichtliche Richtung ist die Unternutzung: Ein Agent besitzt Schreibzugriff auf eine Tabelle, in die er noch nie geschrieben hat. Das ist totes Privileg, und es ist ein Risiko, das Sie ohne Nutzen mit sich tragen. Die gefährliche Richtung ist das gegenteilige Signal, das daraus folgt: Wenn die beobachtete Menge etwas enthält, das die erlaubte Menge nie bewusst freigegeben hat, dann findet eine Aktion statt, die niemand geprüft hat. Ein Export-Job, der plötzlich in einen Bucket schreibt, aus dem er bisher nur gelesen hat. Ein Agent, dessen Richtlinie auf ein Schema beschränkt war und der nun auf ein anderes übergreift. Das ist nichts Exotisches; es ist die alltägliche Textur von Agenten, die mit groben Berechtigungen miteinander verdrahtet sind.
Der Grund, warum das schwierig ist – und warum es spezifisch für Agenten gilt und nicht für Menschen –, liegt darin, dass das Verhalten generiert und nicht konfiguriert ist. Ein Mensch mit zu viel Zugriff nutzt diesen meist nicht aus. Ein Agent mit zu viel Zugriff wird alles ausnutzen, was ihm hilft, die anstehende Aufgabe zu erledigen, einschließlich Pfaden, die niemand vorhergesehen hat. Eine statische Richtlinienprüfung kann mit einem Verhalten, das sich pro Lauf ändert, nicht Schritt halten.
Drift in ein prüfbares Signal verwandeln
Drift ist nur gefährlich, solange er unsichtbar ist. Die Aufgabe besteht darin, ihn zu einem Signal zu machen, das ein Mensch prüfen kann, und das erfordert zwei Dinge, die zusammenwirken: die fortlaufende Beobachtung dessen, was Agenten tatsächlich berühren, und eine stabile Aufzeichnung dessen, was ihnen erlaubt war zu berühren.
Die Beobachtung muss read-first sein. Ein Collector, der aus Logs, OpenTelemetry-Traces und eBPF-Kernel-Signalen beobachtet, sitzt außerhalb des Datenpfads des Agenten. Er ist kein Proxy, er reguliert keine Aufrufe, und wenn er ausfällt, fällt er im sicheren Sinne offen aus: Der Agent arbeitet weiter, Sie verlieren Sichtbarkeit statt Verfügbarkeit. Diese Asymmetrie ist entscheidend: Ein Sicherheitskontrollmechanismus, der die Produktion lahmlegen kann, ist ein Mechanismus, den Teams stillschweigend deaktivieren. Insbesondere die eBPF-Schicht fungiert als Ground Truth auf Kernel-Ebene, als der Teil, an dem ein Agent nicht vorbeirouten kann (die Kernel-Erfassung stammt von einem Tetragon-Sensor, den Sie selbst betreiben; Olivares AI liest den Export von Tetragon und lädt selbst keine eBPF-Programme) – weshalb Hinweise auf Protokollebene wie MCP-Tool-Annotationen (readOnlyHint, destructiveHint) damit abgeglichen statt für bare Münze genommen werden. Die MCP-Spezifikation selbst besagt, dass diese Annotationen nicht vertrauenswürdig sind; erst Kernel-Signale machen den Abgleich belastbar.
Was die Beobachtung erzeugt, ist eine Access Map: für jeden Agenten, welche Ressourcen er erreicht hat und ob er gelesen (R) oder gelesen/geschrieben (RW) hat. Die Karte speichert Zugriffs-beziehungen, keine Payloads, Geheimnisse oder personenbezogenen Daten. Der interessante Teil ist der Diff:
| Agent | Ressource | Erlaubt | Beobachtet | Drift |
|---|---|---|---|---|
| data-export-job | prod-postgres | R | R | keiner |
| data-export-job | s3://billing-exports | R | RW | ungeprüfter Schreibzugriff |
| report-builder | analytics-db | R | (ungenutzt) | totes Privileg |
Die Zeile, auf die es ankommt, ist die mittlere. Die Richtlinie gewährte Lesezugriff auf den Export-Bucket; der Collector beobachtete einen Schreibzugriff. Diese eine Zeile ist genau das Hauptrisiko, das Least-Privilege-Drift sichtbar machen soll: ein ausgeübtes Privileg, das niemand geprüft hat, zugeordnet zu einem konkreten Agenten statt zu einem geteilten Service-Account – denn erst eine Identität pro Agent macht die Zuordnung und das Audit überhaupt möglich.
Zum Zeitpunkt des Zugriffs durchsetzen, nicht nur protokollieren
Die Erkennung sagt Ihnen, dass Drift aufgetreten ist. Um den Kreis zu schließen, soll der ungeprüfte Schreibzugriff ein verweigerter Pfad sein, kein protokollierter. Hier kommt eine Richtlinie ins Spiel, die zum Zeitpunkt des Zugriffs ausgewertet wird.
Olivares AI wertet Cedar als Forbid-Overlay über Rollen aus, die standardmäßig alles verweigern; eine Regel kann also nur Zugriff entziehen. Diese hier verweigert jede Anfrage, die ein geheimes Credential berührt, egal was die Rolle sagt.
permit(principal, action, resource);
forbid(principal, action, resource)
when { resource.kind == "credential" && resource.sensitivity == "secret" };Eigene Cedar-Regeln zu schreiben setzt Business voraus; Community setzt die integrierten Rollen, das native Deny-Overlay und den Kill-Switch durch; benutzerdefinierte Rollen und eingegrenzte Berechtigungen sind Business.
Gehen Sie das Vorher und Nachher konkret durch.
Vorher. Ein Coding-Agent, der eine breite Rolle innehat, ruft ein MCP-Tool auf, das auf s3://billing-exports schreibt. Nichts hält ihn auf. Die Aktion gelingt, geht im normalen Datenverkehr unter und taucht Tage später, wenn überhaupt, als Anomalie in der Access Map auf. Die Lücke zwischen erlaubt und beobachtet hat sich vergrößert, und das einzige Artefakt ist eine Logzeile, die niemand gelesen hat.
Nachher. Derselbe Tool-Aufruf erreicht das MCP-Gate. Die Rolle des Agenten erlaubt den Schreibzugriff nicht, daher verweigert das Gate den Aufruf, bevor er ausgeführt wird (deny-closed), und hält die Verweigerung im signierten Audit-Log fest, das Manipulationen erkennbar macht. Aus dem ungeprüften Schreibzugriff wird nie eine ungeprüfte Änderung. Olivares AI blockiert eine Aktion nur an seinen vier Durchsetzungspunkten: innerhalb von Claude Code, im Modell-Proxy, bei jedem MCP-Tool-Aufruf und zwischen Agenten. Ein Job, der direkt in S3 schreibt, außerhalb dieser Punkte, wird nicht blockiert: Die Access Map zeichnet den Schreibzugriff auf und kennzeichnet ihn als Drift zur Prüfung.
Zwei Eigenschaften halten das ehrlich. Erstens wird jede privilegierte Einsicht in die Access Map selbst auditiert – wer hat was angesehen –, denn die Karte ist sensibel, und ein Sicherheitswerkzeug, das seine eigenen Bediener nicht nachvollziehbar machen kann, ist nicht vertrauenswürdig. Zweitens wird die Konfidenz klar ausgewiesen: Eine Kante, deren Quelle eine Identität pro Agent trägt, ist als attributed markiert, eine nur vom Kernel gesehene als approximate, weil Kernel-Signale einen Prozess, eine Cgroup oder einen Container benennen, nicht einen Agenten. Sie werden nie aufgefordert, auf Basis einer erfundenen Gewissheit zu handeln.
Das Fazit
Least-Privilege ist für KI-Agenten nicht gescheitert; der Prüfrhythmus ist es. Berechtigungen sind grob, Verhalten ist dynamisch, und vierteljährliche Zertifizierungen können eine Zugriffsfläche, die sich bei jedem Lauf ändert, nicht verfolgen. Die Lösung ist kein schwererer Proxy im kritischen Pfad. Sie ist fortlaufende, read-first Beobachtung, die einen Diff aus erlaubt vs. beobachtet erzeugt, plus Policy-as-Code, die die korrigierte Grenze zum Zeitpunkt des Zugriffs durchsetzt – sodass ein über-privilegierter Agent als prüfbares Signal erkannt wird, lange bevor er zum Vorfall wird.
Wenn Sie sehen möchten, wie der Collector, die Access Map und die Durchsetzung zum Zeitpunkt des Zugriffs zusammenspielen, ohne im Datenpfad Ihrer Agenten zu sitzen, führt die Seite Architektur durch das Design, und das Produkt zeigt, wie die Ansicht aus erlaubt vs. beobachtet auf einem realen Bestand aussieht.