De vier lagen van betrouwbare AI-agents — wat vier nieuwe papers betekenen voor de Nederlandse overheid
AI GovernanceDeze week las ik vier papers die in dezelfde week verschenen, elk over een fundamentele laag van AI-betrouwbaarheid. En eerlijk? Het voelt alsof er een kantelpunt is bereikt. Niet langer gaat het alleen over of een model goed antwoordt. De echte vraag wordt: plant het veilig, communiceert het betrouwbaar onzekerheid, stopt het op tijd met redeneren, en kan het interne verklaringen leveren die verifieerbaar zijn?
Samen vertellen ze één verhaal: de volgende fase van AI-governance verschuift van modelkwaliteit naar execution assurance. Dit is geen academische exercitie. Met de EU AI Act die op 2 augustus 2026 van kracht wordt, en BIO2 die functiescheiding vereist tussen menselijke beslissers en geautomatiseerde systemen, zijn dit de vragen waar CIO's van ministeries, gemeenten en ZBO's nú antwoord op moeten hebben.
De vier lagen
De papers bestrijken vier onafhankelijke control-lagen, die samen een volwassen governance-stack vormen:
| Laag | Paper | Kernvraag |
|---|---|---|
| Semantic supply chain security | MCP Poisoning (CAS Beijing) | Kan de agent zijn toolbeschrijvingen vertrouwen? |
| Confidence calibration | Confidence Calibration (Berkeley) | Weet het systeem wanneer het mogelijk fout zit? |
| Reasoning budget governance | Reasoning Redundancy (Fudan) | Stopt het model op tijd, of verbrandt het tokens zonder waarde? |
| Formal local verification | Verifiable Transformers (Somani) | Kunnen we specifieke modelgedragingen formeel bewijzen? |
Laag 1: MCP Tool Description Poisoning, de aanval die niemand zag aankomen
Paper: When the Manual Lies: A Realistic Benchmark to Evaluate MCP Poisoning Attacks for LLM Agents, Shi Liu et al., CAS Institute of Information Engineering, Beijing
De Model Context Protocol (MCP) standaard wordt snel de lingua franca voor agent-tool interoperabiliteit, Anthropic, Google en OpenAI adopteren het. Maar deze paper toont een fundamentele aanvalsvector die in klassieke AppSec niet bestaat: Tool Description Poisoning (TDP).
Hoe het werkt
In traditionele applicatiebeveiliging scan je code, dependencies, SBOM's en permissies. TDP valt buiten al die checks: kwaadaardige instructies worden niet in tool-code geplaatst, maar in de beschrijvende metadata, de "handleiding" waarop een agent vertrouwt bij planning en toolselectie. Denk aan tool descriptions, parameter schema's, examples, docstrings, README-fragmenten en MCP server manifests.
De auteurs introduceren de MCP-TDP Security Benchmark: 32 realistische testcases over 6 risicocategorieën, in een high-fidelity sandbox. De resultaten zijn confronterend:
- GPT-4o: ~100% Attack Success Rate in high-risk scenario's
- 8 mainstream LLMs getest, allemaal zwaar kwetsbaar
- Prompt-guardrails zijn grotendeels ineffectief en soms contraproductief, een fenomeen dat de auteurs de "Firewall Fallacy" noemen
Implicatie voor MCP-governance
In klassieke AppSec controleer je code, dependencies, SBOM's en permissies. In agentic security moet je óók tool metadata, schema's, descriptions, examples, docstrings, README-fragmenten en MCP manifests als executable influence behandelen. De implicaties raken vijf domeinen.
MCP governance wordt radicaal anders: tool descriptions moeten security-reviewed worden alsof ze policy-bearing code zijn. In de agent runtime mag toolselectie niet alleen door modelinterpretatie gebeuren, maar moet policy-gated zijn, een model kan niet neutraal naar metadata kijken. CI/CD krijgt er een hele nieuwe dimensie bij: MCP server manifests, tool schemas en descriptions moeten door SAST-achtige checks, diff-review en signing. Voor runtime control betekent dit dat high-risk tools confirm-before-act vereisen, met least privilege, scoped tokens en output validation. En audit? Log niet alleen tool calls, maar ook welke metadata aan het model is aangeboden.
De paper stelt een defense voor: Reactive Self-Correction, waarbij een agent post-executie zijn eigen acties detecteert en herstelt. Maar de structurele oplossing ligt dieper: tool metadata moet als aparte supply chain attack surface worden behandeld.
Laag 2: Confidence Calibration, waarom je niet op model-zekerheid kunt vertrouwen
Paper: Confidence Calibration in Large Language Models, Noam Michael et al., U.C. Berkeley & USC
Veel enterprise AI-designs vertrouwen impliciet op modelconfidence als routeringssignaal: "confidence > 90%? Uitvoeren." "Confidence ＜ 70%? Escaleren naar mens." Deze paper ondergraaft die eenvoudige logica volledig.
De kernbevinding: moderne LLMs vertonen hetzelfde patroon als overmoedige mensen, maar erger. Ze zijn overconfident op moeilijke taken en underconfident op makkelijke taken. De auteurs noemen dit het "hard-easy effect" en tonen het aan over 11 modellen (GPT-4o, Claude, Gemini, Llama, Mistral) en 5 taaktypen. Ze introduceren LifeEval, een benchmark die calibratie meet over moeilijkheidsgraden met een continue, bias-vrije schaal.
De risico's zijn concreet. Confidence als vrijgavecriterium is onveilig bij moeilijke taken, juist daar waar overconfidence het hoogst piekt. Confidence als audit evidence is zwak bewijs, tenzij empirisch gekalibreerd per taaktype. Confidence als human-in-the-loop trigger loopt het risico escalaties te missen bij complexe cases. En confidence als model-ranking metric is ronduit misleidend zonder calibration curves en ECE/Brier-score-metingen.
Het juiste model: confidence als gecalibreerd risicosignaal
De governance-vertaling is niet "gebruik geen confidence" maar: combineer confidence met retrieval quality, source provenance, task criticality, tool risk, policy classification, historical model accuracy en disagreement tussen modellen.
Concreet:
Decision approval = f(
model confidence,
task criticality,
evidence quality,
data sensitivity,
tool impact,
model disagreement,
historical calibration,
human override policy
)
Niet doen: "model zegt 92% confidence, dus uitvoeren." Wel doen: per use case calibratie meten, juridische samenvatting, code review, security triage, architectuuradvies en data-classificatie apart. Eén generieke confidence threshold is governance theatre.
Laag 3: Reasoning Redundancy, waarom je agent te veel nadenkt
Paper: How Much Thinking is Enough? Quantifying and Understanding Redundancy in LLM Reasoning, Zhiyuan Zhai et al., Fudan University
Dit is de paper die CFO's én CISO's zouden moeten lezen. De auteurs meten hoeveel reasoning-stappen in LLM-denksporen redundant zijn. Hun methode: neem een correcte reasoning trace, knip stappen van het einde af, forceer het model te stoppen en een antwoord te geven. Meet hoeveel je kunt wegsnijden voordat het antwoord fout gaat.
De resultaten zijn schokkend:
- ρ (redundancy) tussen 61.3% en 92.5% over 4 frontier modellen × 2 benchmarks
- Voor QwQ en Qwen3: meer dan de helft van alle correcte traces heeft een kritische prefix van één enkele stap, de openingszin is genoeg voor het correcte antwoord
- Zelfs op de moeilijkste MATH-500 Level-5 problemen blijft redundancy substantieel: 46-85%
- Externe judge replicatie bevestigt: ρ_ext > 30% in alle condities, ＞50% in 5 van de 8
Het theoretische bewijs
De paper bewijst (Theorem 1) dat dit geen bug is, maar een structurele eigenschap van hoe reasoning-modellen worden getraind. Onder elke outcome-based reward zonder lengte-penalty is geen enkele eindige stopping time optimaal. Modellen worden beloond voor correctheid, niet voor efficiëntie, dus is eindeloos doordenken de optimale strategie.
De fix is eenvoudig: voeg een expliciete lengte-penalty -λT toe aan de reward. Maar totdat modelbouwers dat doen, is het aan deployers om reasoning budgets te controleren.
Strategische implicatie
Redenen heeft een prijs, en die prijs wordt zichtbaar op vijf fronten. Cost governance krijgt een nieuwe parameter: reasoning budget wordt een eersteklas architectuurparameter. In agent orchestration worden stop-criteria, early-exit policies en answer-ready detectors noodzakelijk. Model routing wordt selectiever, niet elke taak mag naar een deep reasoning model. Observability moet reasoning tokens, retries, loops, critical prefix en marginal accuracy gain meten. En procurement? Prijs per token is onvoldoende, meet cost per accepted outcome.
Een Reasoning Budget Controller is geen luxe meer, het is een FinOps-vereiste. De inrichting hangt af van het taaktype. Voor simple lookups is geen deep reasoning nodig: directe uitvoer. Code diff review vraagt medium reasoning, bounded. Security threat models vergen deep reasoning, maar met checkpointed stop. Juridische interpretatie combineert deep reasoning met evidence validation. Agent tool execution gebruikt bounded reasoning plus policy gate. En long-horizon planning is iteratief, niet één lange chain.
Laag 4: Verifiable Transformers, van plausible uitleg naar formeel bewijs
Paper: Towards Verifiable Transformers: Solver-Checkable Circuit Explanations, Neel Somani, Independent Researcher
Mechanistic interpretability heeft een fundamenteel probleem: we vinden circuits in transformers, maar we kunnen niet bewijzen wat ze doen. Validatie gebeurt via voorbeelden, ablaties en handmatige redenering, er blijft een gat tussen "plausibele verklaring" en "bewijs". Deze paper dicht dat gat met Verifiable Transformers: een framework dat task-localized circuits omzet in solver-checkable claims.
De methode werkt in twee sporen. Directe verificatie: het circuit wordt direct geëncodeerd in een SMT (Satisfiability Modulo Theories) solver, waarbij bewijzen en tegenvoorbeelden gelden voor het circuit zelf. Surrogate-mediated verificatie: als operators niet tractabel encodeerbaar zijn (softmax), wordt een SMT-encodable surrogate getraind, gevalideerd tegen het originele circuit, en worden claims geverifieerd tegen de surrogate.
Voor verifieerbaarheid introduceert de auteur een specifieke architectuurstack: Signed L1 BandNorm (ipv LayerNorm), Sparsemax attention (ipv softmax), en LeakyReLU (ipv GELU). Deze stack is SMT-representeerbaar én trainable op GPT-2 schaal, maar directe verificatie blijft intractable op die schaal. De paper is eerlijk over de scope: "The guarantees in this paper are bounded, projected, and circuit-level. The goal is not full-model verification."
De juiste verwachting
Wat betekent dit nu praktisch? Voor model assurance biedt het mogelijke toekomstige bewijsvoering voor afgebakende modelgedragingen. Voor AI Act compliance ondersteunt het traceerbaarheid en verifieerbare verklaringen, maar nog niet op productieschaal. Safety cases kunnen er onderdeel van worden: evidence packs voor specifieke, bounded model capabilities.
De praktische vertaling: verifieer kleine, kritieke subcomponenten formeel, en combineer dat met runtime controls, red-teaming, evals, logging en human oversight. Zie dit als onderzoeksrichting voor "verifiable AI components", niet als oplossing voor complete LLM-governance.
De gecombineerde control stack
Samen suggereren de vier papers een volwassen control stack die verder gaat dan prompt-level safety. De semantic supply chain security-laag (MCP-TDP paper) vraagt: kan de agent zijn toolbeschrijvingen vertrouwen? Confidence calibration (Calibration paper) vraagt: weet het systeem wanneer het mogelijk fout zit? Reasoning budget governance (Redundancy paper) vraagt: stopt het model op tijd, of verbrandt het tokens zonder waarde? En formal local verification (Verifiable Transformers) vraagt: kunnen we specifieke modelgedragingen formeel bewijzen of weerleggen?
De strategische conclusie is onontkoombaar: prompt engineering is geen governance-laag. De toekomst vraagt om policy-enforced agent runtimes, calibrated uncertainty, cost-aware reasoning, signed tool metadata, bounded autonomy en evidence-producing AI systems.
Concrete implicaties
Op basis van deze papers definieer ik zes componenten die essentieel zijn voor een BIO2-compliant agent runtime:
1. MCP Tool Metadata Security Gate. Elke MCP tool krijgt een security manifest met risk level, toegestane agents, scopes, geblokkeerde metadata patterns, en verplichte description hashing en signing.
2. Confidence Calibration Harness. Per taaktype meet je accuracy, confidence, calibration gap, ECE, abstention quality en escalation precision. Geen generieke confidence threshold, per use case gekalibreerd.
3. Reasoning Budget Controller. Harde en adaptieve limieten met early-exit op answer stability, evidence sufficiency en marginal confidence gain.
4. Tool Execution Firewall. Een Zero Trust-laag tussen intentie en actie: policy engine valideert elke tool call op scope, dataclassificatie, tool risk en vereist human approval voor high-impact acties.
5. Evidence Pack per agent run. Voor elke relevante actie: prompt/context hash, tool metadata hash, modelversie, confidence score, reasoning budget used, tool calls, policy decisions, human approvals, en post-action validation.
6. Lokale formele verificatie. Niet complete LLMs bewijzen, wel kleine kritieke componenten: policy engines, token scope mappers, data classifiers, agent routers.
De architectuurregel
Deze papers bevestigen dat enterprise AI volwassen wordt langs dezelfde lijn als cloud security: eerst enthousiasme over capabilities, daarna incidenten, daarna control planes. De praktische les is hard: een agent is geen chatbot met tools, maar een semi-autonome execution environment. Je moet hem behandelen als een combinatie van gebruiker, applicatie, integratieplatform en supply-chain consumer.
Daarom stel ik deze architectuurregel centraal:
No agent may act solely on model reasoning. Every meaningful action must pass through independent policy, calibrated uncertainty, signed tool metadata, bounded reasoning budget, and auditable execution controls.
Prioritering voor CIO's
Niet alle papers vragen om dezelfde urgentie. Het MCP Poisoning-paper heeft de hoogste directe bruikbaarheid: neem het direct op in je MCP threat model en tool governance. Reasoning Redundancy en Confidence Calibration scoren ook hoog, implementeer een reasoning budget controller en zet een calibration harness per use case op. Verifiable Transformers heeft middelmatige directe bruikbaarheid maar potentieel zeer hoge waarde op de lange termijn: monitor de ontwikkelingen en pas toe op kleine kritieke componenten.
Wat organisaties hiermee moeten doen
Deze control stack is geen nice-to-have, het is de minimale set voor BIO2-compliant agent deployment:
- MCP security gates met signed tool metadata, risk-classificatie en policy-enforced toolselectie
- Calibration harnesses per use case, gevalideerd tegen BIO2-classificeerbare taaktypen
- Reasoning budget controllers die token-efficiëntie afdwingen zonder kwaliteitsverlies
- Verifiable subcomponents voor kritieke policy engines, formeel bewezen, niet alleen getest
Voor organisaties die agentic AI willen inzetten onder de AI Act, BIO2 of NIS2: dit is het minimale control-niveau dat nodig is. Prompt guardrails alleen zijn governance theatre, de aanvalsvector is verschoven naar de metadata-laag, en alleen een volledige execution assurance stack dekt dat af.
De vier besproken papers zijn: 2605.24069 (MCP Poisoning), 2605.23909 (Confidence Calibration), 2605.23926 (Reasoning Redundancy), en 2605.24033 (Verifiable Transformers).
Lees ook: Microsoft vraagt om agent governance, ben je klaar voor de AI Act? en OpenSpec: de ontbrekende governance-laag tussen AI en code.
AI & Security Intelligence
Wekelijkse nieuwsbrief met AI updates, security alerts en compliance inzichten, direct in uw inbox.
Security & AI Operating Model
Advisory met executiekracht
Van BIO2 en NIS2 tot EU AI Act, embedded in uw operating model, niet als extern project. Maandelijks opzegbaar, met assessments als bewijsvoering.