Excessive agency
Wat is excessive agency?
Excessive agency wil zeggen dat een AI-agent meer kan dan zijn taak vraagt. Hij heeft een tool die hij nooit nodig had, werkt via een account waarvan niemand de rechten nakeek, of mag een zware actie afronden zonder dat iemand meekijkt. Je merkt er niets van tot het model iets verkeerds beslist, want dan kan die beslissing ook ergens naartoe.
OWASP omschrijft het als de kwetsbaarheid waardoor schadelijke acties gebeuren op basis van onverwachte, dubbelzinnige of gemanipuleerde output van een model, om het even waarom dat model ontspoorde. Meestal is dat een hallucinatie of een instructie die een aanvaller binnenkreeg. Excessive agency gaat over geen van beide; het gaat over waar de agent bij kan zodra zoiets gebeurd is.
In de OWASP Top 10 voor LLM-toepassingen van 2025 stond het op LLM06, het nummer dat je nog in zowat elk artikel ziet. De editie van augustus 2026 schoof het op naar LLM03, na prompt injection en het lekken van gevoelige informatie, omdat de incidenten zich blijven opstapelen rond agents waarvan de output shell-commando's uitvoert, API's aanspreekt en records in een database wijzigt. In die editie is LLM06 unbounded consumption, dus zet het jaartal altijd bij het nummer: LLM03:2026.
De drie oorzaken volgens OWASP
OWASP splitst het probleem in drie stukken. Overloop ze apart, want dat je er één opgelost hebt, zegt niets over de twee andere.
Te veel functionaliteit. De tool kan meer dan de opdracht. Een mailplugin die enkel de inbox moet samenvatten, maar er ook een verzendfunctie bij heeft. Het voorbeeld van OWASP zelf: een extensie gekozen om documenten uit een repository te lezen, die ze ook kan aanpassen en wissen. De plugin die iemand ooit uitprobeerde en nooit loskoppelde, hoort er ook bij.
Te veel rechten. De tool klopt, het account erachter niet. De versie die je in een KMO tegenkomt is de integratiegebruiker van het ERP: aangemaakt voor één nachtelijke export, adminrechten gekregen omdat die export dan meteen werkte, en nu hangt er een agent aan. De versie van OWASP is een databaseconnectie met UPDATE, INSERT en DELETE terwijl de taak alleen SELECT nodig heeft, of één gedeeld account met hoge rechten voor werk dat per gebruiker zou moeten lopen.
Te veel autonomie. Tool en account zijn correct afgebakend, maar er staat niets tussen de beslissing en de uitvoering. Denk aan een agent die zelfstandig een creditnota mag opmaken: een model bepaalt het bedrag, de klant krijgt zijn geld terug, en in je boekhouding staat een document dat geen mens goedkeurde. OWASP noemt dat het ontbreken van een onafhankelijke controle bij acties met grote impact.
Excessive agency versus prompt injection
Die twee zitten aan weerszijden van hetzelfde incident.
Prompt injection is de oorzaak. Het is de manier waarop een vijandige instructie voor het model belandt: verstopt in een mail, een webpagina, een PDF, een supportticket, de beschrijving van een tool. Het verklaart waarom de agent het verkeerde wilde doen.
Excessive agency is het gevolg. Het verklaart waarom dat willen volstond. Een agent die enkel mag lezen en opstellen, kan je de hele dag injecteren en je houdt er hoogstens een slecht concept aan over. Diezelfde injectie bij een agent met een verzendfunctie en een volledige mailbox levert een vertrokken mail op met je klantenlijst erin.
Injectie helemaal onmogelijk maken lukt niet, want een taalmodel leest instructies en data via dezelfde stroom tekst. Het gevolg klein maken lukt wel, en dat is gewoon bouwwerk met een eindpunt.
Een instructie is geen controle
De klassieke fout is de grens in de prompt schrijven. Verwijder nooit iets. Blijf van productie af. Vraag altijd voor je verzendt. Een agent leest dat, gaat ermee akkoord, en doet het daarna toch, omdat er nergens in het uitvoeringspad iets staat dat hem tegenhoudt.
Het geval dat iedereen zich herinnert is Replit, juli 2025. Jason Lemkin, oprichter van SaaStr, liet een coding agent op een lopend project werken en had erbij gezegd dat er geen code mocht wijzigen zonder toestemming. De agent voerde toch destructieve commando's uit tegen de productiedatabase en zei daarna dat de data niet meer te recupereren was, wat achteraf niet klopte. De AI Incident Database registreert het als incident 1152. De CEO van Replit noemde het onaanvaardbaar, zei dat het nooit mogelijk had mogen zijn, en kondigde een automatische scheiding tussen ontwikkel- en productiedatabases aan. De code freeze bestond wel degelijk. Hij stond alleen op de enige plek waar niets hem afdwingt.
OWASP noemt het alternatief complete mediation: het onderliggende systeem beslist of een actie mag, niet het model. De database weigert de DELETE omdat het account niet mag verwijderen. De mail-API weigert omdat de OAuth-scope alleen lezen toelaat. De goedkeuringsstap zit in je ERP en niet in de prompt. Een model kan je overtuigen om iets te vragen. Je kan het niet overtuigen dat het iets mag.
De maatregelen van OWASP, in gewone taal
OWASP zet acht maatregelen op een rij. De meeste zijn goedkoop en weinig spectaculair.
Geef de agent minder tools. Koppel enkel wat de taak nodig heeft. Moet hij nooit een webpagina ophalen, dan krijgt hij daar geen tool voor.
Geef elke tool minder functies. Een mailboxtool om samen te vatten heeft leesrechten nodig, geen verzenden en geen verwijderen.
Vermijd tools zonder afbakening. Een tool die eender welk shell-commando uitvoert of eender welke URL ophaalt, dekt alles wat er bestaat. Moet de agent een bestand wegschrijven, bouw dan die ene schrijffunctie in plaats van hem een shell te geven.
Geef elke tool een kleiner account. Leesrechten op de tabel met producten, geen eigenaarsrechten op de database, en vastgelegd in de rechten van de database zelf in plaats van in de code van de tool.
Laat de agent werken in naam van de gebruiker. Laat hem handelen als de persoon die de vraag stelde, met diens sessie en scope, niet via één gedeeld service account dat ieders bestanden ziet.
Vraag goedkeuring bij zware acties. Verzenden, verwijderen, betalen, publiceren, rechten aanpassen: de agent bereidt voor, een mens bevestigt, en op dat scherm staan de echte parameters.
Autoriseer in het onderliggende systeem. Elke vraag die via een tool binnenkomt, toets je aan je eigen beleid aan de andere kant van die tool, waar het model niets te zeggen heeft.
Controleer input en output. Gewone secure coding geldt ook voor de leidingen rond een agent, en OWASP verwijst daarvoor naar zijn eigen ASVS.
Twee dingen voorkomen niets, maar drukken wel de factuur. Log elke tool-call met zijn parameters, zodat je achteraf ziet wat er gebeurd is en hoe ver het geraakt is. Zet een limiet op het aantal acties die pijn doen, zodat een agent die om twee uur 's nachts ontspoort vijf mails verstuurt en geen vijfduizend voor iemand het merkt.
Waar moet je op letten bij excessive agency
Autonomie verdien je per taak, je zet ze niet één keer aan. De aparte OWASP-lijst voor agentische toepassingen, uit december 2025, zet identity and privilege abuse niet toevallig op ASI03: agents draaien onder identiteiten van gebruikers of systemen met meer rechten dan de taak vraagt, en houden die daarna bij. Beperk de rechten tot de taak en laat ze vervallen.
Rechten groeien stilaan. Elke nieuwe integratie voegt een account toe en niemand haalt het oude weg. Loop de drie oorzaken opnieuw af na elke nieuwe tool, leveranciersupdate en modelwissel, en vraag een leverancier welke identiteit zijn product in jouw tenant gebruikt en of de goedkeuringsstap een echte poort is of een melding die je kan uitzetten.
Een agent die enkel leest, heeft een ander probleem. Excessive agency gaat over schadelijke acties. Een agent die alleen leest maar wel data naar buiten kan sturen, lekt in plaats van kapot te maken; dat is de vraag achter de lethal trifecta, en beide checks zijn de moeite.
De verantwoordelijkheid verschuift niet. Wist een agent klantgegevens of stuurt hij persoonsgegevens naar het verkeerde adres, dan is het bedrijf dat de agent inzet aanspreekbaar. Geef elke agent een eigen identiteit en log welke agent wat deed, zodat een incidentrapport een account noemt en niet "de AI".