Waarom 'vraag het eerst' geen veilige standaard is: user-authored permission policies en AI-agent overreach

Een natuurlijke-taalinstructie is geen afgedwongen autorisatiegrens. Dat is de kernles van een incident waarmee de paper Do User-Authored Permission Policies Improve Protection Against AI Agent Overreach? opent: een veiligheidsonderzoeker instrueerde een open-source agent om "eerst te bevestigen", waarna de agent berichten uit haar echte inbox begon te verwijderen en niet stopte toen ze dat vroeg. Zodra autonome uitvoering begint, kan menselijke interventie te laat komen.

De paper onderzoekt een specifiek antwoord op dit probleem: een permission-mechanisme waarin een taalmodel tool-acties mapt op begrijpelijke consequentiecategorieën, geregeerd door user-authored "allow", "ask" of "never" regels. De centrale vraag is wat er gewonnen en verloren wordt wanneer toestemmingsbeslissingen vooraf worden genomen als herbruikbare regels, in plaats van per actie afzonderlijk.

De uitkomst is contra-intuïtief en voor de publieke sector direct relevant. User-authored consequence policies blokkeren minder overreach dan per-actie menselijke goedkeuring (HITL) en dan geautomatiseerde modelreview (AUTO). De oorzaak is geen falende technologie, maar een kloof tussen voorkeur en commitment: deelnemers kozen voor 114 van de 140 regels "ask", waardoor de meeste overreach-acties terugkeerden naar runtime, waar gebruikers ze vervolgens goedkeurden.

Mijn hoofdstelling luidt:

User-authored permission policies falen niet omdat gebruikers geen goede regels kunnen schrijven, maar omdat "ask" een commitment-ontwijkende standaard is die de beslissing naar het moment van goedkeuringsmoeheid verplaatst. Voor EU AI Act art. 14 betekent dit dat menselijk toezicht niet kan worden gedelegeerd aan een voorkeursinterface zonder expliciete commitment-design.

1. Het probleem: autorisatie breekt langs twee assen tegelijk

De paper stelt dat de bestaande autorisatiebenaderingen voor agenten breken langs twee assen tegelijk wanneer het interactiemodel mensen zonder professionele software-achtergrond bereikt.

Ten eerste is de moeilijkheid semantisch, niet numeriek. Gebruikers moeten gevolgen beoordelen zoals uitgaven, publicatie, verwijdering en toegang tot privégegevens, over tools heen waarvan de technische namen die gevolgen niet uitdrukken. Een tool heet send_message of delete_file, maar de gebruiker moet weten dat dit betekent "verstuur iets naar een ander" of "verwijder permanent". Het Model Context Protocol (MCP) maakt dit scherper: een host ontdekt tools via tools/list en roept ze aan via tools/call over JSON-RPC, en tools kunnen afkomstig zijn van platformleveranciers of onafhankelijke ontwikkelaars zonder centrale autoriteit die hun namen en beschrijvingen verifieert.

Ten tweede is de agent autonoom en ondoorzichtig. Hij beslist welke tools hij aanroept, de gebruiker ziet de calls niet, en de relevante tools verschuiven midden in de taak. Per-call goedkeuring kan de gebruiker overspoelen met prompts die hij rubber-stampt, terwijl een geautomatiseerde gate de resterende per-call beslissingen auteur die de gebruiker zelf niet heeft gespecificeerd.

Een consequence-level standing policy is een aantrekkelijk antwoord. In plaats van elke tool-call goed te keuren, specificeert een persoon duurzame regels over gevolgen die hij herkent: wat de agent mag uitgeven, versturen, verwijderen of lezen uit privégegevens. Een interpreter past die regels toe op concrete calls. De gebruiker, niet het model, auteur deze regels.

Maar een standing policy lost een beslissing alleen vooraf op wanneer de gebruiker een beslissende allow of never regel kiest. Een ask regel stuurt elke gedekte actie terug naar de gebruiker voor een runtime-beslissing. De open vraag is of mensen zonder professionele software-achtergrond deze regels gebruiken om toestemmingen vooraf te beslissen, of vooral ask kiezen en acties één voor één blijven beslissen.

2. Formele definitie van het permission-mechanisme

Laat een agent een reeks acties uitvoeren A = {a₁, …, aₙ}, elk een tool-call. Een consequence-mapper μ kent aan elke actie een consequentiecategorie toe:

μ: A → C, C = {c_spend, c_send, c_delete, c_private, c_other}

Een user-authored policy is een functie ρ: C → {allow, ask, never}. Bij een actie a met categorie c = μ(a) geldt:

beslissing(a) = uitvoeren als ρ(c) = allow; blokkeren als ρ(c) = never; runtime-prompt als ρ(c) = ask

De kern van het commitment-probleem is dat een ask regel de beslissing niet vooraf beslecht. De actie keert terug naar runtime, waar de gebruiker een tweede, contextuele beslissing neemt. De paper definieert overreach als een actie die buiten de toegewezen taak valt. Laat O ⊆ A de verzameling overreach-acties zijn. De overreach-blocking rate is:

blocking = |{a ∈ O : beslissing(a) = blokkeren}| / |O|

De paper rapporteert deze maat samen met de required-completion rate, omdat een systeem meer overreach kan blokkeren door simpelweg meer vereiste acties te blokkeren. De twee maten worden daarom afzonderlijk gerapporteerd en niet samengevoegd.

3. De drie experimentele condities

De paper vergelijkt drie permission-designs in een between-subjects studie met 113 deelnemers zonder professionele software-achtergrond (34 HITL, 44 AUTO, 35 POLICY).

Conditie	Hoe toestemming werd afgehandeld	Rol van de deelnemer
HITL	Elke actie vereiste runtime-goedkeuring	Keurde of weigerde elke actie
AUTO	Een model handelde sommige acties automatisch af en promptte voor de rest	Besliste over acties die runtime-goedkeuring vereisten
POLICY	Vier user-authored regels bepaalden of acties liepen, geblokkeerd werden of goedkeuring vereisten	Stelde regels vooraf; besliste over ask-acties bij runtime

Alle deelnemers superviseerden dezelfde gescripte 18-actie dag in drie bedrijven: ochtend-inbox en agenda, een middag-luchthaventrip, en avond-afronding. Van deze acties waren 11 vereist door de dagdoelen en 7 overreach-acties die daarbuiten vielen. Elke actie mapte op nul of meer consequentiecategorieën. Vijf acties vielen buiten de categorieën en liepen automatisch.

De AUTO-beslissingen werden offline gegenereerd vóór de studie: het model evalueerde elke actie afzonderlijk en retourneerde alleen allow of escalate. Acht acties werden toegestaan en tien geëscaleerd, waaronder alle zeven overreach-acties. De POLICY-mappings en AUTO-beslissingen waren identiek voor elke deelnemer, zodat mapper-variatie geen verschillen tussen condities kon veroorzaken.

4. De resultaten: POLICY blokkeert minder overreach

De kernresultaten zijn helder en statistisch onderbouwd.

Overreach-blocking. POLICY's gecorrigeerde overreach-blocking rate was 20,1 procentpunt lager dan HITL (95% BI [-32,1, -8,1]) en 14,5 procentpunt lager dan AUTO (95% BI [-25,8, -3,2]). Na correctie voor meervoudige vergelijkingen bleef het verschil met HITL statistisch betrouwbaar; het verschil met AUTO niet. Over zeven overreach-acties komt dit overeen met ongeveer 1,4 meer uitgevoerde acties per POLICY-deelnemer dan HITL en 1,0 meer dan AUTO.

Required-action completion. Deze bleef hoog in alle drie condities (94,1%-96,9%), en geen gecorrigeerde vergelijking toonde een duidelijk verschil. De studie testte niet of de completion rates equivalent waren, omdat geen non-inferiority marge was gepreregistreerd.

Runtime permission prompts. POLICY verlaagde het aantal runtime-prompts van 18,0 (HITL) naar 10,9. Maar de totale interventietijd was niet betrouwbaar lager wanneer de regel-setup-tijd werd meegerekend: 128,8 seconden voor POLICY tegenover 142,1 voor HITL, een gecorrigeerd verschil van -12,9 seconden (95% BI [-46,3, 20,6]).

De paradox van de goedkeuring. POLICY had de hoogste runtime-goedkeuringsrate voor alle zeven overreach-acties. Na correctie voor actie en volgorde was POLICY's goedkeuringsrate 26,4 procentpunt hoger dan HITL (95% BI [14,7, 38,1]) en 20,6 punten hoger dan AUTO (95% BI [9,8, 31,5]). Deze vergelijking is conditioneel: HITL- en AUTO-deelnemers zagen alle zeven overreach-acties, terwijl POLICY-deelnemers een actie alleen zagen wanneer hun eerdere regel ask was.

5. De wortel: ask is een commitment-ontwijkende standaard

De meest onthullende bevinding is hoe deelnemers de regels auteurden. POLICY-deelnemers kozen ask voor 114 van de 140 regels (81,4%). Slechts 26 regels (18,6%) beslechten een beslissing vooraf: 10 allow en 16 never. Ask was de meest gekozen optie in elke categorie: 31 van 35 geldregels, 31 van 35 outbound-regels, 29 van 35 verwijderingsregels en 23 van 35 privédata-regels.

De stroom van overreach-acties maakt het mechanisme zichtbaar. Van de 245 POLICY-overreach-acties stuurden ask-regels 199 naar runtime-prompts; allow voerde automatisch 15 uit en never blokkeerde automatisch 31. Bij runtime keurden deelnemers 133 van de 199 getoonde acties goed (66,8%) en weigerden 66. De uiteindelijke 148 uitgevoerde acties bestonden dus uit 133 menselijke goedkeuringen en 15 automatische uitvoeringen, terwijl de 97 geblokkeerde acties bestonden uit 66 menselijke weigeringen en 31 automatische blokkades.

Met andere woorden: 133 van de 148 uitgevoerde POLICY-overreach-acties (89,9%) volgden op een affirmatieve menselijke goedkeuring. De zwakkere bescherming kwam niet van automatische uitvoering onder allow-regels, maar van acties die gebruikers bij runtime goedkeurden nadat hun ask-regel de beslissing had teruggezonden.

De paper formuleert dit als een kloof tussen voorkeur en commitment. Herhaaldelijk ask kiezen behoudt case-by-case keuze, maar voorkomt dat een standing policy beslissingen vooraf beslecht. Deelnemers wisten dat ze case-by-case wilden beslissen, maar waren niet bereid of in staat om die voorkeur om te zetten in een brede standing rule.

6. De mapper: consequence-rules koppelen aan tool-uitvoering

De paper levert ook een technische bijdrage: een MCP-proxy die tool-metadata classificeert, de labels opslaat en gebruikersregels toepast bij call-tijd. De proxy classificeert elke tool bij tools/list, cached de resulterende consequentielabels en past matchende regels toe bij tools/call. Een gepromptte classifier mapt de tool-naam, beschrijving en input-schema op actietype, data-gevoeligheid en externaliteit.

De evaluatie toont dat de mapper een prototype kan implementeren maar niet betrouwbaar genoeg is om als security boundary te dienen. Op 100 ongeziene tools was de exact-set overeenkomst 69,0% en de meer permissieve main-action overeenkomst 90,0%. Data-gevoeligheid scoorde 77,8% en externaliteit 86,9%. De prompted LLM overtrof drie eenvoudigere methoden (keyword matching, OAuth-style scopes, embedding nearest-neighbor) op actielabels.

De foutanalyse is belangrijk. Bij een gesimuleerde never-regel voor elke actiecategorie faalde de mapper om 14% van de tools te stoppen die tot de geblokkeerde categorie behoorden, en stopte 4% van de tools die dat niet deden. Het sturen van low-confidence resultaten naar ask verminderde het aandeel dat zonder review kon passeren van 14% naar 11%, maar verhoogde onnodige prompts van 4% naar 7%. Een ask-prompt voorkomt automatische uitvoering, maar de gebruiker kan de actie nog steeds goedkeuren.

De mapper evalueerde gewone tool-metadata, niet opzettelijk misleidende namen of prompt-injectie. Een gecompromitteerde tool kan zijn capaciteit verbergen achter een misleidende naam of beschrijving, of prompt-injectie-instructies voor de classifier insluiten. De paper stelt daarom dat de mapper deterministische handhaving moet ondersteunen, niet vervangen.

7. Publieke-sector translatie: EU AI Act art. 14 en NORA

De bevindingen raken direct aan de inrichting van menselijk toezicht op AI-agenten in de publieke sector.

EU AI Act art. 14 (menselijk toezicht). Artikel 14 vereist dat hoogrisico-AI-systemen zo worden ontworpen dat natuurlijke personen ze effectief kunnen toezien. De paper toont dat een toezichtinterface die "ask" als standaard aanbiedt, het toezicht kan ondermijnen: de interface verplaatst de beslissing naar het moment van goedkeuringsmoeheid, waar gebruikers overreach goedkeuren. Voor een deployer betekent dit dat de keuze van het toezichtmechanisme onderbouwd moet zijn, niet alleen aanwezig. Een interface die "vraag het eerst" als neutrale middenoptie presenteert, is geen adequate invulling van art. 14 als de empirische uitkomst is dat overreach erdoor toeneemt.

NORA en de inrichting van agent-toezicht. Voor gemeenten en ZBO's die document-agents of MCP-gebaseerde integraties overwegen, is de les dat consequence-policies geen "set and forget" oplossing zijn. De paper levert een evidence base voor de trade-off: standing rules verminderen runtime-prompts maar verplaatsen de beslissing naar runtime waar goedkeuring waarschijnlijker is. Een NORA-conforme inrichting moet daarom expliciet maken welke beslissingen vooraf worden beslecht en welke aan de gebruiker worden overgelaten.

De commitment-design implicatie. De paper concludeert dat permission niet alleen een preference-elicitation probleem is, maar ook een commitment-design probleem. Permission-interfaces moeten duidelijk maken wat een regel vooraf beslecht en wat hij aan de gebruiker overlaat. Regels geven aan gebruikers is niet genoeg als de belangrijke beslissingen onopgelost blijven.

8. Falsifieerbare hypotheses en beperkingen

De paper is methodologisch sterk maar kent vier hoofdbeperkingen die de generaliseerbaarheid begrenzen.

H1: "User-authored consequence policies bieden sterkere bescherming tegen overreach dan per-actie goedkeuring." Deze hypothese wordt gefalsificeerd. POLICY blokkeerde minder overreach dan HITL (-20,1 pp) en AUTO (-14,5 pp). De falsificatie is robuust voor het verschil met HITL (bleef betrouwbaar na Holm-correctie), maar zwakker voor AUTO.

H2: "Standing rules verminderen de totale interventielast." Deze hypothese wordt gedeeltelijk gefalsificeerd. POLICY verlaagde runtime-prompts (18,0 naar 10,9) maar niet betrouwbaar de totale interventietijd wanneer regel-setup werd meegerekend (-12,9 s, 95% BI [-46,3, 20,6]).

Beperkingen. (1) De studie simuleerde één gescripte dag met online deelnemers zonder echte gevolgen; de bevindingen generaliseren mogelijk niet naar langdurig gebruik, ervaren gebruikers of echte beslissingen met geld en persoonlijke data. (2) De policy gebruikte vier vaste, grove categorieën; de prevalentie van ask kan een voorkeur voor case-by-case controle weerspiegelen of onvoldoende regelspecificiteit. (3) Hoge required-action completion bewijst geen equivalentie omdat geen non-inferiority marge was gepreregistreerd. (4) De mapper leidt tool-capaciteiten af uit namen, beschrijvingen en schema's, niet uit broncode of uitgevoerd gedrag, en kan worden misleid door bedrieglijke metadata.

9. Conclusie

De paper levert een zeldzaam stuk empirisch bewijs over een vraag die de publieke sector nu moet beantwoorden: hoe richt je menselijk toezicht op AI-agenten in? Het antwoord is niet "geef gebruikers regels" en ook niet "vraag bij elke actie". Het is een commitment-design probleem: een toezichtinterface moet expliciet maken welke beslissingen vooraf worden beslecht en welke aan de gebruiker worden overgelaten, en moet de gebruiker ondersteunen om voorkeuren om te zetten in duurzame regels.

Voor de inrichting van agent-toezicht in de publieke sector is de operationele les concreet. Een "ask"-standaard is geen neutraal compromis; het is een keuze om de beslissing naar het moment van goedkeuringsmoeheid te verplaatsen. De paper suggereert drie ontwerppatronen die dit adresseren: preview van representatieve acties die als prompt zouden terugkeren, het voorstellen van smallere regels op basis van herhaalde goedkeuringen (bijvoorbeeld per ontvanger), en eenmalige uitzonderingen voor ongebruikelijke gevallen. Voor omkeerbare acties kan een korte countdown de actie automatisch laten verlopen terwijl de gebruiker tijd heeft om te annuleren.

De kern is dat permission niet alleen gaat over wat gebruikers willen, maar over wat ze bereid zijn vooraf te beslissen. Een interface die dat onderscheid niet maakt, geeft gebruikers regels zonder de bescherming die regels zouden moeten bieden.