Was Ihre KI-Agenten tatsächlich erreichen können: Agentenzugriffe auf realer Infrastruktur abbilden

Ein KI-Agent ist im Betrieb ein Prozess, der Credentials hält. Jemand stattet ihn mit einem Service-Account, einem API-Key oder einer IAM-Rolle aus, damit er seine Aufgabe erledigen kann, und von diesem Moment an kann er alles erreichen, was diese Credentials erreichen. Die Aufgabenbeschreibung lautete „Abrechnungsdaten nächtlich exportieren”. Das Credential lautete „die Produktionsdatenbank lesen und beschreiben, dazu den Object Store und die Queue”. Niemand hat beides abgeglichen. Monate später kann niemand im Team eine Frage beantworten, die trivial sein sollte: Was kann dieser Agent tatsächlich erreichen, und was berührt er tatsächlich?

Diese Lücke ist nicht hypothetisch. Unabhängige Branchenforschung (CSA/Token) ergab, dass rund 82 % der Organisationen KI-Agenten betreiben, von denen sie nichts wissen, während nur etwa 21 % ein Echtzeit-Inventar dieser Agenten führen. Sie können nicht steuern, was Sie nicht sehen, und derzeit können die meisten Estates ihre Agenten überhaupt nicht sehen — geschweige denn die Kanten, die jeden Agenten mit den Ressourcen verbinden, die er erreichen kann.

Drei verschiedene Fragen, routinemäßig vermischt

Der Grund, warum „was kann dieser Agent erreichen” so schwer zu beantworten ist, liegt darin, dass die Frage drei separate Fragen in eine kollabieren lässt. Sie auseinanderzuhalten ist das ganze Spiel.

• Gehalten — die Credentials, die der Agent besitzt. Ein Token, ein Key, ein Role-Binding. Das ist ein Identitäts-Fakt: zu welchen Türen der Agent die Schlüssel hat.
• Erlaubt — was diese Credentials laut Policy tun dürfen: die IAM-Grants, die Datenbankrollen, die Netzwerkregeln. Das ist ein Policy-Fakt, und er ist fast immer breiter, als irgendjemand sich erinnert, weil Berechtigungen anwachsen und niemand sie wieder entzieht.
• Beobachtet — was der Agent tatsächlich dabei gesehen wurde zu tun: welche Ressourcen er erreicht hat und ob jeder Zugriff ein Lesen oder ein Schreiben war. Das ist ein Verhaltens-Fakt, und solange Sie ihn nicht erheben, existiert er schlicht nirgendwo.

Die meisten Security-Werkzeuge hören bei erlaubt auf. Sie lesen Ihr IAM aus und teilen Ihnen mit, dass der Agent in den Bucket der Abrechnungsexporte schreiben könnte. Das ist notwendig, aber unzureichend, denn „könnte” ist eine Menge aus Tausenden latenter Fähigkeiten, und ein Mensch kann nicht Tausende von Vielleichts triagieren. Was das Gespräch verändert, ist, beobachtet neben erlaubt zu stellen und auf die Differenz zu schauen.

Die Access Map

Eine Access Map ist der Graph dieser Kanten: für jeden entdeckten Agenten eine Kante zu jeder Ressource, die er erreichen kann, annotiert mit dem, was tatsächlich darüber beobachtet wurde. Die Einheit, auf die es ankommt, ist die Kante, und die wichtigste Annotation an der Kante ist die Unterscheidung zwischen Lesen und Schreiben.

R (read) bedeutet, dass der Agent Daten abgerufen hat, ohne sie zu verändern: ein SELECT, ein GET, ein Dateilesezugriff. RW (read/write) bedeutet, dass er Zustand verändert hat: ein INSERT/UPDATE/DELETE, ein PUT in den Object Store, eine Schema-Migration. Der Blast-Radius dieser beiden ist nicht vergleichbar. Eine Lesekante auf einer sensiblen Tabelle ist eine Frage der Exponierung. Eine Schreib-Kante — besonders eine unbeabsichtigte — ist eine Frage der Integrität und ein Incident. Beide als denselben „Zugriff” zu behandeln, ist der Weg, wie Teams das Finding verpassen, auf das es ankam.

So sieht die Zeile eines einzelnen Agenten aus, sobald die Map gebaut ist:

Sehen Sie sich die erste Zeile an. Der Export-Job war dazu gedacht, aus prod-postgres zu lesen und das Ergebnis nach s3://billing-exports zu schreiben. Quelle lesen, Ziel schreiben. Doch das Credential, das ihm übergeben wurde, gewährt RW auf der Datenbank, und der Collector beobachtete, wie er in prod-postgres schrieb — eine Mutation am produktiven System of Record, die niemand geprüft, beabsichtigt oder derzeit erklären kann. Die Spalte „Erlaubt” hat still und leise die ganze Zeit gesagt, dass dies zulässig war. Das ist der Keim eines Incidents, offen sichtbar, und ohne die Spalte „Beobachtet” gibt es nichts, was sich kennzeichnen ließe.

Erlaubt minus beobachtet ergibt Drift

Das charakteristische Ergebnis ist die Differenz. Least-Privilege-Drift ist das, was Sie erhalten, wenn Sie eine Spalte von der anderen abziehen, und sie schneidet in beide Richtungen:

• Erlaubt, aber nie beobachtet — der Agent kann internal-metrics-api erreichen, hat es im gesamten Beobachtungsfenster aber nie getan. Das ist toter Scope: eine Berechtigung, deren Entzug Sie gefahrlos vorschlagen können und die die Angriffsfläche verkleinert, ohne das Verhalten zu berühren.
• Beobachtet jenseits dessen, was geprüft wurde — der Schreibzugriff auf prod-postgres, den niemand abgezeichnet hat. Das ist das aussagekräftige Finding: eine Aktion, die geschieht und die, hätte man bei der Provisionierung danach gefragt, niemand genehmigt hätte.

Die zweite Kategorie ist das eigentliche Risiko, und die ehrliche Version des Produkts erfindet sie nie. Jede beobachtete Kante trägt ein Konfidenzniveau — attribuiert, wenn die Aktion mit korroborierendem Signal an eine bestimmte Agentenidentität gebunden ist, approximativ, wenn die Evidenz schwächer ist. Sie zeigen die Differenz, statt eine Vermutung zur Gewissheit umzudeklarieren. Ein Finding, hinter dem Sie nicht stehen können, ist schlimmer als gar kein Finding.

Passiv entdeckt, pro Agent attribuiert

Zwei Designentscheidungen machen das vertrauenswürdig, statt nur ein weiteres Dashboard zu sein.

Erstens ist die Discovery passiv. Der Collector beobachtet — Logs, OpenTelemetry-Traces, Datenbank-Audit-Streams wie PostgreSQLs pgAudit und eBPF auf Kernel-Ebene als Ground-Truth-Absicherung — und sitzt nicht im Datenpfad des Agenten. Es gibt keinen verpflichtenden Proxy. Fällt der Collector aus, arbeitet der Agent weiter; die Observability degradiert, die Produktion nicht. Für ein System, dessen ganzer Zweck die Steuerung kritischer Infrastruktur ist, ist diese Asymmetrie das Design: geringes Downside, hohes Signal.

Zweitens wird jede Aktion einer bestimmten Agentenidentität zugeordnet, nicht einem gemeinsam genutzten Service-Account. Das ist der Unterschied zwischen einem Audit-Ledger, das sagt „die Export-Rolle hat um 02:14 in prod-postgres geschrieben”, und einem, das sagt, welcher Agent es tat, unter wessen Verantwortung, gegen welchen beabsichtigten Scope. Identität pro Agent ist die Voraussetzung dafür, dass Least-Privilege überhaupt etwas bedeutet — ohne sie kann eine Aktion zwar gesehen, aber nie auf einen verantwortlichen Owner zurückgeführt werden.

Die Kanten und die Read/Write-Fakten sind das Einzige, was gespeichert wird. Die Map erfasst Beziehungen — Agent zu Ressource, R oder RW — nicht Payloads, nicht die gelesenen Zeilen, keine Secrets. Eingaben, die Secrets oder personenbezogene Daten enthalten könnten, werden redigiert und einem Secret-Scanning unterzogen, bevor irgendetwas geschrieben wird. Der Graph ist gerade deshalb sensibel, weil er eine Access Map ist, und deshalb so gebaut, dass er das Minimum enthält, das Governance möglich macht, und nicht mehr.

Signale aus dem eigenen Ökosystem des Agenten helfen, doch ihnen allein wird nicht vertraut. Ein MCP-Server kann über Annotationen wie readOnlyHint ankündigen, dass ein Tool read-only sei; gemäß der MCP-Spezifikation sind diese Hints untrusted und müssen korroboriert, niemals blind geglaubt werden. Die Sicht auf Kernel-Ebene ist das, was ein Tool erwischt, das read-only beanspruchte und trotzdem schrieb.

Sobald die Map existiert, ist der nächste Schritt die Enforcement: den Export-Job auf der Datenbank auf read-only festzunageln, den Schreibzugriff zu verweigern und zu alarmieren, statt bloß zu loggen — Policy, die zum Zugriffszeitpunkt angewendet wird, nicht nach dem Incident rekonstruiert.

agent "data-export-job" {
  resource "prod-postgres" {
    access = "read"        # intended scope: read source only
    deny   = ["write", "ddl"]
  }
  resource "s3://billing-exports" {
    access = "read-write"  # intended scope: write destination
  }
  on_violation {
    action = "block"
    alert  = "secops"
  }
}

Die Map sagt Ihnen die Policy, die Sie hätten schreiben sollen, weil sie Ihnen den einen Zugriff zeigt, den der Agent tatsächlich brauchte, und das Dutzend, das er nie nutzte. Das ist der Unterschied zwischen dem Raten von Least-Privilege und dem Ableiten aus Ground Truth.

Wenn dies die Frage ist, die Ihr Estate heute nicht beantworten kann — was kann jeder Agent erreichen, und was berührt er tatsächlich — dann ist genau dafür die Access Map da. Die Produktübersicht führt durch Discovery und die Differenz aus Erlaubt und Beobachtet; die Architektur erläutert, wie passive Collection, Identität pro Agent und das Audit-Ledger zusammenspielen, ohne jemals im Datenpfad Ihrer Agenten zu sitzen.