Die meisten Teams entdecken dieselbe unbequeme Tatsache in derselben Reihenfolge. Zuerst stellen sie fest, dass bereits KI-Agenten quer durch ihren Bestand laufen, Modelle aufrufen, MCP-Server öffnen, in Datenbanken und Object Stores greifen. Dann versuchen sie, diese zu inventarisieren, und finden keine Liste vor. Unabhängige Branchenforschung (CSA/Token, n=418) liefert Zahlen zu dieser Lücke: Rund 82 % der Organisationen haben Agenten in Betrieb, von denen sie nichts wissen. Bevor Sie all das überhaupt steuern können, müssen Sie es sehen. Die Frage ist, wie Sie diese Sichtbarkeit erreichen, ohne die Lage zu verschlimmern.
Es gibt zwei ehrliche Antworten, und sie liegen an den entgegengesetzten Enden eines Risikospektrums.
Zwei Wege, einen Agenten zu sehen
Der erste ist ein Inline-Proxy. Sie leiten den Traffic des Agenten durch eine Komponente, die Sie kontrollieren, und weil jeder Request und jede Response durch sie hindurchläuft, können Sie in Echtzeit sehen, formen und blockieren. Das ist ein legitimes, mächtiges Design. So wird heute ein Großteil von Egress-Filterung, Secret-Brokering und Policy auf Request-Ebene durchgesetzt.
Der zweite ist Passive Discovery. Statt im Flow zu stehen, beobachten Sie ihn von der Seite: die OpenTelemetry, die ein Agent ohnehin emittiert, die nativen Audit-Trails der Systeme, die er berührt (PostgreSQL pgAudit, Cloud-Audit-Logs wie AWS CloudTrail, Kubernetes Audit), und Kernel-Signale via eBPF als Ground-Truth-Backstop. Sie terminieren die Verbindung nie. Sie beobachten, was geschehen ist, und rekonstruieren, wer was berührt hat. Die Kernel-Erfassung stammt von einem Tetragon-Sensor, den Sie selbst bereitstellen; Olivares AI liest den Export von Tetragon und lädt selbst keine eBPF-Programme.
Der entscheidende Unterschied liegt nicht darin, wie viel jeder Ansatz im Bestfall sehen kann. Er liegt darin, was passiert, wenn die Sichtbarkeitsschicht selbst ausfällt.
Der Blast Radius ist die eigentliche Achse
Ein Inline-Proxy steht konstruktionsbedingt im Datenpfad. Das verschafft Echtzeitkontrolle und kostet Sie einen geteilten Fehlerfall. Ist der Proxy langsam, sind Ihre Agenten langsam. Bricht er weg, ist das sichere Verhalten in der Regel entweder fail-closed, was bedeutet, dass Ihre Agenten stehen bleiben, oder fail-open, was bedeutet, dass Ihre Kontrolle im ungünstigsten Moment klammheimlich verschwindet. So oder so teilt sich die Sichtbarkeitskomponente nun einen Blast Radius mit der Produktion. Sie fügt außerdem jedem Aufruf einen Latenz-Hop hinzu und eine Deployment-Fläche, die jemand auf dem kritischen Pfad betreiben, skalieren und patchen muss.
Passive Discovery hat das umgekehrte Profil. Der Collector ist out-of-band und read-first: Er liest Telemetrie, Audit-Trails und Kernel-Events; er leitet den Traffic des Agenten weder weiter noch schreibt er ihn um. Degradiert er oder fällt er aus, ändert sich im Request-Pfad nichts. Sie verlieren aktuelle Sichtbarkeit, bis er sich erholt, nicht Durchsatz, nicht Verfügbarkeit. Genau das bedeutet read-first und geringes asymmetrisches Risiko in der Praxis: Von der Sache, deren einzige Aufgabe das Beobachten ist, geht kein Aufwärtsrisiko für die Produktion aus.
| Inline-Proxy | Passive Discovery | |
|---|---|---|
| Position | Im Datenpfad | Out-of-band, daneben |
| Echtzeit-Blockierung | Nativ | Erfordert Enforcement am Access Point |
| Hinzugefügte Latenz | Ja, bei jedem Aufruf | Keine |
| Bei Ausfall | Agenten stocken oder Kontrolle verschwindet | Sichtbarkeit veraltet; Agenten unbeeinträchtigt |
| Abdeckung stiller Pfade | Hoch (er terminiert den Flow) | Hängt von emittierten Signalen + eBPF-Backstop ab |
Deshalb lautet die Produkthaltung kein verpflichtender Proxy und nicht „Proxies sind nutzlos”. Es gibt Pfade, auf denen eine Inline-Komponente die richtige Wahl ist, und sie lassen sich kombinieren. Doch Discovery, der Teil, dem es nie erlaubt sein darf, genau das lahmzulegen, was er inventarisiert, ist die falsche Aufgabe, um sie auf den kritischen Pfad zu schrauben.
Der Tradeoff, ehrlich benannt
Passive Discovery hat eine echte Schwäche, und etwas anderes zu behaupten wäre die Art Strohmann, die ein Design still und leise in Misskredit bringt. Ein Proxy, der einen Flow terminiert, sieht jedes Byte davon. Ein passiver Collector sieht nur, was der Agent, seine Runtime oder die Ressource zu emittieren entschieden hat. Auf einem vollständig nicht-kooperativen Pfad, der wenig protokolliert und keine brauchbare Telemetrie ausgibt, dünnt Discovery auf Anwendungsebene aus. Sie können schlussfolgern, dass etwas passiert ist, aber die Zuordnung wird schwieriger.
Zwei Dinge halten das ehrlich, statt es fatal werden zu lassen.
Das erste ist der eBPF-Kernel-Backstop. Anwendungs-Logs können unvollständig, verzögert oder im adversarialen Fall absichtlich unterdrückt sein. Der Kernel lässt sich nicht höflich darum bitten, einen Syscall zu vergessen. Ein Agent, der einen Socket zu einer Datenbank öffnet oder eine Datei schreibt, hinterlässt an der Syscall-Grenze eine Spur, unabhängig davon, was sein Logging festzuhalten entschieden hat. Das macht eBPF zur Anti-Evasion-Ground-Truth: Wenn höherstufige Signale widersprechen oder verstummen, ist die Kernel-Sicht die bestätigende Schicht. Es ist auch der Grund, warum MCP-Tool-Annotationen wie readOnlyHint und destructiveHint, nützlich als Hinweise, gemäß MCP-Spec als untrusted behandelt werden. Ein Tool, das vorgibt, read-only zu sein, und beim Schreiben beobachtet wird, ist genau die Diskrepanz, die es aufzudecken lohnt, und Sie erwischen sie nur, wenn Sie die Behauptung mit dem abgleichen, was tatsächlich passiert ist.
Das zweite sind ehrliche Konfidenzstufen. Nicht jede Beobachtung verdient dasselbe Gewicht, und die Access Map tut auch nicht so, als wäre es anders. Eine Kante, deren Quelle eine Identität pro Agent trägt, etwa kooperatives OpenTelemetry mit Agent-ID oder ein Audit-Trail, in dem der Agent eine eigene Datenbankrolle hat, wird als attributed markiert. Eine aus partieller Telemetrie abgeleitete Kante und jede Kante, die nur der Kernel sieht, wird als approximate markiert, weil Kernel-Signale einen Prozess, eine Cgroup oder einen Container benennen, nicht einen Agenten. Das Produkt verkleidet eine Vermutung nie als Tatsache. Ein Prüfer sollte auf einen Blick erkennen können, wie sehr jeder Zeile zu trauen ist.
Von der Beobachtung zum entscheidenden Diff
Discovery ist nur der Input. Der Output ist der Vergleich zwischen PERMITTED, was die Policy erlaubt, und OBSERVED, was der Collector tatsächlich gesehen hat. Dieser Diff ist Least-Privilege-Drift, und der Paradefall ist ein beobachteter Schreibvorgang, den keine Policy je gewährt hat und den niemand geprüft hat.
Ein paar Zeilen aus einem Access-Feed machen es greifbar. Lesevorgänge sind Routine; der markierte Schreibvorgang ist die eigentliche Geschichte:
agent action resource outcome confidence
data-export-job READ s3://billing-exports allowed attributed
data-export-job READ prod-postgres allowed attributed
data-export-job WRITE prod-postgres flagged approximate
support-rag READ internal-wiki-mcp allowed approximateEin Export-Job, der eine Produktionsdatenbank liest, ist unauffällig. Derselbe Job, der in sie schreibt, obwohl die Policy nur jemals Lesezugriff gewährt hat, ist die Art Kante, die nie ungeprüft durchgehen sollte. Der Kernel bestätigt, dass der Schreibvorgang stattgefunden hat, benennt aber einen Prozess oder Container und keinen Agenten; deshalb wird diese Kante als approximate markiert.
Die Drift zu sehen ist die halbe Arbeit; sie zu schließen die andere Hälfte. Enforcement gehört an den Access Point, ausgedrückt als Policy-as-Code, damit die Regel prüfbar ist. Olivares AI wertet Cedar als Forbid-Overlay über Deny-by-default-Rollen aus, sodass eine Regel Zugriff nur wegnehmen kann; diese hier verweigert jede Anfrage, die ein als geheim eingestuftes Credential berührt, was auch immer die Rolle sagt.
permit(principal, action, resource);
forbid(principal, action, resource)
when { resource.kind == "credential" && resource.sensitivity == "secret" };Eigene Cedar-Regeln zu schreiben erfordert Business. Community erzwingt die integrierten Rollen, das native Deny-Overlay und den Kill-Switch; eigene Rollen und bereichsbezogene Grants gehören zu Business.
Passive Discovery findet den nicht erlaubten Schreibvorgang, und die Zugriffskarte markiert ihn als Drift. Olivares AI blockiert nur an seinen vier Durchsetzungspunkten: in Claude Code, im Modell-Proxy, bei jedem MCP-Tool-Aufruf und zwischen Agenten. Ein Schreibvorgang, der über einen dieser Punkte läuft und den die Rolle des Agenten nicht erlaubt, wird verweigert, bevor er ausgeführt wird, und im signierten Audit-Log festgehalten, das Manipulationen erkennbar macht; ein direkter Schreibvorgang auf die Datenbank wird beobachtet, nicht blockiert. Sichtbarkeit und Kontrolle bleiben getrennte Anliegen, was genau der Grund ist, warum sich die Discovery-Schicht leisten kann, read-first zu sein.
Fazit
Sichtbarkeit über KI-Agenten ist eine Risikoentscheidung, bevor sie eine Feature-Entscheidung ist. Ein Inline-Proxy verschafft Ihnen Echtzeitkontrolle zum Preis eines mit der Produktion geteilten Blast Radius. Passive Discovery gibt auf stillen Pfaden etwas Reichweite auf, im Tausch dafür, dass sie die Produktion niemals lahmlegen kann, und schließt dann den größten Teil dieser Reichweite mit einem eBPF-Ground-Truth-Backstop und Konfidenzstufen, die ehrlich bleiben über das, was tatsächlich gesehen wurde. Für ein Inventar, die Schicht, deren gesamte Aufgabe das Beobachten ist, ist diese Asymmetrie die richtige Voreinstellung.
Wenn Sie das vollständige Bild davon wollen, wie die Collector, die Access Map und das Audit-Ledger zusammenpassen, führt Sie der Architekturüberblick von Anfang bis Ende hindurch.