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, während nur etwa 21 % ein Echtzeit-Inventar darüber führen (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
Lassen Sie mich die Sache präzise benennen. 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 – 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 Policy-as-Code ins Spiel, die zum Zeitpunkt des Zugriffs ausgewertet wird. Derselbe Diff, der den Drift markiert hat, wird zur Regel, die ihn verhindert.
Erwägen Sie, den Export-Job auf der Produktionsdatenbank auf Read-only festzunageln und Schreibzugriffe rundheraus zu verweigern, mit einer Verletzung, die blockiert und alarmiert, statt stillschweigend durchzugehen:
agent "data-export-job" {
# Read-only on the operational database. No writes, ever.
access "prod-postgres" {
mode = "read"
deny = ["write", "delete", "ddl"]
}
# The export target the job is *supposed* to use.
access "s3://billing-exports" {
mode = "read"
}
on_violation {
action = "block" # deny the call at access time
alert = "security-oncall"
audit = "append" # write to the tamper-evident ledger
}
}Gehen Sie das Vorher und Nachher konkret durch.
Vorher. Der Export-Job, der eine breite Rolle innehat, führt einen Schreibzugriff auf s3://billing-exports aus. 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 Schreibzugriff trifft ein. Die Richtlinie wird zum Zeitpunkt des Zugriffs ausgewertet, erkennt einen write auf einer Ressource, die auf read beschränkt ist, und gibt eine Verweigerung zurück, bevor die Operation greift. Die Verletzung blockiert den Aufruf, löst eine Warnung an die Bereitschaftsrotation aus und hängt einen Eintrag an das anhängende, hash-verkettete Audit-Ledger an. Aus dem ungeprüften Schreibzugriff wird nie eine ungeprüfte Änderung. Der Drift wird im selben Moment zurück in einen Least-Privilege-Pfad umgewandelt.
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 Aktion, die einem Agenten durch Evidenz auf Kernel-Ebene zugeordnet wird, ist anders gekennzeichnet als eine, die nur näherungsweise erschlossen wurde. 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.