Übersieht Passive Discovery Dinge, die ein Proxy erfassen würde?

Auf vollständig kooperativen Pfaden konvergieren beide Ansätze. Ein Proxy kann jedes Byte der Flows sehen, die er terminiert, während Passive Discovery auf die Telemetrie und Audit-Trails angewiesen ist, die ein Agent oder sein Host ausgibt. Die Lücke entsteht auf nicht-kooperativen Pfaden, die wenig emittieren. Genau dafür ist der eBPF-Kernel-Backstop da: Ein Syscall, der einen Socket oder eine Datei berührt, ist beobachtbar, unabhängig davon, was die Anwendung zu protokollieren entschieden hat. Wo die Beweislage dünner ist, kennzeichnet die Access Map die Kante als näherungsweise statt als zugeordnet, sodass eine Beobachtung mit geringerer Konfidenz nie als Gewissheit ausgegeben wird.

Wenn der Collector ausfällt, legt das meine Agenten lahm?

Nein. Ein passiver Collector liegt per Design außerhalb des Request-Pfads: Er liest OpenTelemetry, native Audit-Trails und Kernel-Signale out-of-band und terminiert oder leitet den Traffic des Agenten nie weiter. Fällt er aus, laufen Ihre Agenten exakt wie zuvor weiter; Sie verlieren aktuelle Sichtbarkeit, bis er zurückkehrt, nicht die Produktion. Diese Asymmetrie, kein Aufwärtsrisiko für den Datenpfad, ist der ganze Sinn einer read-first-Erfassung.

Passive Discovery vs. Proxies: KI-Agenten inventarisieren, ohne im Datenpfad zu sitzen

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, und nur etwa 21 % pflegen ein Echtzeit-Inventar. 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.

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, die durch ein Kernel-Signal und einen passenden Audit-Eintrag gestützt ist, wird als attributed markiert; eine aus partieller Telemetrie abgeleitete Kante wird als approximate markiert. 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   attributed
support-rag       READ    internal-wiki-mcp       allowed   approximate

Ein 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. Weil der Schreibvorgang an der Kernel-Grenze bestätigt ist, wird er als attributed markiert, nicht als Vorbehalt.

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 und auf den Verstoß reagiert wird, statt ihn bloß zu protokollieren:

policy "data-export-readonly" {
  agent        = "data-export-job"
  resource     = "prod-postgres"
  allow        = ["read"]
  deny         = ["write"]
  on_violation = "block + alert"
}

Passive Discovery findet den nicht erlaubten Schreibvorgang; die Policy bindet den Agenten wieder auf Least-Privilege zurück und blockiert den nächsten. 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.