Least privilege is een van de oudste en betrouwbaarste ideeën in de beveiliging. Geef een identiteit precies de toegang die ze nodig heeft, niets meer, en de blast radius van elke compromittering blijft klein. Voor menselijke accounts en langlevende serviceaccounts houdt het model redelijk stand: rollen worden beoordeeld, rechten worden afgebakend en toegangscertificeringen lopen op kwartaalbasis.
AI-agents doorbreken dit model in stilte. Een agent krijgt een credential, een tool, een MCP-serververbinding, en vanaf dat moment is zijn gedrag dynamisch. Hij beslist tijdens runtime welke resources hij leest, welke hij schrijft, welke tool hij vervolgens aanroept. De grant die u op dag één hebt opgeschreven beschrijft een plafond, niet wat de agent doet. En omdat agents productief zijn, is dat plafond doorgaans royaal: brede databaserollen, schrijftoegang “voor de zekerheid”, een serviceaccount dat over een half dozijn workflows wordt gedeeld. Het resultaat is een landschap waarin de toegestane toegang en de daadwerkelijk gebruikte toegang elke dag stilletjes uit elkaar drijven.
Onafhankelijk branche-onderzoek brengt de omvang van de blinde vlek in kaart: ongeveer 82% van de organisaties meldt AI-agents te hebben draaien waarvan ze het bestaan niet kenden, terwijl slechts ongeveer 21% een realtime-inventaris ervan bijhoudt (CSA/Token Security, n=418). U kunt geen least privilege afdwingen op een landschap dat u niet kunt zien.
Least-privilege drift gedefinieerd
Laat ik het verschijnsel precies benoemen. Least-privilege drift is de groeiende kloof tussen de toegang die een agent mag hebben en de toegang die hij blijkt te gebruiken. Het kent twee faalrichtingen, en slechts één daarvan is voor de hand liggend.
De voor de hand liggende richting is onderbenutting: een agent heeft schrijftoegang tot een tabel waarnaar hij nooit heeft geschreven. Dat is een ongebruikt privilege, en het is risico dat u zonder enig voordeel met u meedraagt. De gevaarlijke richting is het omgekeerde signaal dat het impliceert: wanneer de waargenomen verzameling iets bevat dat de toegestane verzameling nooit bewust heeft toegekend, vindt er een actie plaats die niemand heeft beoordeeld. Een exportjob die plotseling schrijft naar een bucket waaruit hij voorheen alleen las. Een agent die door beleid tot één schema is afgebakend en zich uitstrekt naar een ander. Dit zijn geen exotische gevallen; het is de alledaagse werkelijkheid van agents die met grofkorrelige rechten aan elkaar worden geknoopt.
De reden dat dit lastig is, en de reden dat het specifiek is voor agents in plaats van mensen, is dat het gedrag wordt gegenereerd, niet geconfigureerd. Een mens met te veel toegang maakt er meestal geen gebruik van. Een agent met te veel toegang gebruikt alles wat hem helpt de taak die voor hem ligt af te ronden, inclusief paden die niemand had voorzien. Statische beleidsbeoordeling kan gedrag dat per run verandert niet bijbenen.
Drift omzetten in een toetsbaar signaal
Drift is alleen gevaarlijk zolang het onzichtbaar is. De opgave is het tot een signaal te maken dat een mens kan beoordelen, en daarvoor zijn twee dingen nodig die samenwerken: voortdurende observatie van wat agents werkelijk aanraken, en een stabiel register van wat ze mochten aanraken.
De observatie moet read-first zijn. Een collector die observeert uit logs, OpenTelemetry-traces en eBPF-kernelsignalen zit buiten het datapad van de agent. Hij is geen proxy, hij houdt geen calls tegen, en als hij faalt, faalt hij open in de veilige zin: de agent blijft werken, u verliest zichtbaarheid in plaats van beschikbaarheid. Die asymmetrie is van belang: een beveiligingsmaatregel die de productie kan platleggen, is een maatregel die teams stilletjes uitschakelen. De eBPF-laag fungeert in het bijzonder als ground truth op kernelniveau, het deel waar een agent niet omheen kan, en daarom worden hints op protocolniveau zoals MCP-toolannotaties (readOnlyHint, destructiveHint) eraan getoetst in plaats van vertrouwd. De MCP-specificatie zelf stelt dat die annotaties niet te vertrouwen zijn; kernelsignalen maken de toetsing pas echt.
Wat de observatie oplevert, is een access map: voor elke agent, welke resources hij heeft bereikt en of hij las (R) of las/schreef (RW). De map slaat toegangsrelaties op, geen payloads, secrets of PII. Het interessante deel is de diff:
| Agent | Resource | Toegestaan | Waargenomen | Drift |
|---|---|---|---|---|
| data-export-job | prod-postgres | R | R | geen |
| data-export-job | s3://billing-exports | R | RW | niet-beoordeelde write |
| report-builder | analytics-db | R | (ongebruikt) | ongebruikt privilege |
De regel die telt, is de middelste. Beleid kende leesrecht toe op de exportbucket; de collector nam een write waar. Die ene regel is het belangrijkste risico dat least-privilege drift moet blootleggen: een uitgeoefend privilege dat niemand heeft beoordeeld, toegeschreven aan een specifieke agent in plaats van aan een gedeeld serviceaccount, want identiteit per agent is wat de toeschrijving en de audit überhaupt mogelijk maakt.
Afdwingen op het moment van toegang, niet alleen loggen
Detectie vertelt u dat drift heeft plaatsgevonden. Om de cirkel te sluiten, wilt u dat de niet-beoordeelde write een geweigerd pad wordt, geen gelogd pad. Daar komt policy-as-code in beeld, geëvalueerd op het moment van toegang. Dezelfde diff die de drift signaleerde, wordt de regel die hem voorkomt.
Overweeg de exportjob te beperken tot alleen-lezen op de productiedatabase en writes ronduit te weigeren, met een overtreding die blokkeert en waarschuwt in plaats van geruisloos door te laten:
agent "data-export-job" {
# Read-only on the operational database. No writes, ever.
access "prod-postgres" {
mode = "read"
deny = ["write", "delete", "ddl"]
}
# The export target the job is *supposed* to use.
access "s3://billing-exports" {
mode = "read"
}
on_violation {
action = "block" # deny the call at access time
alert = "security-oncall"
audit = "append" # write to the tamper-evident ledger
}
}Loop het voor en na concreet door.
Voor. De exportjob, in het bezit van een brede rol, doet een write naar s3://billing-exports. Niets houdt hem tegen. De actie slaagt, gaat op in het normale verkeer en duikt dagen later op, als het al gebeurt, als een anomalie in de access map. De kloof tussen toegestaan en waargenomen is groter geworden, en het enige artefact is een logregel die niemand heeft gelezen.
Na. Dezelfde write komt binnen. Beleid wordt geëvalueerd op het moment van toegang, ziet write op een resource die is afgebakend tot read, en geeft een weigering terug voordat de operatie landt. De overtreding blokkeert de call, geeft een waarschuwing aan de on-call-rotatie en voegt een entry toe aan het append-only, hash-geketende auditlogboek. De niet-beoordeelde write wordt nooit een niet-beoordeelde wijziging. De drift wordt op dat moment teruggebracht tot een least-privilege-pad.
Twee eigenschappen houden dit eerlijk. Ten eerste wordt elke geprivilegieerde blik op de access map zelf geaudit, wie keek naar wat, want de map is gevoelig en een beveiligingstool dat geen verantwoording kan afleggen over zijn eigen operators is niet betrouwbaar. Ten tweede wordt vertrouwen helder getoond: een actie die op grond van bewijs op kernelniveau aan een agent wordt toegeschreven, wordt anders gemarkeerd dan een die bij benadering is afgeleid. U wordt nooit gevraagd te handelen op basis van een valse zekerheid.
De kernboodschap
Least privilege faalde niet voor AI-agents; de beoordelingscadans faalde. Rechten zijn grofkorrelig, gedrag is dynamisch, en kwartaalcertificeringen kunnen een toegangsoppervlak dat bij elke run verandert niet volgen. De oplossing is geen zwaardere proxy in het kritieke pad. Het is voortdurende, read-first observatie die een toegestaan-versus-waargenomen diff oplevert, plus policy-as-code die de gecorrigeerde grens afdwingt op het moment van toegang, zodat een te ruim geautoriseerde agent als toetsbaar signaal wordt opgespoord lang voordat het een incident wordt.
Wilt u zien hoe de collector, de access map en handhaving op het moment van toegang in elkaar passen zonder in het datapad van uw agents te zitten, dan loopt de architectuur-pagina het ontwerp door, en het product toont hoe de toegestaan-versus-waargenomen weergave eruitziet op een echt landschap.