Van intelligentie naar bevoegdheid

Kunstmatige intelligentie beperkt zich niet langer tot het beantwoorden van vragen en het genereren van content. AI-systemen kunnen steeds vaker instructies interpreteren, plannen opstellen, tools selecteren en taken uitvoeren zonder voortdurende menselijke aansturing.

Dat onderscheid is belangrijk.

Een AI-systeem dat acties aanbeveelt, verschilt van een systeem dat bevoegd is om ze uit te voeren. Het verschil zit niet noodzakelijkerwijs in de intelligentie of geavanceerdheid. Het gaat om de bevoegdheid.

Autonome systemen beperken zich niet tot de meest geavanceerde grote taalmodellen. Het gaat ook om gespecialiseerde machineleersystemen, robotica, autonome voertuigen, softwareagenten en combinaties van technologieën die binnen vastgestelde gebruiksomstandigheden zelfstandig beslissingen nemen of handelingen uitvoeren.

De mogelijke voordelen ervan zijn aanzienlijk. Ze kunnen bijdragen aan wetenschappelijke ontdekkingen, industriële processen, de gezondheidszorg, softwareontwikkeling en cyberbeveiliging. Ze kunnen ook onbedoelde gevolgen hebben, gevoelige informatie blootleggen of acties in gang zetten die verder gaan dan hun operators bedoelden.

In Beveiligingsuitdagingen bij het ontwerpen van autonome systemen onderzoeken Mohammad Hamad en Sebastian Steinhorst beveiligingsuitdagingen rond autonome incidentrespons, risicobeoordeling, toegangscontrole, de betrouwbaarheid van gegevens en interacties tussen autonome systemen. Hun onderzoek, dat grotendeels betrekking heeft op cyberfysieke systemen, laat zien dat de uitdagingen van het beveiligen van zelfstandig handelende machines verder reiken dan de huidige LLM-agenten.

De bredere gevolgen van autonomie verdienen serieuze aandacht, waaronder de kans op fysieke schade. Bewijs moet echter zorgvuldig worden geïnterpreteerd. Incidenten met geautomatiseerde voertuigen kunnen bijvoorbeeld niet zonder meer worden toegeschreven aan dezelfde mechanismen als die bij autonome cyberbeveiligingsagenten. De mate van autonomie, de gebruiksomstandigheden, de betrokkenheid van mensen en het causale bewijs zijn van belang.

Evenzo bewijst het feit dat autonome AI schade kan veroorzaken niet dat de governance noodzakelijkerwijs achterloopt. We moeten ook niet aannemen dat autonome systemen van nature moeilijk te beveiligen zijn.

De kernvraag is niet of AI complex werk kan uitvoeren, maar of de architecturale, beveiligings- en organisatorische kaders voor autonome systemen passende grenzen kunnen stellen aan gedelegeerde bevoegdheden en controleerbaar bewijs kunnen leveren dat die grenzen worden gerespecteerd.

Cyberbeveiliging biedt een bijzonder nuttig perspectief op deze vraag, omdat beveiligingsprofessionals al tientallen jaren aannames over vertrouwen, machtigingen, toegang en systeemgedrag kritisch onderzoeken.

Het kat-en-muisspel op machinesnelheid

Cyberbeveiliging wordt al lange tijd omschreven als een kat-en-muisspel.

Aanvallers ontdekken zwakke plekken, verdedigers voeren beveiligingsmaatregelen in en beide partijen passen zich aan. Die cyclus gaat door terwijl technologieën, tactieken en gebruiksomgevingen veranderen.

Autonome AI verandert niet noodzakelijkerwijs de fundamentele regels van dat spel. Mogelijk verandert wel wie — of wat — eraan deelneemt, hoe snel er wordt gehandeld en hoeveel werk kan doorgaan zonder voortdurende menselijke tussenkomst.

Een autonoom systeem voor offensieve beveiliging kan blootgestelde diensten opsporen, kwetsbaarheden onderzoeken, mogelijke aanvalspaden ontwikkelen en testen of die paden kunnen worden uitgebuit. Een defensief systeem kan vergelijkbare mogelijkheden inzetten om bedreigingen te onderzoeken, zwakke plekken op te sporen en herstelmaatregelen te valideren.

Dit potentieel voor tweeërlei gebruik is essentieel om de beveiligingsimplicaties van autonome AI te begrijpen.

Project Glasswing van Anthropic is een voorbeeld van AI-ondersteunde ontdekking van kwetsbaarheden. In de onderzoeksupdate van mei 2026 meldde Anthropic aanzienlijke resultaten bij het opsporen van kwetsbaarheden en benadrukte het tegelijk de operationele uitdagingen rond verificatie, openbaarmaking en het uitbrengen van patches.

Dat onderscheid is belangrijk. Een kwetsbaarheid ontdekken is niet hetzelfde als bevestigen dat deze kan worden uitgebuit, de kwetsbaarheid verhelpen of aantonen dat het getroffen systeem veilig is.

Meer bevindingen kunnen het inzicht vergroten en tegelijkertijd de druk opvoeren op de mensen en processen die verantwoordelijk zijn voor het oplossen ervan.

De beveiligingsuitkomst hangt af van wat er daarna gebeurt.

Als aanvallers en verdedigers delen van hun werk kunnen automatiseren, is de relevante vraag niet simpelweg welke partij het meest capabele model heeft. Het gaat erom of verdedigers ontdekkingen kunnen omzetten in effectieve herstelmaatregelen en de resultaten onafhankelijk kunnen verifiëren.

Traditionele penetratietests raken niet achterhaald doordat AI offensieve taken kan uitvoeren. De reikwijdte ervan moet worden uitgebreid met systemen die instructies interpreteren, tools aanroepen, machtigingen combineren en doelen nastreven in meerdere stappen.

Het doel blijft vertrouwd: zwakke plekken opsporen, hun betekenis vaststellen, ze verhelpen en aantonen dat de beveiligingsmaatregelen werken.

Architecturale raakvlakken: waar beveiligingsgrenzen samenkomen

Een van de subtielere risico’s van autonome systemen ontstaat wanneer afzonderlijk geautoriseerde componenten op manieren samenwerken die onbedoelde gevolgen hebben.

Ik noem deze interactiepunten architecturale naden.

Neem een conventioneel voorbeeld. Een organisatie beperkt de toegang tot een bestand met NTFS-machtigingen. Een afzonderlijke clouddeeldienst staat een geautoriseerde gebruiker toe die informatie extern te delen.

Elk systeem kan volgens zijn eigen regels werken. Toch kan hun interactie leiden tot het delen van informatie op een manier die de beoogde beveiligingsgrens van de organisatie schendt.

Dit is een voorbeeld van mogelijk tegenstrijdig beleid, geen bewering dat een bepaald product voor het delen van bestanden kwetsbaar is.

Het probleem hoeft niet te liggen in een gebrek van een van beide maatregelen afzonderlijk. Het kan gaan om een tekortkoming bij het handhaven van het beoogde beveiligingsbeleid in de volledige workflow.

Bij het verbinden van modellen, applicaties, identiteiten, tools, repositories en externe diensten kan autonome AI met vergelijkbare situaties te maken krijgen.

Een agent kan toestemming hebben om een document te lezen, een repository aan te maken en bestanden te uploaden. Dat betekent niet noodzakelijkerwijs dat de agent bevoegd is om die handelingen te combineren op een manier waardoor vertrouwelijke informatie wordt blootgesteld.

Onderzoek biedt een praktische reden om deze interacties onder de loep te nemen.

In AgentDojo evalueerden onderzoekers promptinjectieaanvallen op AI-agents die tools gebruiken, aan de hand van 97 realistische taken en 629 beveiligingstestgevallen. Uit hun bevindingen bleek dat kwaadwillige instructies in niet-vertrouwde uitvoer van tools bepaalde beveiligingseigenschappen in gevaar konden brengen, al slaagden de aanvallen en agents daar niet altijd in.

Het onderzoek stelt niet vast hoe vaak deze aanvallen slagen in productieomgevingen. Het laat wel zien waarom het evalueren van alleen modelreacties onvoldoende is om het gedrag van een systeem dat met tools is verbonden te begrijpen.

Een verwant risico wordt soms omschreven als het witwassen van machtigingen: een handeling lijkt legitiem omdat die via een geautoriseerde tool of tussenpersoon verloopt, terwijl het gecombineerde gedrag de beoogde bevoegdheidsgrens schendt.

Wanneer meerdere agents samenwerken, zijn expliciete regels nodig voor deelname, informatie-uitwisseling en toegestane handelingen.

Ook moet binnen de architectuur duidelijk worden vastgelegd wie waarvoor verantwoordelijk is.

Modelaanbieders, platformbeheerders, agentontwikkelaars en organisaties die de systemen inzetten, kunnen elk verschillende onderdelen van het systeem beheren. Een bruikbaar model voor gedeelde verantwoordelijkheid brengt in kaart wie elke grens beheert, wie uitzonderingen kan goedkeuren, wie de uitvoering controleert en wie reageert wanneer er iets misgaat.

Autonomie neemt verantwoordelijkheid niet weg. Ze maakt het juist belangrijker om te weten waar die verantwoordelijkheid ligt.

Offensieve grondigheid: testen wat we denken te weten

Dit brengt ons bij een concept dat ik Offensieve grondigheid noem.

Offensieve grondigheid is een gedisciplineerde aanpak van tests onder vijandige omstandigheden, kritisch onderzoek en validatie op basis van bewijs, waarmee beveiligingsaannames ter discussie worden gesteld. Daarbij wordt geëvalueerd hoe systemen zich onder realistische omstandigheden gedragen, in plaats van uitsluitend af te gaan op architectuurontwerpen, gedocumenteerde maatregelen of vermeende bescherming.

De onderliggende werkwijzen zijn beproefd. Penetratietests, dreigingsmodellering, red teaming en beveiligingsvalidatie stellen defensieve aannames al lange tijd ter discussie.

Offensieve grondigheid brengt die werkwijzen samen rond één centrale vraag:

Welk bewijs toont aan dat de beoogde beveiligingsgrens standhoudt?

Een organisatie kan beleid hebben dat gevoelige informatie beschermt, een model configureren om verboden verzoeken af te wijzen en een agent laten werken met beperkte machtigingen.

Dat zijn waardevolle waarborgen. Het bestaan ervan toont echter niet op zichzelf aan dat het volledige systeem zich onder vijandige omstandigheden veilig gedraagt.

Een model kan een kwaadwillige instructie afwijzen, terwijl een geautoriseerde tool toch een onbedoelde handeling toestaat. Een beleid kan correct lijken, terwijl interacties tussen systemen een onverwachte route eromheen creëren.

Soms noem ik dit een ‘vangrailillusie’: de aanwezigheid van vangrails aanzien voor bewijs dat het systeem de grens die ze moeten bewaken niet kan overschrijden.

Vangrails zijn nuttig. Hun effectiviteit moet echter nog wel worden aangetoond.

Neem een autonome agent die bevoegd is om een vermoedelijk beveiligingsincident te onderzoeken. De agent kan logbestanden ophalen, gebruikersactiviteiten onderzoeken en maatregelen voor indamming aanbevelen.

Tijdens een geautoriseerde beveiligingstest geeft een aanvaller misleidende instructies aan de informatie die de agent naar verwachting zal verwerken.

De test mag niet stoppen bij de vaststelling of de agent die instructies heeft opgevolgd.

Ook moet worden onderzocht of de agent een ongeautoriseerde handeling heeft geprobeerd uit te voeren, of onafhankelijke maatregelen de uitvoering hebben voorkomen, of de poging is vastgelegd en of het systeem zich op passende wijze heeft hersteld.

Offensive Rigor verbindt vijf activiteiten:

1. Stel de aanname vast: bepaal welke beveiligingseigenschap de architectuur geacht wordt af te dwingen.
2. Daag de aanname uit: test realistische aanvalsroutes, gemanipuleerde invoer en combinaties van legitieme mogelijkheden.
3. Verzamel bewijs: stel vast wat het systeem heeft geprobeerd, wat er is uitgevoerd en welke beveiligingsmaatregelen in werking zijn getreden.
4. Verhelp de zwakke plek: pak het model, de workflow, de machtigingen, de architectuur of het operationele proces aan dat verantwoordelijk is voor de tekortkoming.
5. Controleer de oplossing: test de relevante aanvalsroute opnieuw en bevestig dat de beoogde beveiligingseigenschap wordt afgedwongen.

Hierin zit het verschil tussen het testen van de reactie van een model en het testen van de beveiliging van het volledige systeem.

Ook moet worden onderzocht wat er gebeurt nadat een aanvaller aanvankelijk toegang heeft verkregen. Een aanvaller kan proberen inloggegevens te verzamelen, meer rechten te verkrijgen, persistentie te bewerkstelligen of zich lateraal te verplaatsen door misbruik te maken van mogelijkheden die al in een omgeving beschikbaar zijn.

Dat een tool legitiem is, betekent niet dat elk gebruik ervan legitiem is.

Offensive Rigor gaat er niet van uit dat autonome systemen onveilig zijn. Het doel is om door middel van tests vast te stellen waar hun beveiligingsgrenzen standhouden.

Voorwaardelijke autonomie: intelligentie onderscheiden van bevoegdheid

Een mogelijke architecturale oplossing is onderscheid te maken tussen wat een AI-systeem kan doen en waartoe het bevoegd is.

Ik noem deze aanpak voorwaardelijke autonomie.

Bij voorwaardelijke autonomie hangt de passende mate van zelfstandigheid af van de taak, de operationele omgeving, de mogelijke gevolgen, de onzekerheid en het beschikbare bewijs ter rechtvaardiging van een actie.

Een agent die openbare informatie samenvat, heeft niet per se hetzelfde toezicht nodig als een agent die bevoegd is accounts uit te schakelen, firewallregels te wijzigen of productie-infrastructuur aan te passen.

Voor die laatste agent kunnen expliciete regels voor de uitvoering, onafhankelijk afgedwongen machtigingen, strengere autorisatie en menselijke goedkeuring voor ingrijpende acties nodig zijn.

Deze grenzen mogen niet ruimer worden enkel omdat een agent besluit dat ruimere toegang zou helpen om zijn doel te bereiken.

Een agent mag opnieuw bekijken hoe hij een geautoriseerde taak uitvoert, zonder aanvullende bevoegdheden te verkrijgen.

De OWASP Top 10 voor LLM-toepassingen behandelt dit probleem in de categorie LLM06:2025 Buitensporige autonomie. OWASP noemt buitensporige functionaliteit, machtigingen en autonomie als risicobronnen en beveelt aan mogelijkheden te beperken en autorisatie onafhankelijk af te dwingen.

Voorwaardelijke autonomie past deze principes toe op basis van het operationele risico.

De toegang tot informatie moet beperkt blijven tot wat voor een taak nodig is. Machtigingen voor tools moeten worden beperkt tot goedgekeurde handelingen. Uitvoering kan worden begrensd met actiebudgetten, snelheidslimieten, goedkeuringsvereisten en stopvoorwaarden.

Deze beveiligingsmaatregelen zijn bijzonder belangrijk bij autonome offensieve tests.

Een testagent kan tijdens het nastreven van een geautoriseerd doel terecht inloggegevens of gevoelige informatie ontdekken. Maar het ontdekken van inloggegevens betekent niet dat het model de onversleutelde waarde ervan moet ontvangen.

Een beveiligingsomgeving kan gevoelige inloggegevens afschermen van het model en het gebruik ervan bemiddelen via onafhankelijk afgedwongen autorisatie. Zo kan een beheerder van inloggegevens een geheim rechtstreeks aan een goedgekeurde dienst verstrekken, zonder het onnodig aan het model bloot te stellen.

Dit sluit aan bij de gevestigde principes van minimale bevoegdheden en functiescheiding.

Dit roept ook een interessante vraag op over een Bring Your Own Model (BYOM)- of neem-je-eigen-LLM-mee-architectuur (BYO-LLM).

Welke beveiligingsgaranties blijven intact als het onderliggende model morgen wordt vervangen?

Taakautorisatie, het afschermen van inloggegevens, beperkingen van de reikwijdte, logging en beleidsafdwinging kunnen zijn ondergebracht in de omringende beveiligingsomgeving, in plaats van volledig afhankelijk te zijn van het gedrag van het model.

Dat maakt de beveiligingsomgeving niet automatisch veilig en betekent evenmin dat modellen onderling uitwisselbaar zijn. Verschillende modellen kunnen instructies anders interpreteren, tools anders aanroepen en verschillende soorten fouten veroorzaken.

Een zinvolle evaluatie moet zowel de maatregelen testen die onveranderd moeten blijven als het gedrag dat verandert wanneer het model wordt vervangen.

Misschien zijn sommige van de meest duurzame beveiligingseigenschappen juist die welke onafhankelijk afdwingbaar blijven terwijl de intelligentiecomponent zich verder ontwikkelt.

Wanneer AI op AI handelt: het verificatieprobleem

Neem een hypothetische workflow voor beveiligingsoperaties:

Onderzoek dit incident, verzamel het bewijs, identificeer de getroffen identiteiten, stel inperking voor, voer de goedgekeurde acties uit en controleer het resultaat.

Een onderzoeksagent analyseert telemetrie. Een andere agent doet aanbevelingen voor indamming. Een bevoegde uitvoeringsagent voert wijzigingen door. Een verificatieagent beoordeelt het resultaat.

Dit illustreert een autonome incidentrespons met een gesloten regelkring, niet een gedocumenteerde, sectorbrede tekortkoming.

Stel dat de eerste agent ten onrechte vaststelt dat een identiteit is gecompromitteerd. Een tweede agent neemt die conclusie over en schakelt het account uit. Een derde agent bevestigt dat het account is uitgeschakeld en meldt dat de actie is geslaagd.

De geselecteerde actie is uitgevoerd.

Maar was de oorspronkelijke vaststelling juist? Was de actie geautoriseerd? Heeft de indamming de daadwerkelijke dreiging aangepakt? Heeft ze onnodige verstoring veroorzaakt?

Verificatie kan niet uitsluitend bestaan uit bevestigen dat een agent de door hem geselecteerde actie heeft uitgevoerd.

Ook maakt het resultaat niet automatisch onafhankelijk als de verificatie aan een andere AI-agent wordt toegewezen.

Verschillende agenten kunnen zich baseren op dezelfde onjuiste telemetrie, gecompromitteerde informatie of gebrekkige aannames. Dat ze het met elkaar eens zijn, vormt geen onafhankelijk bewijs voor de onderliggende feiten.

Hoe groter de gevolgen van een autonome actie, hoe sterker de behoefte aan verificatie die onafhankelijk is van het systeem dat de beslissing neemt.

Die onafhankelijkheid kan bestaan uit bewijs dat afzonderlijk is verkregen, deterministische beleidscontroles, afgeschermde uitvoeringsomgevingen, menselijke beoordeling of een combinatie van waarborgen.

De passende maatregelen moeten in verhouding staan tot de gevolgen van een fout.

Acties met weinig impact die kunnen worden teruggedraaid, lenen zich mogelijk voor geautomatiseerde verificatie. Voor acties met grote impact of die moeilijk terug te draaien zijn, kan strengere autorisatie, onafhankelijke bevestiging en expliciete menselijke goedkeuring nodig zijn.

Vier vragen helpen om de relevante beveiligingseigenschappen van elkaar te onderscheiden:

• Heeft het systeem de beoogde taak correct geïnterpreteerd?
• Viel de actie binnen de gedelegeerde bevoegdheid?
• Bleef de uitvoering binnen de toegestane grenzen?
• Voldoet het resultaat aan het beoogde beveiligingsdoel?

Deze vragen hangen met elkaar samen, maar zijn niet onderling uitwisselbaar.

Een agent kan een geautoriseerde actie uitvoeren die een onbedoeld resultaat oplevert. Ook kan een agent een ogenschijnlijk gunstig resultaat bereiken met een niet-geautoriseerde actie.

Geen van beide mag automatisch als geslaagde beveiliging worden beschouwd.

Naarmate autonome systemen meer mogelijkheden krijgen, bestaat de uitdaging niet alleen uit het in staat stellen ervan om complexe workflows uit te voeren. Het gaat erom voldoende bewijs te leveren dat hun acties geautoriseerd, passend en correct blijven.

Daarbij hoort weten wanneer je moet stoppen, opschalen, een actie terugdraaien of een begrensd en expliciet begrepen risico aanvaarden.

Vertrouwen moet op bewijs berusten

De gevolgen van autonome AI voor de beveiliging zijn niet uitsluitend negatief.

Autonome systemen kunnen verdedigers helpen kwetsbaarheden op te sporen, dreigingen te onderzoeken en validatiewerkzaamheden uit te voeren die anders veel menselijke inspanning zouden vergen.

Betere modellen, sterkere externe controles en meer volwassen werkmethoden kunnen sommige risico’s beperken die samenhangen met gedelegeerde bevoegdheden.

Het zou daarom voorbarig zijn te concluderen dat autonome AI per definitie onveilig is of dat governance de ontwikkeling ervan niet kan bijhouden.

Er bestaat ook een serieus tegenargument tegen het idee dat autonome AI fundamenteel nieuwe beveiligingsprincipes vereist.

Veel onderliggende problemen — te ruime bevoegdheden, niet-vertrouwde invoer, zwakke autorisatie, inconsistente beleidshandhaving en ontoereikende verificatie — worden al decennialang bestudeerd.

Bestaande maatregelen bieden mogelijk al werkbare oplossingen, mits ze correct worden geïmplementeerd en getest.

Autonomie kan de snelheid, schaal en complexiteit van de toepassing ervan veranderen. Daardoor worden die maatregelen niet automatisch ongeldig.

Het bewijs leidt tot een nuttigere vraag: onder welke voorwaarden kunnen autonome systemen worden vertrouwd om gedelegeerde bevoegdheden uit te oefenen, en hoe tonen we aan dat aan die voorwaarden is voldaan?

Het antwoord ligt niet alleen in de mogelijkheden van het model.

Daarvoor zijn architecturale grenzen, duidelijk toegewezen verantwoordelijkheden, onafhankelijk afgedwongen autorisatie, passend toezicht en bewijs nodig dat de waarborgen onder realistische omstandigheden werken.

Ook is een consistente maar zich ontwikkelende visie op beveiliging en risico nodig.

Onze fundamentele beveiligingsprincipes hoeven niet telkens te veranderen wanneer er een nieuw model verschijnt. Maar we moeten onze aannames over de toepassing van die principes voortdurend ter discussie stellen naarmate de mogelijkheden, werkomgevingen en gedelegeerde bevoegdheden zich ontwikkelen.

Dat is het doel van offensieve grondigheid.

Niet om te bewijzen dat AI-systemen zullen falen, maar om te ontdekken waar ze kunnen falen, de gevolgen vast te stellen en de maatregelen te valideren die bedoeld zijn om die fouten te voorkomen of in te perken.

Misschien ligt het duurzamere voordeel niet zozeer in het kiezen van een capabeler model, maar in het bouwen van een architectuur waarin modellen kunnen veranderen zonder de grenzen van vertrouwen, bevoegdheid en verificatie in gevaar te brengen.

Het kat-en-muisspel gaat door. Steeds vaker hebben beide kanten mogelijk autonome spelers.

Het is van belang ervoor te zorgen dat we niet uit het oog verliezen hoe we zwakke plekken kunnen opsporen, verhelpen en aantonen dat de resultaten kloppen, terwijl we ons haasten om al het andere te automatiseren.

Vertrouwen moet op bewijs zijn gebaseerd.

Auteursnoot: De standpunten en interpretaties in dit artikel zijn die van mij en geven niet noodzakelijkerwijs de officiële standpunten, het beleid of de productmogelijkheden van mijn werkgever weer.