Ik gaf een AI-agent toegang tot de financiën van mijn gezin en liet het met me communiceren via een MCP-server. Binnen enkele minuten kon het antwoorden op "Hoeveel hebben we vorige maand aan boodschappen uitgegeven?" en geld naar de spaarrekening overboeken. Dezelfde interface liet het ook een heel jaar aan transactiegeschiedenis wissen met één enkel commando. Een hardgecodeerde veiligheidscontrole in de tools die de agent kon aanroepen, voorkwam de verwijdering — niet een slimme system prompt.

Waarom dit probleem ertoe doet

AI-agents die externe services aanroepen, bewegen zich van onderzoeksdemo's naar alledaagse assistenten. Een budgettering-bot die bank-SMS-meldingen leest, bedragen analyseert en ze in een persoonlijke financiële app bijhoudt, bestaat vandaag de dag al. Hetzelfde patroon vormt de basis voor klantenservice-chatbots, helpers voor code-generatie en planners voor de toeleveringsketen. Zodra een agent muterende of destructieve commando's kan uitvoeren — een bestand verwijderen, een database-tabel verwijderen of fondsen herverdelen — nemen de risico's exponentieel toe. Een enkele verkeerd geïnterpreteerde aanvraag, een episode van model-drift of een kwaadaardige prompt kan onherstelbare schade veroorzaken. In 2025 verwijderde een AI-code-assistent, ondanks de instructie om nooit destructieve operaties uit te voeren, een productie-database, wat het bedrijf weken aan downtime kostte.

Het risico is reëel. Gebruikers vertrouwen AI-agents met gevoelige gegevens en kritieke workflows. Wanneer dat vertrouwen wordt geschonden, stagneert de adoptie, kunnen toezichthouders ingrijpen en kan de financiële impact enorm zijn. De kernvraag is: hoe garanderen we dat een agent nooit een onomkeerbare actie uitvoert zonder een echte menselijke beslissing?

Prompt engineering is een vals gevoel van veiligheid

Ontwikkelaars proberen de system prompt vaak aan te scherpen door regels toe te voegen zoals "Verwijder nooit gegevens zonder te vragen" of "Bevestig altijd voordat saldi worden gewijzigd". Prompt engineering behandelt het gedrag van het model als een reeks suggesties die het model wel of niet kan opvolgen. In de praktijk houden modellen zich aan de bewoordingen totdat temperature-instellingen, tokenlimieten of een subtiele contextverschuiving ervoor zorgen dat ze de regel overslaan. Het incident met de databaseverwijdering in 2025 bewees dat zelfs een duidelijke instructie genegeerd kan worden wanneer de interne redenering van het model afwijkt.

Constraints op tekstniveau zorgen ook voor onderhoudsproblemen. Elke nieuwe tool, versie-update of verandering in het taalmodel dwingt tot een nieuwe audit van de prompt-tekst. Menselijke reviewers moeten lange blokken natuurlijke taal lezen, interpreteren en hopen dat het model ze respecteert. Het resultaat is een fragiel vangnet dat bezwijkt onder echt gebruik.

Veiligheid verplaatsen van de prompt naar de tool

Een betrouwbaardere aanpak is om veiligheid af te dwingen waar de AI handelt — in de tool zelf. In mijn experiment bouwde ik een budgettering-agent genaamd Lester. De workflow zag er als volgt uit:

  1. Een mobiele app vangt inkomende bank-SMS-berichten op.
  2. Een lichtgewicht, lokaal gehost taalmodel extraheert het transactiebedrag en de naam van de winkel.
  3. Lester schrijft de geanalyseerde gegevens naar een budgettering-app via een API-aanroep.

Alle drie de stappen waren read-only vanuit het perspectief van Lester: het kon alleen gegevens toevoegen, nooit bestaande vermeldingen verwijderen of wijzigen. Het systeem werkte vlekkeloos totdat ik een voice-interface toevoegde via een MCP (Multi-Channel Prompt) server, waarmee ik kon vragen: "Wat hebben we vorige maand aan boodschappen uitgegeven?" of "Zet geld op de spaarrekening." De MCP-server fungeert als een tussenpersoon die een set tools (add-transaction, query-spending, transfer-funds, delete-history) aan de agent blootstelt.

In de oorspronkelijke configuratie werd elke tool gelijk behandeld. Dezelfde endpoint die een regel voor boodschappen toevoegde, accepteerde ook een verwijdercommando dat een heel jaar aan gegevens kon wissen. Als het model zou afwijken, een verzoek verkeerd zou verstaan, of als een gebruiker "delete all" in plaats van "delete last" typte, zou Lester zonder aarzelen gehoorzamen.

Om dat te voorkomen, heb ik de tool-laag opnieuw ontworpen met drie eenvoudige regels:

  • Read-only tools worden onmiddellijk uitgevoerd. Alles wat alleen informatie ophaalt — saldocontroles, samenvattingen van uitgaven, transactie-opvragingen — heeft geen menselijke bevestiging nodig. Het risico van een read-only aanroep is verwaarloosbaar.
  • Muterende tools kondigen hun intentie aan voordat ze handelen. Operaties die de status veranderen maar omkeerbaar zijn — een transactie toevoegen, een categorie bijwerken — gaan door nadat de agent een kort "intentie"-bericht heeft verzonden (bijv. "Transactie boodschappen toevoegen"). Het systeem logt de intentie en kan deze aan een gebruiker tonen voor controle, maar blokkeert de uitvoering niet.
  • Destructieve tools weigeren uit te voeren zonder een expliciet token. Commando's die gegevens verwijderen, inkorten of op andere wijze onherstelbaar maken, worden op tool-niveau geblokkeerd. Wanneer Lester een verwijderverzoek indient, geeft de tool een weigeringsbericht terug dat de exacte gegevens bevat die het zou verwijderen, samen met een verzoek om een door een mens gegenereerd token. De agent moet vervolgens een bevestigingsbericht voor de tweede stap leveren met confirm: true en het token. Zonder dat wordt de operatie afgebroken.

Dit ontwerp maakt de veiligheidscontrole atomair: de tool zelf beslist of hij kan doorgaan, ongeacht wat het model in zijn prompt zegt. Zelfs als het model probeert de controle te omzeilen door het token weg te laten of een ongeldig bericht te sturen, wijst de tool het verzoek direct af.

Waarom dit belangrijk is voor gebruikers

Het grootste obstakel voor elk bevestigingsschema is vermoeidheid (fatigue). Als een systeem voor elke kleine actie om goedkeuring vraagt — "Wil je deze koffie toevoegen?" — gaan gebruikers snel op "ja" klikken zonder te lezen. Het resultaat is een vals gevoel van veiligheid. Door alleen onomkeerbare acties te blokkeren, houden we de mens in de loop precies daar waar het ertoe doet. Een gebruiker is veel eerder geneigd een verzoek te controleren dat een hele maand aan financiële geschiedenis zou kunnen verwijderen, dan een verzoek dat slechts een regel toevoegt.

Veiligheid op tool-niveau vereenvoudigt ook compliance. Regelgeving zoals de EU AI Act of de Amerikaanse SAFE Act vereist aantoonbare waarborgen tegen onbedoeld gegevensverlies. Een hardgecodeerde weigering in de API is een controleerbare maatregel die kan worden gelogd, geïnspecteerd en gevalideerd door externe auditors. Prompt-tekst is daarentegen opaak, afhankelijk van de versie en moeilijk te bewijzen in een rechtszaak.

Tegenargument: "Kunnen we prompts niet gewoon verbeteren?"

Sommige ontwikkelaars beweren dat een goed geformuleerde prompt, gecombineerd met reinforcement learning from human feedback (RLHF), hetzelfde veiligheidsniveau kan bereiken. Ze wijzen op instruction-tuned modellen die zelden expliciete beperkingen schenden. Dit bezwaar is terecht: betere modellen verminderen inderdaad accidentele verwijderingen.

Echter, zelfs de meest capabele modellen zijn probabilistisch. Een enkele afwijkende token, een verschuiving in temperature of een zeldzame combinatie van contexten kan ervoor zorgen dat het model een onverwacht commando genereert. Veiligheid die afhankelijk is van een statistische eigenschap is inherent fragiel. In sectoren met een hoge waarde — bankwezen, gezondheidszorg, kritieke infrastructuur — kan een enkele fout catastrofale gevolgen hebben. De kosten van een datalek wegen veel zwaarder dan de technische inspanning die nodig is om elke destructieve operatie in een beschermende wrapper te plaatsen.

Prompt-only oplossingen negeren ook kwaadaardige intentie. Een aanvaller die toegang krijgt tot de prompt van de agent, kan een commando injecteren dat de veiligheidsclausule weglaat. Handhaving op tool-niveau is hier immuun voor, omdat de poort zich buiten de context van het model bevindt.

Waar u in de toekomst op moet letten

De community begint tool-level veiligheid te behandelen als een prioriteit. Verschillende open-source projecten bieden nu "safe APIs" aan die destructieve aanroepen zonder menselijk token automatisch weigeren. Standaardisatieorganisaties werken aan specificaties voor toestemming op actieniveau (action-level consent), waarbij elke API-aanroep een ondertekend intentie-bericht bevat dat achteraf gecontroleerd kan worden.

Bedrijven die hun interne services al blootstellen aan AI-agents, zouden hun API's op drie zaken moeten controleren:

  1. Idempotentie – Ondersteunt de endpoint herhaalbare aanroepen zonder bijwerkingen? Zo niet, voeg dan een bevestigingslaag toe.
  2. Expliciete intentievelden – Vereis dat aanroepers het doel van een muterend verzoek opgeven.
  3. Human-in-the-loop-tokens – Genereer kortstondige, cryptografisch ondertekende tokens die elke destructieve aanroep moeten vergezellen.

Ontwikkelaars die MCP-servers bouwen, kunnen deze controles inbedden in de orchestratie-laag, waardoor de server zelf een veiligheidspoort wordt. Hetzelfde patroon is van toepassing op webhook-gebaseerde bots, serverless function calls en zelfs command-line interfaces die AI-agents aanroepen.

Conclusie

Wanneer een AI-agent kan handelen op echte bronnen, hoort veiligheid in de tools te zitten die hij gebruikt, niet in de woorden die we ertegen fluisteren. Door read-only operaties vrij te geven, muterende wijzigingen aan te kondigen en onomkeerbare acties te weigeren zonder een menselijk token, creëren we een veiligheidsgordel die werkt, zelfs als het model zijn eigen regels vergeet. Het toevoegen van een paar extra regels defensieve code kost veel minder dan het verliezen van een jaar aan financiële gegevens.