De vier lagen van betrouwbare AI-agents — wat vier nieuwe papers betekenen voor de Nederlandse overheid
AI GovernanceIn dezelfde week dat Microsoft de Agent Governance Toolkit uitbracht, verschenen er vier academische papers die elk een fundamentele laag van AI-betrouwbaarheid blootleggen. Samen vertellen ze één verhaal: de volgende fase van AI-governance verschuift van modelkwaliteit naar execution assurance.
Niet langer gaat het alleen om 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?
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.
| Domein | Implicatie | |--------|-----------| | MCP governance | Tool descriptions moeten security-reviewed worden alsof ze policy-bearing code zijn | | Agent runtime | Toolselectie mag niet alleen door modelinterpretatie gebeuren, maar moet policy-gated zijn | | CI/CD | MCP server manifests, tool schemas en descriptions moeten door SAST-achtige checks, diff-review en signing | | Runtime control | High-risk tools vereisen confirm-before-act, least privilege, scoped tokens en output validation | | 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 implicatie voor high-stakes omgevingen is helder:
| Gebruik van confidence | Risico | |------------------------|--------| | Confidence als vrijgavecriterium | Onveilig bij moeilijke taken — juist waar overconfidence piekt | | Confidence als audit evidence | Zwak bewijs, tenzij empirisch gekalibreerd per taaktype | | Confidence als human-in-the-loop trigger | Kan escalaties missen bij complexe cases | | Confidence als model-ranking metric | 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
| Laag | Consequentie | |------|-------------| | Cost governance | Reasoning budget wordt een eersteklas architectuurparameter | | Agent orchestration | Stop-criteria, early-exit policies en answer-ready detectors worden noodzakelijk | | Model routing | Niet elke taak mag naar een deep reasoning model | | Observability | Meet reasoning tokens, retries, loops, critical prefix en marginal accuracy gain | | Procurement | Prijs per token is onvoldoende — meet cost per accepted outcome |
Een Reasoning Budget Controller is geen luxe meer — het is een FinOps-vereiste:
| Taaktype | Default reasoning policy | |----------|-------------------------| | Simple lookup | Geen deep reasoning, directe uitvoer | | Code diff review | Medium reasoning, bounded | | Security threat model | Deep reasoning, maar met checkpointed stop | | Juridische interpretatie | Deep reasoning plus evidence validation | | Agent tool execution | Bounded reasoning plus policy gate | | Long-horizon planning | 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. 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)
- 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
| Niveau | Relevantie | |--------|-----------| | Model assurance | Mogelijke toekomstige bewijsvoering voor afgebakende modelgedragingen | | AI Act compliance | Ondersteunt traceerbaarheid en verifieerbare verklaringen — maar nog niet op productieschaal | | Safety cases | Kan onderdeel worden van 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:
| Control laag | Onderbouwd door | Kernvraag | |-------------|----------------|-----------| | Semantic supply chain security | MCP-TDP paper | Kan de agent zijn toolbeschrijvingen vertrouwen? | | Confidence calibration | Calibration paper | Weet het systeem wanneer het mogelijk fout zit? | | Reasoning budget governance | Redundancy paper | Stopt het model op tijd, of verbrandt het tokens zonder waarde? | | Formal local verification | Verifiable Transformers | 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.
Zes bouwblokken voor de DjimIT stack
Op basis van deze papers definieer ik zes concrete componenten 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
| Paper | Directe bruikbaarheid | Actie | |-------|----------------------|-------| | MCP Poisoning | Zeer hoog | Direct opnemen in MCP threat model en tool governance | | Reasoning Redundancy | Hoog | Reasoning budget controller implementeren | | Confidence Calibration | Hoog | Calibration harness per use case opzetten | | Verifiable Transformers | Middel (lange termijn: zeer hoog) | Monitoren, toepassen op kleine kritieke componenten |
Wat DjimIT hiermee doet
Bij DjimIT bouwen we deze control stack in onze sovereign AI-infrastructuur. We combineren:
- 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.
Doorlopend Advies
Wilt u structurele begeleiding op AI, security & compliance?
Met een Advisory Subscription heeft u een externe sparringpartner die meedenkt op strategisch en technisch niveau — zonder de overhead van een fulltime dienstverband. Vanaf €1.500 per maand, maandelijks opzegbaar.
Ontdek Advisory Subscription →