Passieve detectie versus proxies: AI-agents inventariseren zonder in het datapad te zitten

De meeste teams ontdekken hetzelfde ongemakkelijke feit in dezelfde volgorde. Eerst beseffen ze dat er al AI-agents door hun hele omgeving draaien, die modellen aanroepen, MCP-servers openen en in databases en object stores grijpen. Vervolgens proberen ze die te inventariseren en stellen ze vast dat er geen lijst bestaat. Onafhankelijk branche-onderzoek (CSA/Token, n=418) zet cijfers op die kloof: ongeveer 82% van de organisaties heeft agents draaien waarvan ze niets weten, en slechts circa 21% houdt een real-time inventaris bij. Voordat u hier iets van kunt besturen, moet u het kunnen zien. De vraag is hoe u die zichtbaarheid krijgt zonder de zaak erger te maken.

Er zijn twee eerlijke antwoorden, en die liggen aan tegenovergestelde uiteinden van een risicospectrum.

Twee manieren om een agent te zien

De eerste is een inline proxy. U routeert het verkeer van de agent via een component die u beheert, en omdat elk request en elke response erdoorheen gaat, kunt u in real time zien, vormgeven en blokkeren. Dit is een legitiem, krachtig ontwerp. Op deze manier wordt vandaag de dag veel egress-filtering, secret-brokering en beleid op requestniveau afgedwongen.

De tweede is passieve detectie. In plaats van in de flow te gaan staan, observeert u die van opzij: de OpenTelemetry die een agent al uitzendt, de native audittrails van de systemen die hij aanraakt (PostgreSQL pgAudit, cloud-auditlogs zoals AWS CloudTrail, Kubernetes audit), en signalen op kernelniveau via eBPF als ground-truth-vangnet. U termineert de verbinding nooit. U bekijkt wat er is gebeurd en reconstrueert wie wat heeft aangeraakt.

Het verschil dat ertoe doet, is niet hoeveel elk in het beste geval kan zien. Het is wat er gebeurt wanneer de zichtbaarheidslaag zelf uitvalt.

Blast radius is de echte as

Een inline proxy zit per constructie in het datapad. Dat levert real-time controle op, en het kost u een gedeelde faalmodus. Is de proxy traag, dan zijn uw agents traag. Valt hij om, dan is de veilige standaard meestal fail closed, waardoor uw agents stoppen, of fail open, waardoor uw controle stilletjes verdwijnt op het slechtst denkbare moment. Hoe dan ook deelt de zichtbaarheidscomponent nu een blast radius met de productie. Hij voegt bovendien een latency-hop toe aan elke aanroep en een deployment-oppervlak dat iemand op het kritieke pad moet beheren, schalen en patchen.

Passieve detectie heeft het tegenovergestelde profiel. De collector is out-of-band en read-first: hij leest telemetrie, audittrails en kernel-events; hij stuurt het verkeer van de agent niet door en herschrijft het niet. Degradeert of sterft hij, dan verandert er niets in het requestpad. U verliest actuele zichtbaarheid tot hij hersteld is, geen doorvoer, geen beschikbaarheid. Dit is wat read-first, laag-asymmetrisch risico in de praktijk betekent: er is geen opwaarts risico voor de productie vanuit het ding waarvan de enige taak is om te kijken.

Daarom luidt het productstandpunt geen verplichte proxy in plaats van “proxies zijn nutteloos”. Er zijn paden waar een inline component de juiste keuze is, en die laten zich combineren. Maar detectie, het deel dat nooit het ding waarvan het de inventaris bijhoudt mag platleggen, is de verkeerde taak om aan het kritieke pad vast te schroeven.

De afweging, eerlijk gesteld

Passieve detectie heeft een echte zwakte, en het tegendeel beweren zou het soort stroman zijn dat een ontwerp stilletjes het vertrouwen ontneemt. Een proxy die een flow termineert, ziet er elke byte van. Een passieve collector ziet alleen wat de agent, zijn runtime of de resource heeft besloten uit te zenden. Op een volledig niet-coöperatief pad, eentje dat weinig logt en geen bruikbare telemetrie uitzendt, dunt detectie op applicatieniveau uit. U kunt afleiden dat er iets is gebeurd, maar attributie wordt moeilijker.

Twee dingen houden dat eerlijk in plaats van fataal.

Het eerste is het eBPF-vangnet in de kernel. Applicatielogs kunnen incompleet zijn, vertraagd, of, in een vijandig geval, opzettelijk onderdrukt. De kernel kun je niet vriendelijk vragen een syscall te vergeten. Een agent die een socket naar een database opent of een bestand schrijft, laat een spoor achter op de syscall-grens, ongeacht wat zijn logging heeft besloten vast te leggen. Dat maakt eBPF tot de anti-ontwijkings-ground-truth: wanneer hogerliggende signalen het oneens zijn of stilvallen, is de kernelweergave de bevestigende laag. Het is ook de reden waarom MCP-toolannotaties zoals readOnlyHint en destructiveHint, nuttig als hints, conform de MCP-spec als untrusted worden behandeld. Een tool die beweert read-only te zijn en die wordt waargenomen terwijl hij schrijft, is precies de discrepantie die het verdient om aan het licht te komen, en u betrapt die alleen als u de bewering toetst aan wat er werkelijk is gebeurd.

Het tweede zijn eerlijke betrouwbaarheidsniveaus. Niet elke waarneming verdient hetzelfde gewicht, dus de toegangskaart doet niet alsof dat zo is. Een edge die onderbouwd is door een kernelsignaal en een bijbehorend auditrecord wordt gemarkeerd als attributed; een edge die uit gedeeltelijke telemetrie is afgeleid, wordt gemarkeerd als approximate. Het product witwast nooit een gok tot een feit. Een reviewer moet in één oogopslag kunnen zien hoeveel hij elke regel mag vertrouwen.

Van waarneming naar de diff die ertoe doet

Detectie is slechts de input. De output is de vergelijking tussen PERMITTED, wat het beleid toestaat, en OBSERVED, wat de collector daadwerkelijk zag. Die diff is least-privilege-drift, en de kop boven het verhaal is een waargenomen write die het beleid nooit heeft toegekend en die niemand heeft gereviewd.

Een paar regels uit een access feed maken het concreet. Reads zijn routine; de geflagde write is het verhaal:

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

Een export-job die een productiedatabase leest, is niets bijzonders. Diezelfde job die er naartoe schrijft, terwijl het beleid alleen ooit read heeft toegekend, is het soort edge dat nooit ongereviewd zou mogen passeren. Omdat de write op de kernelgrens wordt bevestigd, is hij gemarkeerd als attributed, geen slag om de arm.

De drift zien is de helft van het werk; hem dichten is de andere helft. Handhaving hoort bij het toegangspunt, uitgedrukt als policy-as-code, zodat de regel reviewbaar is en op de overtreding wordt gehandeld, niet enkel gelogd:

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

Passieve detectie vindt de niet-toegekende write; het beleid pint de agent terug op least-privilege en blokkeert de volgende. Zichtbaarheid en controle blijven gescheiden zorgen, en dat is precies waarom de detectielaag zich read-first kan veroorloven.

Conclusie

Zichtbaarheid op AI-agents is een risicobeslissing voordat het een featurebeslissing is. Een inline proxy geeft u real-time controle ten koste van het delen van een blast radius met de productie. Passieve detectie geeft wat bereik op stille paden op in ruil voor de garantie dat ze de productie nooit kan platleggen, en dicht het grootste deel van dat bereik vervolgens met een eBPF-ground-truth-vangnet en betrouwbaarheidsniveaus die eerlijk blijven over wat er werkelijk is gezien. Voor een inventaris, de laag waarvan de hele taak is om te kijken, is die asymmetrie de juiste standaard.

Wilt u het volledige beeld van hoe de collectors, de toegangskaart en de auditregistratie in elkaar passen, dan loopt het architectuuroverzicht er van begin tot eind doorheen.