Jullie AI-agent mag alles. Dat is geen autonomie.

Wat er gebeurde

Een team waar ik mee werkte wilde “één agent voor de hele klantflow”. De demo was indrukwekkend. De agent las CRM, schreef follow-ups, boekte slots in de agenda, pakte bijlagen uit Drive en kon in een later pad ook een factuurtrigger raken. Alles via dezelfde tool-stack. “Autonoom”, stond op de roadmap.

Tot er iets misging dat niemand als security-incident herkende. Een vage instructie, een verkeerd geïnterpreteerde klantmail, een tool-call te veel. Geen dramatiek zoals een sandbox-escape in het nieuws. Wel een mail die niet had mogen gaan, een veld dat niet had mogen wijzigen, en een auditlog die vooral liet zien: de agent mocht dit technisch gewoon.

Niemand had bewust “alles geven” gekozen uit kwaadwilligheid. Ze wilden geen frictie. Elke extra scope scheelde een ticket. Elke gedeelde service-account scheelde een login. Tot de blast radius groter was dan de taak die de agent eigenlijk deed.

Ik zie dit bij compacte teams én bij grotere organisaties. Niet omdat mensen naïef zijn. Omdat autonomie wordt verward met open deuren. En omdat een Approve-knop later (als die er al is) de verkeerde rechten niet kleiner maakt. Dat is een ander probleem dan human-in-the-loop als theater. Hier gaat het om wat de agent überhaupt mag aanraken.

Als je agent alles mag, heb je geen autonomie ontworpen. Je hebt alleen de sleutelbos laten liggen.

Waarom AI-agent rechten nu relevant zijn

Least privilege is oud nieuws voor mensen en services. Bij agents wordt het opeens “vertraging”. Dat is een gevaarlijke ruil. Los van runtime-quarantaine of sandbox-nieuws blijft de kern organisatorisch: welke business-tools mag deze agent identity überhaupt gebruiken? Een agent die tools kiest op basis van taal, hallucinatie of gemanipuleerde context, heeft niet jouw intentie. Hij heeft jouw scopes.

OWASP LLM06:2025 Excessive Agency benoemt precies dit: te veel functionaliteit, te veel permissions, te veel autonomie. De mitigatie is saai en effectief. Beperk tools tot wat de taak nodig heeft. Geef downstream systemen minimale rechten. Laat high-impact acties niet stilzwijgend doorlopen.

NIST AI RMF vraagt om risico’s te mappen en te managen over de levenscyclus. Voor agents vertaalt dat concreet naar: welke acties zijn mogelijk, wat is de impact, wie autoriseert, hoe log je tool-calls. Zonder die kaart blijft “autonome agent” een marketingzin.

Drie plekken waar te ruime AI-agent rechten het hardst pijn doen:

• Gedeelde god-tokens. Eén service-account voor CRM, mail en files. Handig in de demo. Onbruikbaar als je ooit wilt weten wie wat mocht.
• Write waar read genoeg is. De agent moet een status lezen, maar mag records updaten, verwijderen of exporteren. Dat is geen feature. Dat is een onnodige deur.
• Betalen en versturen in dezelfde rol als zoeken. Zodra geld, externe mail of productie-wijzigingen in dezelfde identity zitten als research-tools, is elke fout duur.

Dit raakt governance lichter dan een heel AI-beleid, maar zwaarder dan een prompt in Slack. Zelfde volwassenheidstest als bij prompt versiebeheer: het label klinkt modern, het ontwerp niet. En zonder baseline weet je niet of “meer tools” überhaupt iets oplevert, zoals bij ROI zonder baseline.

Wat je nu kunt doen: AI-agent rechten die wél kloppen

Geen nieuw platform als eis. Wel zes gewoonten die van een sleutelbos weer een ontwerp maken.

1. Schrijf de taak vóór de tool-lijst. Eén zin: wat moet de agent afronden? Alles wat die zin niet nodig heeft, valt weg. “Misschien later handig” is geen scope.
2. Splits identities per impact. Read-CRM is een andere identity dan write-CRM. Mail-draft is iets anders dan mail-send. Betalen krijgt nooit dezelfde token als zoeken.
3. Least privilege downstream, niet alleen in de prompt. Een zin “je mag niet verwijderen” stopt geen API die delete toelaat. Rechten horen in het systeem dat de actie uitvoert.
4. Tijdgebonden en intrekbaar. Tijdelijke credentials, korte TTL, revoke-pad. Als een agent-rol weken open blijft staan “omdat het werkt”, groeit je blast radius stil.
5. Log tool-calls alsof het productie is. Welke tool, welke scope, welk object, welk resultaat. Zonder die trail kun je na een fout alleen gissen. Met die trail kun je scopes aanscherpen.
6. Meet blast radius bewust. Vraag: wat is het ergste dat één gemanipuleerde of foute run kan doen? Als het antwoord “klantenbestand plus mailbox plus betalingen” is, heb je geen agent. Je hebt een onbeheerde admin.

Wat “goed genoeg” vandaag al is

Je hoeft geen zero-trust theater te bouwen. Begin met één agent-flow: taak op papier, toolset tot het minimum, aparte read/write identities, logging aan, één revoke-knop. Dat is al serieuze autonomie. Autonomie binnen grenzen, niet ondanks grenzen.

Voor agents die je wilt laten werken zonder de hele stack open te zetten, helpt vaak gerichte AI-modeloptimalisatie of managed AI-agents meer dan nóg een connector. Wil je rechten en oversight laten aansluiten op jullie risico’s? De EU AI Act deployer quick scan of een kort gesprek via contact is een nuchter startpunt.