Welke permissies geef je AI-agenten in je bedrijf eigenlijk

Waarom AI-agenten toestemming kregen om zelfstandig te handelen

Op 26 augustus 2026 werd Claude in Chrome algemeen beschikbaar, en de echte verandering was niet de extensie zelf, maar het feit dat AI-agents acties in de browser kunnen uitvoeren zonder goedkeuring bij elke stap — tot dan toe vroeg elke klik om expliciete bevestiging van de gebruiker. Die verschuiving staat niet op zich: de hele sector is het afgelopen jaar opgeschoven van „betere modellen” naar „agents die het werk doen”, met steeds ruimere rechten en steeds minder toezicht stap voor stap, in production-grade applicaties met geheugen en echte tools, niet alleen gesprekken in een chatvenster.

Voor een bedrijf in Roemenië dat een AI-agent overweegt — voor marketing, voor support, voor interne processen — betekent dit een nieuwe vraag, die „installeren we hem of niet” niet meer dekt: hoeveel handelingsvrijheid krijgt die agent eigenlijk, en wie bepaalt waar de grens ligt? Het serieuze antwoord is niet „zoveel mogelijk autonomie”, maar een expliciete grens, vastgelegd voordat de agent aan het werk gaat, niet ontdekt na het eerste incident.

„Agents Rule of Two”: de eenvoudige regel die rampen voorkomt

Meta publiceerde op 31 oktober 2025 een eenvoudig framework genaamd „Agents Rule of Two”, precies bedoeld voor bedrijven zonder een team dat specifiek is toegewijd aan de beveiliging van AI-agenten. De regel identificeert drie risicovolle vermogens die een agent kan hebben: het verwerken van onveilige content (afkomstig van internet, een e-mail of een extern document), toegang tot gevoelige data of systemen, en het vermogen om een status te wijzigen of naar buiten te communiceren — een e-mail versturen, een betaling doen, iets publiceren. De regel zegt simpelweg: een agent mag maximaal twee van deze drie hebben, zonder direct menselijk toezicht.

Als een agent alle drie tegelijk heeft — hij leest onveilige content, heeft toegang tot privégegevens en kan naar buiten toe handelen — zonder tussen de stappen een nieuwe sessie te starten, zou hij niet volledig autonoom mogen draaien. In dat geval beperk je ofwel een van de drie vermogens, ofwel voer je een expliciete stap van menselijke goedkeuring in vóór de uiteindelijke actie. Het is een regel simpel genoeg om zelf te controleren, zonder beveiligingsadvies, voor elke agent die je overweegt in productie te nemen.

Wat de „Rule of Two” betekent voor de permissies van de agenten in jouw bedrijf

Een concreet voorbeeld: een agent die binnenkomende e-mails leest en automatisch verstuurde antwoorden opstelt, heeft twee van de drie capaciteiten — hij verwerkt onveilige content (binnenkomende e-mails kunnen verborgen instructies bevatten) en handelt naar buiten toe (hij verstuurt antwoorden). Als die agent daarnaast geen toegang heeft tot andere gevoelige systemen van het bedrijf, blijft de combinatie, volgens de regel, binnen een acceptabele zone voor autonomie, met normale monitoring.

De situatie verandert radicaal als diezelfde agent ook toegang krijgt tot de bankrekening van het bedrijf of de klantendatabase — dan komt er een derde capaciteit bij, en vereist de volledige combinatie ofwel het schrappen van een van de drie, ofwel een stap van menselijke bevestiging vóór elke onomkeerbare actie. Het verschil tussen een „nuttige agent” en een „veiligheidsrisico” zit niet in hoe geavanceerd het onderliggende model is, maar in de exacte combinatie van toegang die je hem hebt gegeven — vaak zonder daar expliciet bij stil te staan.

Waarom het precies nu telt: injection blijft onopgelost

De reden waarom deze regel precies nú telt, en niet over twee jaar, is dat de industrie toestemming kreeg om autonoom te handelen voordat er een volledige oplossing was voor prompt injection — de techniek waarbij verborgen tekst, geplaatst op een webpagina of in een document, de instructies van een agent kaapt. Het OWASP-rapport over agentic applicaties toont dat prompt injection is gekoppeld aan zes van de tien categorieën van de Top 10 Agentic, en van de drieënvijftig gevolgde agentic projecten zijn er achtentwintig zelfs programmeertools — precies de klasse instrumenten waarmee een softwareontwikkelbedrijf dagelijks werkt.

De praktische conclusie is niet om AI-agents te vermijden, maar om ze niet als een gewone chatbot te behandelen: een agent die onbewaakt op het web kan navigeren of documenten van derden kan lezen, erft precies het risico dat de sector nog actief beheerst. Grenzen aan rechten zijn geen nutteloze bureaucratie — ze zijn het directe antwoord op een reële, gedocumenteerde kwetsbaarheid, niet een hypothetische of een die door de pers wordt overdreven.

Wat de wet vereist: art. 50 van de AI Act, kort samengevat

Sinds 2 augustus 2026 is artikel 50 van de Europese AI Act van toepassing, dat transparantieverplichtingen invoert voor elk interactief systeem en voor door AI gegenereerde synthetische content — concreet moet een chatbot of agent de gebruiker duidelijk laten weten dat hij met een automatisch systeem spreekt, niet met een mens. De overgangstermijn voor de markering (watermarking) van content gegenereerd door systemen die vóór 2 augustus op de markt zijn gebracht, loopt tot 2 december 2026, en de verplichtingen voor hoogrisicosystemen blijven uitgesteld tot 2027-2028.

Voor een bedrijf dat al AI-gegenereerde visuals of video gebruikt in presentatiemateriaal of op de site — hero's, productvisuals — betekent dit een eenvoudige maar noodzakelijke check: voldoet die content aan de labelplicht? Het is geen dramatische procesverandering, maar wel het soort detail dat, als je het negeert, een compliance-probleem wordt dat makkelijk te vermijden is als je het op tijd aanpakt, in plaats van het pas te ontdekken bij een controle.

Het verborgen risico: de skills die je voor je agent installeert

Een apart, maar verwant deel van het risico komt van het materiaal waaruit agenten zijn opgebouwd: skills — tekstinstructies die je installeert om uit te breiden wat een agent kan doen. Snyk analyseerde bijna vierduizend publieke skills en vond bij meer dan een derde ten minste één beveiligingsprobleem, en de aparte analyse van NVIDIA vond echte kwetsbaarheden bij ongeveer een kwart van de steekproef. Een eerlijkheidsnotitie telt hier mee: de titel van het Snyk-rapport spreekt over „prompt injection” als groot aandeel, maar hun tabel toont dat injection maar een klein deel van het totaal vormt — de rest zijn andere, verschillende probleemcategorieën.

De praktische conclusie is simpel: een skill is geen onschuldig tekstbestand, maar erft de toegang van de agent tot omgevingsvariabelen, API-sleutels en gevoelige mappen. Voordat je een pakket skills van een onbekende marketplace installeert, loont het om het door een dedicated scanner te halen, net zoals je elke nieuwe code-dependency zou scannen voordat je die in productie zet — de beveiligingspraktijk uit softwareontwikkeling geldt hier identiek, het is geen apart domein.

Een praktische checklist voordat je een AI-agent zelfstandig laat handelen

Voordat je een AI-agent autonoom laat werken in je bedrijf, verkleinen een paar eenvoudige controles het risico aanzienlijk, zonder dat daar een apart securityteam of geavanceerde technische kennis voor nodig is — alleen de discipline om ze telkens te doorlopen wanneer je die agent een nieuwe capaciteit geeft of een extra tool koppelt. De lijst hieronder is bedoeld om in een paar minuten te doorlopen, niet als formele security-audit.

De checklist vervangt geen bredere veiligheidsdiscussie als die agent toegang heeft tot financiële operaties of gevoelige persoonsgegevens van klanten — in die gevallen loont het om iemand met specifieke ervaring in AI-agentbeveiliging te betrekken, niet alleen technisch gezond verstand. Voor de meeste gewone interne processen dekken deze vijf controles echter het grootste deel van het werkelijke risico, tegen een tijdskost die bijna verwaarloosbaar is vergeleken met wat ze voorkomen.

• 01Somt de drie vermogens expliciet op: privégegevens, onveilige content, externe actie
• 02Controleer of de agent alle drie tegelijk heeft, zonder nieuwe sessie ertussen
• 03Voeg een stap van menselijke goedkeuring toe voor elke onomkeerbare actie
• 04Scan elke geïnstalleerde skill of plugin voordat je hem in productie zet
• 05Controleer of alle gegenereerde synthetische content aan de markeringsverplichting voldoet

Veelgemaakte fouten bij het invoeren van AI-agenten in je bedrijf

De meest voorkomende fout is een AI-agent behandelen als een gewone productiviteitstool, zonder enige expliciete discussie over welke toegang hij krijgt — hij wordt geïnstalleerd, krijgt credentials „zodat het sneller gaat”, en de grens van de permissies komt nooit als gespreksonderwerp ter sprake. De tweede fout is aannemen dat een „betrouwbare” leverancier de noodzaak van eigen verificatie wegneemt — de regel van twee op drie geldt ongeacht wie de agent heeft gebouwd, want het risico komt uit de combinatie van toegang, niet uit de kwaliteit van het onderliggende model.

De derde fout, op lange termijn de duurste, is het uitstellen van het gesprek over rechten en toestemmingen tot na een incident — een verkeerd verstuurde e-mail, een actie uitgevoerd op basis van gemanipuleerde content, een datalek. De kost om de grenzen meteen vast te leggen, is bijna nul; de kost om ze pas vast te leggen nadat iets is misgegaan, omvat bijna altijd ook het herstellen van verloren vertrouwen, niet alleen van het getroffen technische systeem.

Bronnen en verder lezen.

• 01Meta AI Blog — Agents Rule of Two: A Practical Approach to AI Agent Security
• 02Help Net Security — OWASP prompt injection AI security failures
• 03Latham & Watkins — AI Act update: EU resolves to change rules and extend deadlines
• 04Snyk — ToxicSkills: malicious AI agent skills on ClawHub
• 05Help Net Security — SkillSpector: open-source agent skill security scanner
• 06Simon Willison — Prompt injection (ongoing coverage)

Veelgestelde vragen

Het team van The Niche SocietyAI- en software-engineers uit Boekarest · LinkedIn

gepubliceerd 2026-09-09