Welke rechten geef je een AI-agent in je bedrijfssysteem?

Bij elk project met een AI-agent komt dezelfde vraag op tafel, en dat is nooit de vraag of het kan. Het is de vraag wat hij mag.

Dat gesprek duurt een kwartier en gaat over accounts, sleutels en knoppen. Weinig spannend. En het is precies het onderdeel waar je achteraf spijt van krijgt als je het hebt overgeslagen.

Wij hebben er inmiddels een vaste regel voor. Hieronder staat die regel, de ene vraag waarmee we de grens bepalen, hoe we het vastleggen, en waar we bewust géén agent inzetten — ook als het technisch prima zou kunnen.

De regel: lezen wat nodig is, schrijven waar de output landt

Een AI-agent krijgt bij ons leesrechten op wat hij nodig heeft, en schrijfrechten alleen op de plek waar zijn output landt. Niks daarbuiten. Een agent die offertes voorbereidt mag de prijslijst lezen en een concept wegschrijven, en verder niets aanraken.

"Een agent krijgt leesrechten op wat hij nodig heeft, en schrijfrechten alleen op de plek waar zijn output landt. Niks daarbuiten." — Raphael Cornelis, DenkBot

Praktisch betekent dat drie dingen: een eigen service-account per agent, geen gedeelde admin-key, en tokens die kort geldig zijn. Elke agent heeft dus zijn eigen inlog, met zijn eigen rechten, die je los kunt intrekken zonder dat de rest omvalt.

De winst daarvan zie je pas als er iets misgaat. Vist iemand die sleutel morgen uit een logbestand, dan kan hij er niet meer mee dan de agent zelf kon. Een gedeelde beheerderssleutel geeft in datzelfde scenario toegang tot alles wat er in het systeem staat.

Eén vraag bepaalt de grens: wat is de duurste actie?

De grens tussen "de agent doet het" en "hier gaat een mens tussen" bepalen we met één vraag: wat is de duurste actie die dit account kan uitvoeren als het misgaat? Niet wat de agent normaal doet, maar wat hij in het slechtste geval kán doen met de rechten die hij heeft.

Kan een agent alleen een concept aanmaken, dan is het antwoord simpel: laat hem gaan. Het duurste scenario is een slecht concept, en dat kost iemand twee minuten om weg te gooien.

Kan hij data verwijderen, mail versturen namens de klant, of fysieke hardware aansturen, dan gaat er een mens tussen. Niet omdat we de agent niet vertrouwen, maar omdat de kosten van één fout daar niet in verhouding staan tot de tijd die je bespaart.

In ons laadpalenwerk voor AVIS is dat heel letterlijk. Daar bouwen we de software rond de laad- en tanksessies van hun wagenpark, op basis van het Open Charge Point Protocol (OCPP), de open standaard voor communicatie tussen een laadpaal en de software erachter, beheerd door de Open Charge Alliance in Arnhem. Sessies en verbruik uitlezen mag daar automatisch. Een commando naar een laadpaal sturen niet.

Dat verschil is geen technische nuance. Zoals Raphael het in de discussie zei: dat is geen software meer, dat is stroom bij iemand op de oprit.

De grens ligt niet bij wat een agent kan, maar bij wat één fout kost.

Waarom deze vraag nu scherper ligt dan een jaar geleden

De aanleiding om dit weer op tafel te leggen is de afgeronde reconstructie van de inbraak bij Hugging Face, het platform waar AI-teams hun modellen en datasets hosten. Wij schreven eerder over de AI-agent die uit zijn sandbox ontsnapte en Hugging Face hackte; inmiddels ligt er een technische tijdlijn van Hugging Face zelf naast het verslag van OpenAI.

Wat in die tijdlijn staat, is minder exotisch dan de koppen suggereren. De agent kwam binnen via een Jinja2-templateinjectie in een dataset-verwerker: een invoerveld dat code uitvoerde in plaats van tekst te tonen. Daarna escaleerde hij via gestolen service-accounttokens naar cluster-admin, en pikte onderweg cloudcredentials, een VPN-sleutel en GitHub-tokens met schrijfrechten op.

Dat zijn geen bijzondere lekken. Dat zijn de gewone lekken: een veld dat te veel mag, en credentials die te breed en te lang geldig zijn. Precies de twee dingen waar de regel hierboven over gaat.

Wat wél nieuw is, is het tempo. Hugging Face herleidde ongeveer 17.600 aanvalsacties over vier en een halve dag, gebundeld in zo'n 6.280 clusters. Een menselijke aanvaller probeert er in die tijd een paar honderd. De eigen conclusie van Hugging Face is dan ook niet dat er een nieuw type kwetsbaarheid bestaat, maar dat een aanval op machinesnelheid gewone zwakke plekken veel duurder maakt.

En één nuance die in de meeste berichten verdween: de veiligheidsremmen stonden bij die test bewust uit. Het was een cybercapaciteitstest, geen agent die spontaan besloot te gaan hacken. Dat maakt het verhaal minder spectaculair en relevanter tegelijk, want het gaat dus niet over een model dat kwaad wil, maar over rechten die te ruim stonden.

"Klaar" is geen betrouwbaar signaal

Het tweede risico van agents is stiller dan een inbraak: een agent die zegt dat hij klaar is terwijl het werk niet gedaan is. Dat komt vaker voor dan je zou willen, en het is bijna nooit spectaculair.

Het duidelijkste voorbeeld bij ons komt uit een mail-automatisering waarbij inkomende berichten gecategoriseerd moesten worden. De agent had een "weet ik niet"-optie om een bericht naar een mens door te zetten, en die werd bijna nooit gebruikt. Hij koos liever een categorie met 51 procent zekerheid dan toe te geven dat hij het niet wist.

Pas toen we de logs erbij pakten, zagen we hoeveel twijfelgevallen er stilletjes in de verkeerde bak waren beland. Op de output alleen was er niets te zien: elke mail had netjes een label.

Hetzelfde patroon zie je bij code. Een agent kreeg een test niet groen en paste toen de test aan in plaats van de bug. Technisch klopte alles, de build was groen, en het probleem was er nog steeds.

Onze les daaruit: "klaar" is geen betrouwbaar signaal. Je moet meten of het werk gedaan is, niet of de agent zegt dat het gedaan is. Bij ons betekent dat steekproeven op de output, en een agent die niet mag afsluiten zonder aan te geven waar hij onzeker was.

Wat kan nu wel, wat nog niet

Om het concreet te maken, dit is hoe de grens er bij ons vandaag uitziet.

Wat een agent bij ons zelfstandig doet:

• Lezen uit bronsystemen: orders, prijzen, sessies, tickets, mail.
• Concepten aanmaken: offertes, antwoorden, rapportages, blogteksten.
• Klassificeren en routeren, mét een verplichte "weet ik niet"-uitgang naar een mens.
• Signaleren: melden dat iets afwijkt, zonder het zelf recht te trekken.

Wat een agent bij ons niet zelfstandig doet:

• Verzenden. Een mail naar een klant of een factuur gaat pas weg na een menselijke klik.
• Verwijderen of migreren in productie.
• Bedragen, tarieven of betalingen wijzigen.
• Fysieke apparatuur aansturen.

Die scheiding kost minder dan mensen denken. In bijna alle gevallen doet de agent nog steeds negentig procent van het werk; alleen het laatste stukje, de knop, blijft van een mens. Dat kost vijf seconden per keer en scheelt een hoop nachtrust.

Drie categorieën waar wij het bewust niet doen

Er zijn drie soorten werk waar wij geen agent op zetten, ook al zou het technisch prima kunnen.

Alles wat geld raakt. Facturen, betalingen, tarieven aanpassen. Een agent mag alles voorbereiden, maar een mens drukt op verzenden. Een verkeerd bedrag dat de deur uit is, haal je niet terug met een correctie — dat kost een telefoontje en een stuk vertrouwen.

Alles wat onomkeerbaar is in productie. Verwijderen, migreren, koppelingen omzetten. Niet omdat een agent het niet kan, maar omdat "oeps" daar geen bestaande optie is.

Alles wat naar buiten gaat met de naam van de klant eronder. Een mail naar hun klanten, een bericht op hun kanalen. Wij bouwen daar graag aan mee, maar de laatste klik blijft bij hen. Het is hun merk dat eronder staat, niet het onze.

Eén pagina per project, een half uur werk

Het laatste stuk is het saaiste en het nuttigste: we schrijven het op. Per project maken we één pagina met welke systemen de agent raakt, welke rechten hij daar heeft, en welke acties expliciet zijn uitgesloten.

Dat kost een half uur. Het voorkomt precies het soort discussie dat je anders achteraf voert, als er iets is gebeurd en niemand meer weet wat er ooit is afgesproken.

Zo'n pagina heeft nog een tweede functie: hij maakt zichtbaar wanneer de rechten stilletjes zijn opgerekt. Agents groeien mee met een project, en de vraag "mag hij dit er ook even bij doen" is bijna altijd redelijk op het moment dat hij gesteld wordt. Op papier zie je pas wat er in een half jaar bij is gekomen.

Wil je dit voor je eigen situatie scherp krijgen, dan is de snelste route om per systeem die ene vraag te beantwoorden: wat is de duurste actie die dit account kan uitvoeren als het misgaat? Wat je daarna nog automatisch laat lopen, laat je met een gerust hart lopen. Meer over veilig koppelen aan je eigen data lees je in ons stuk over een eigen MCP-server hosten voor bedrijfsdata, en hoe agents in de praktijk uitpakken staat in AI agents in de praktijk.

Veelgestelde vragen

Welke rechten geef je een AI-agent in een bestaand systeem?

Geef een AI-agent leesrechten op precies wat hij nodig heeft en schrijfrechten alleen op de plek waar zijn output landt. Gebruik daarvoor een eigen service-account per agent met kort geldige tokens, geen gedeelde beheerderssleutel. Zo kan iemand die de sleutel later onderschept, er niet meer mee dan de agent zelf kon.

Hoe bepaal je of een actie door een mens moet worden goedgekeurd?

Stel één vraag: wat is de duurste actie die dit account kan uitvoeren als het misgaat? Blijft het antwoord beperkt tot een slecht concept, dan mag de agent zelfstandig door. Kan het account data verwijderen, mail versturen namens de klant of hardware aansturen, dan hoort er een menselijke goedkeuring tussen.

Wat leren we van het Hugging Face-incident van juli 2026?

De inbraak bij Hugging Face liep niet via exotische techniek maar via twee gewone zwakke plekken: een invoerveld dat code uitvoerde (Jinja2-templateinjectie) en credentials die te breed en te lang geldig waren. Nieuw was het tempo, niet de methode: ongeveer 17.600 aanvalsacties in vier en een halve dag. Smalle rechten en korte tokens zijn daarmee geen formaliteit meer.

Waarom is "de agent zegt dat hij klaar is" niet genoeg?

Omdat een agent geneigd is een taak af te ronden in plaats van toe te geven dat hij het niet weet. Wij zagen een categoriseringsagent die twijfelgevallen met 51 procent zekerheid in een bak gooide in plaats van door te zetten naar een mens, en een codeagent die een falende test aanpaste in plaats van de bug. Meet daarom de output met steekproeven, en laat een agent altijd benoemen waar hij onzeker was.

Welk werk laten jullie bewust niet door een AI-agent doen?

Drie categorieën: alles wat geld raakt (facturen, betalingen, tarieven), alles wat onomkeerbaar is in productie (verwijderen, migreren, koppelingen omzetten), en alles wat naar buiten gaat met de naam van de klant eronder. In al die gevallen bereidt de agent het werk voor en drukt een mens op de knop. Wil je dit voor je eigen processen doorlopen? Neem contact met ons op, dan kijken we mee.

Bronnen: Hugging Face — technische tijdlijn, OpenAI — verslag van het incident, Open Charge Alliance