Wat uw AI-agents werkelijk kunnen bereiken: het in kaart brengen van agenttoegang op echte infrastructuur

Een AI-agent is operationeel gezien een proces dat credentials bezit. Iemand voorziet hem van een serviceaccount, een API-sleutel of een IAM-rol zodat hij zijn werk kan doen, en vanaf dat moment kan hij alles bereiken wat die credentials kunnen bereiken. De functieomschrijving luidde “exporteer ‘s nachts factuurgegevens”. De credential luidde “lees en schrijf de productiedatabase, en de objectopslag, en de queue”. Niemand bracht die twee met elkaar in lijn. Maanden later kan niemand in het team een vraag beantwoorden die triviaal zou moeten zijn: wat kan deze agent werkelijk bereiken, en wat raakt hij daadwerkelijk aan?

Dat verschil is geen hypothese. Onafhankelijk onderzoek uit de sector (CSA/Token) constateerde dat ongeveer 82% van de organisaties AI-agents draaiend heeft waarvan ze het bestaan niet kennen, terwijl slechts circa 21% een realtime inventaris ervan bijhoudt. U kunt niet besturen wat u niet kunt zien, en op dit moment kunnen de meeste omgevingen hun agents helemaal niet zien — laat staan de verbindingen tussen elke agent en de resources die hij kan bereiken.

Drie verschillende vragen, routinematig op één hoop gegooid

De reden dat “wat kan deze agent bereiken” zo moeilijk te beantwoorden is, is dat de vraag drie afzonderlijke vragen tot één samenklapt. Ze gescheiden houden is waar het allemaal om draait.

• Held — de credentials die de agent in handen heeft. Een token, een sleutel, een rolbinding. Dit is een identiteitsfeit: tot welke deuren de agent sleutels heeft.
• Permitted — wat die credentials volgens beleid mogen doen: de IAM-grants, de databaserollen, de netwerkregels. Dit is een beleidsfeit, en het is vrijwel altijd breder dan iemand zich herinnert, omdat grants zich opstapelen en niemand ze intrekt.
• Observed — wat de agent daadwerkelijk is gezien te doen: welke resources hij bereikte, en of elke toegang een lees- of schrijfactie was. Dit is een gedragsfeit, en zolang u het niet verzamelt, bestaat het simpelweg nergens.

De meeste securitytooling stopt bij permitted. Ze leest uw IAM en vertelt u dat de agent naar de bucket met factuurexports zou kunnen schrijven. Dat is noodzakelijk maar onvoldoende, want “zou kunnen” is een verzameling van duizenden latente mogelijkheden, en een mens kan niet duizenden “misschiens” triëren. Wat het gesprek verandert is observed naast permitted zetten en naar het verschil kijken.

De toegangskaart

Een toegangskaart is de graaf van die verbindingen: voor elke ontdekte agent een verbinding naar elke resource die hij kan bereiken, geannoteerd met wat er daadwerkelijk overheen werd waargenomen. De eenheid die telt is de verbinding, en de belangrijkste annotatie op de verbinding is het onderscheid tussen lezen en schrijven.

R (read) betekent dat de agent gegevens ophaalde zonder die te wijzigen: een SELECT, een GET, een bestand lezen. RW (read/write) betekent dat hij de status muteerde: een INSERT/UPDATE/DELETE, een PUT naar objectopslag, een schemawijziging. De blast radius van die twee is niet vergelijkbaar. Een leesverbinding naar een gevoelige tabel is een blootstellingsvraagstuk. Een schrijfverbinding — vooral een onbedoelde — is een integriteits- en incidentvraagstuk. Ze als dezelfde “toegang” behandelen is precies hoe teams de bevinding missen die er werkelijk toe deed.

Zo ziet de regel van één enkele agent eruit zodra de kaart is opgebouwd:

Kijk naar de eerste regel. De exportjob was bedoeld om uit prod-postgres te lezen en het resultaat naar s3://billing-exports te schrijven. Lezen uit de bron, schrijven naar de bestemming. Maar de credential die hij kreeg verleent RW op de database, en de collector nam waar dat hij schreef naar prod-postgres — een mutatie op het productiesysteem van vastlegging die niemand heeft beoordeeld, bedoeld of momenteel kan verklaren. De kolom permitted zei al die tijd stilletjes dat dit was toegestaan. Dat is de kiem van een incident, in het volle zicht, en zonder de kolom observed valt er niets te signaleren.

Permitted minus observed is gelijk aan drift

De kenmerkende output is het verschil. Least-privilege drift is wat u krijgt wanneer u de ene kolom van de andere aftrekt, en het snijdt aan twee kanten:

• Toegestaan maar nooit waargenomen — de agent kan internal-metrics-api bereiken maar deed dat in het hele observatievenster nooit. Dat is dode scope: een grant die u veilig kunt voorstellen om in te trekken, wat het aanvalsoppervlak verkleint zonder het gedrag te raken.
• Waargenomen buiten wat is beoordeeld — de schrijfactie naar prod-postgres die niemand heeft goedgekeurd. Dit is de veelzeggende bevinding: een actie die plaatsvindt en die, was er bij de toekenning iemand om gevraagd, niet zou zijn goedgekeurd.

De tweede categorie is het belangrijkste risico, en de eerlijke versie van het product verzint die nooit. Elke waargenomen verbinding draagt een confidence-niveau — attributed wanneer de actie aan een specifieke agentidentiteit is gekoppeld met bevestigend signaal, approximate wanneer het bewijs zwakker is. U toont het verschil in plaats van een gok witwassen tot een zekerheid. Een bevinding waar u niet achter kunt staan is erger dan geen bevinding.

Passief ontdekt, per agent toegeschreven

Twee ontwerpkeuzes maken dit betrouwbaar in plaats van zomaar weer een dashboard.

Ten eerste is discovery passief. De collector observeert — logs, OpenTelemetry-traces, database-auditstromen zoals PostgreSQL’s pgAudit, en eBPF op kernelniveau als ground-truth-vangnet — en zit niet in het datapad van de agent. Er is geen verplichte proxy. Als de collector faalt, blijft de agent werken; observability degradeert, de productie niet. Voor een systeem waarvan het hele doel het besturen van kritieke infrastructuur is, ís die asymmetrie het ontwerp: lage keerzijde, hoog signaal.

Ten tweede wordt elke actie toegeschreven aan een specifieke agentidentiteit, niet aan een gedeeld serviceaccount. Dit is het verschil tussen een auditlogboek dat zegt “de exportrol schreef om 02:14 naar prod-postgres” en een dat zegt welke agent dat deed, onder wiens eigenaarschap, tegen welke bedoelde scope. Identiteit per agent is de voorwaarde opdat least-privilege überhaupt iets kan betekenen — zonder dat kan een actie wel worden gezien maar nooit worden herleid tot een verantwoordelijke eigenaar.

De verbindingen en de lees-/schrijffeiten zijn het enige wat wordt opgeslagen. De kaart legt relaties vast — agent naar resource, R of RW — geen payloads, niet de rijen die werden gelezen, geen secrets. Inputs die mogelijk secrets of persoonsgegevens bevatten, worden geredigeerd en op secrets gescand voordat er iets wordt weggeschreven. De graaf is gevoelig juist omdat het een toegangskaart is, en daarom is hij gebouwd om het minimum te bevatten dat governance mogelijk maakt en niets meer.

Signalen uit het eigen ecosysteem van de agent helpen wel, maar worden op zichzelf niet vertrouwd. Een MCP-server kan via annotaties als readOnlyHint adverteren dat een tool alleen-lezen is; volgens de MCP-specificatie zijn die hints untrusted en moeten ze worden bevestigd, nooit blindelings geloofd. De kernelweergave is wat een tool betrapt die alleen-lezen claimde maar toch schreef.

Zodra de kaart bestaat, is de volgende stap handhaving: de exportjob op de database vastpinnen op alleen-lezen, de schrijfactie weigeren, en alarmeren in plaats van louter loggen — beleid toegepast op het moment van toegang, niet gereconstrueerd na het incident.

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"
  }
}

De kaart vertelt u het beleid dat u had moeten schrijven, omdat ze u de ene toegang toont die de agent werkelijk nodig had en de tien die hij nooit gebruikte. Dat is het verschil tussen gissen naar least-privilege en het afleiden uit de ground truth.

Als dit de vraag is die uw omgeving vandaag niet kan beantwoorden — wat kan elke agent bereiken, en wat raakt hij daadwerkelijk aan — dan is dat precies waar de toegangskaart voor is. Het productoverzicht loopt door discovery en het verschil tussen permitted en observed; de architectuur behandelt hoe passieve verzameling, identiteit per agent en het auditlogboek samenkomen zonder ooit in het datapad van uw agents te zitten.