Agentic AI is geen LLM met tools — OWASP herdefinieert het dreigingsmodel

Op 1 juni 2026 publiceerde het OWASP Gen AI Security Project versie 2.01 van de State of Agentic AI Security and Governance. Het is een document dat elke CISO, CIO en enterprise architect zou moeten lezen — niet omdat het baanbrekend nieuw onderzoek bevat, maar omdat het een fundamentele herkadering doorvoert.

Agentic AI is geen "LLM-applicatie met extra tools". Het is een nieuw operationeel risicodomein. En wie het nog behandelt als een modelrisico, mist de boot.

De governance-reset

Wat me meteen opviel: OWASP positioneert agentic AI niet als een uitbreiding van het bestaande LLM-dreigingsmodel, maar als een eigenstandig domein met vier pijlers:

Agent identity. Niet "kan deze API-key verbinden?", maar "wie handelt namens wie, onder welke delegatie, binnen welke bevoegdheidsgrens, op dit moment, met deze tool?"

Tool authorization. Welke acties, API's, bestanden, repositories, CI/CD-paden en SaaS-systemen mag de agent gebruiken — per actie, per context, per delegatieketen.

Runtime governance. Monitoring, drift-detectie, policy enforcement, kill switches en audit-grade telemetrie. Niet als periodieke audit, maar als continue control loop.

Supply-chain governance. SBOM en AIBOM, maar ook MCP-servers, skills, plugins, model endpoints, datasets, RAG-bronnen, connectors en delegated agents. Alles wat dynamisch tijdens runtime kan worden ingeschakeld.

Traditionele non-human identity — service accounts, API keys, OAuth credentials — valideert vooral of een entiteit mag verbinden. Agent identity moet continu toetsen wat de agent op dat moment probeert te doen, onder welke context, met welke tool, en binnen welke bevoegdheidsgrens. Dat is een fundamenteel andere denkwijze.

Drie assen die ertoe doen

OWASP hanteert een taxonomie langs drie assen: agenttype, implementatiepatroon en compositiepatroon. Dit is sterker dan simplistische "Level 1-5 autonomy" classificaties, omdat risico's niet alleen afhangen van wat de agent doet, maar ook van hoe hij gebouwd is en hoe hij samenwerkt met andere agents.

Een low-code Copilot Studio-flow, een Claude Code-agent met shell access, een LangGraph multi-agent workflow en een MCP-gekoppelde infrastructuuragent hebben fundamenteel andere detectie-, audit- en containment-eigenschappen.

De implementatieanalyse is bijzonder relevant. OWASP maakt onderscheid tussen:

• Full orchestration frameworks (LangGraph, CrewAI, AutoGen, Dify, Google ADK, OpenAI Agents SDK, Claude Code, Codex): bieden vaak tracing en hook points, maar geen volledige security out of the box.
• Lightweight library composition (LiteLLM, directe OpenAI/Anthropic SDK's): meer controle, maar vereist zelfgebouwde logging, policy enforcement en auditability.
• Platform-native/low-code agents: het hoogste shadow-AI-risico, omdat citizen developers vaak buiten security review deployen.

Coding agents verdienen speciale aandacht. Ze krijgen shell access, file system-toegang, git-operaties, en soms cloud/CI/CD-rechten. De attack surface verschuift van "slechte code-output" naar de volledige software delivery chain. Een geïnjecteerde prompt via een poisoned file kan doorwerken naar sub-agents. Agent-generated commits kunnen provenance en SLSA-garanties verzwakken als review en branch protection niet op repositoryniveau worden afgedwongen.

De ASI Top 10: van hypothetisch naar productie-incidenten

OWASP stelt expliciet dat agentic risico's niet meer hypothetisch zijn. Ze worden ondersteund door productie-incidenten, vendor advisories en CVE's. De publicatie koppelt het 2026 threat landscape aan de OWASP Top 10 for Agentic Applications.

De meest urgente categorieën:

ASI01 — Agent Goal Hijack. De dominante aanvalsvorm. Niet alleen directe prompt injection, maar ook indirecte injectie via documenten, e-mail, tickets, CRM-records, websites, logs of repositorybestanden.

ASI02 — Tool Misuse and Exploitation. Een agent met brede tooltoegang wordt gemanipuleerd tot destructieve acties, dataverwijdering of ongeautoriseerde resource access.

ASI03 — Identity and Privilege Abuse. Volgens OWASP de grootste kloof tussen risicoseverity en organisatorische preparedness.

ASI04 en ASI05 — Agentic Supply Chain Vulnerabilities en Unexpected Code Execution. Hoge incidentvolumes rond MCP, skills, coding IDE's en runtime execution.

ASI06 — Memory and Context Poisoning. Persistent memory, RAG, session state, agent logs en cross-session context als aanvalsvector.

Dit laatste raakt direct aan de Supermemory-analyse van vorige week. De MemoryTrap-kwetsbaarheid die Cisco in Claude Code vond — waarbij een kwaadaardige payload in een gekloonde repo via normaal ontwikkelwerk persistent memory, global hooks en uiteindelijk de system prompt bereikte — is het schoolvoorbeeld van ASI06. Anthropic fixte het in Claude Code v2.1.50, maar de bredere vraag blijft: hoeveel andere agentic tools behandelen memory nog steeds als impliciet betrouwbaar?

Voor MCP-connected, multi-agent en cross-boundary agents komen daar ASI07 tot ASI10 bij: insecure inter-agent communication, cascading failures, human-agent trust exploitation en rogue agents. Zodra agents onderling communiceren, worden foutpropagatie en vertrouwensketens een eigen risicocategorie.

Het maturity model: sterk voor de boardroom, onvoldoende voor implementatie

OWASP combineert twee dimensies in een governance maturity model: Adoption Tier (AT0 tot AT8) en Governance Maturity Level (0 tot 4).

De adoptietiers lopen van shadow AI naar embedded assistants, custom GPT's, citizen-developer agents, code-executing agents, custom in-house agents, externally extended agents, multi-agent orchestration en federated/cross-boundary agents. Voor de meeste enterprise-agent stacks — Claude Code, Codex-workflows, MCP-servers, LiteLLM-proxies, multi-agent orchestration — zit je ergens tussen AT4 en AT7.

Het maturity model loopt van Level 0 (ad hoc, unaware) naar Level 3 (continuous oversight) en Level 4 (adaptive governance). OWASP stelt dat Level 2 onvoldoende is zodra agents code uitvoeren, infrastructuur raken of meerdere systemen orkestreren. Level 3 is de minimale doelpositie: realtime monitoring, anomaly detection, kill switches, machine-readable policies en integratie met observability-platformen.

Mijn kritiek: het model is sterk als board-level assessment, maar te weinig operationeel voor implementatie. Je moet het vertalen naar concrete controls: OAuth2/OIDC-tokenprofielen, agent-scoped credentials, policy-as-code, repository enforcement, MCP allowlisting, runtime attestation, immutable audit logs, network egress controls, DLP, sandboxing, approval gates, rollback en incident response playbooks.

De supply chain die je niet in je SBOM ziet

Traditionele SBOM's beschrijven wat statisch is geïnstalleerd. Agentic supply-chain security moet runtime composition en delegated authority afdekken: welke tools, MCP-servers, plugins, skills, RAG-bronnen, model endpoints en sub-agents kunnen tijdens uitvoering worden ingeschakeld, en onder wiens autoriteit handelen zij?

Voor enterprise-architectuur betekent dit: behandel een agent workflow als een tijdelijke, dynamisch samengestelde software supply chain. Een AIBOM moet niet alleen model, dataset en code bevatten, maar ook tool registry, MCP-serverlijst, connectorversies en scopes, model endpoint en provider, prompt/skill provenance, runtime invocation trace, delegation chain, credential scope en expiry, policy decisions, human approvals, output artifacts en commit provenance.

Dit sluit direct aan op ISO 27001 asset management, NIST CSF, SLSA, Sigstore/cosign, CycloneDX/SPDX en secure SDLC. Maar het vraagt om tooling die nog nauwelijks bestaat — de acht gap-gebieden die OWASP zelf identificeert (agent identity, runtime containment, architectural monitoring, supply chain attestation, schema controls) zijn letterlijk een product-roadmap.

Agent identity: de OAuth2-reset

De interessantste verschuiving is OWASP's onderscheid tussen traditionele non-human identity (NHI) en agent identity. Voor agents is "credential present" geen voldoende autorisatiecriterium. Je hebt continue, contextuele autorisatie nodig per actie.

OWASP wijst op komende standaardisatie rond agent-specific identity, OAuth 2.0, policy-based access control, recursive delegation, multi-agent token exchange en MCP's OAuth 2.1 resource-indicator-scoped tokens.

Praktisch betekent dit:

• Gebruik nooit gedeelde long-lived API keys voor agents
• Short-lived, audience-bound, resource-scoped tokens
• Onderscheid tussen user-delegated tokens en agent-owned workload identity
• Beperk delegation depth: een parent agent mag geen onbeperkte child agents met afgeleide rechten creëren
• Leg token lineage vast: wie gaf welke bevoegdheid, voor welk doel, met welke TTL, naar welke tool
• Forceer revocation propagation: intrekking van parent authority moet child sessions en delegated tools beëindigen
• Step-up approval voor high-impact acties: git push, delete, deploy, IAM-change, cloud spend, e-mail send, database mutation, external data transfer

Compliance: GDPR art. 22 en NIS2 zijn geen bijzaak

OWASP koppelt agentic AI expliciet aan GDPR, NIS2, DORA, EU AI Act en product liability.

GDPR Article 22 legt een harde ondergrens: volledig geautomatiseerde besluiten met rechtsgevolg of vergelijkbaar significant effect zijn verboden zonder expliciete waarborgen. Agent memory, RAG pipelines en cross-session context raken direct aan dataminimalisatie, opslagbeperking en het recht op vergetelheid. Elke agent die persistent onthoudt wat gebruikers doen, moet kunnen aantonen dat dit noodzakelijk en proportioneel is.

NIS2 is minstens zo belangrijk. OWASP legt de link met human-equivalent access control voor AI-agents, 24-uurs early warning en supply-chain security voor third-party tools, API's en model endpoints. Agent telemetrie, incidentclassificatie en containment zijn geen "nice to have" — ze worden onderdeel van aantoonbare cyberweerbaarheid. De toezichthouder gaat vragen: "Kun je aantonen dat je agent niet zelf het incident was?"

Een control baseline die direct toepasbaar is

Op basis van OWASP's framework kom ik tot deze minimale baseline voor een volwassen agentic platform. Dit is geen academische exercitie — dit zijn de controls die elke organisatie moet hebben voordat ze agents productie laten raken.

Zero Trust. Expliciete agentidentiteit, least privilege, continuous verification, geen impliciet vertrouwen tussen agents.

OAuth2/OIDC. Short-lived scoped tokens, audience restrictions, PKCE waar relevant, token exchange met delegation constraints, geen gedeelde secrets.

Secrets. Vault-backed, rotation, no plaintext env dumps. Geen secrets in prompts, logs of memory. Dit klinkt vanzelfsprekend — totdat je beseft dat de meeste coding agents hun eigen .env-bestanden lezen.

MCP security. Server allowlist, schema validation, tool descriptor sanitization, resource-scoped authorization, egress filtering, signed servers. Elke MCP-tool die je toevoegt is een uitbreiding van je trust boundary.

Runtime. Sandboxing, read-only default filesystem, command allowlist plus semantic risk policy, deterministische pre-tool gates, post-tool audit. Agents moeten niet kunnen schrijven tenzij expliciet toegestaan.

CI/CD. Branch protection, signed commits, mandatory review voor agent-generated code, SAST/DAST/SCA/secret scanning, SBOM generation. De agent is een contributor, niet de maintainer.

Observability. Immutable audit trail, OpenTelemetry-compatible traces, SIEM-integratie, anomaly detection, kill switch. Als je niet kunt zien wat je agent deed, kun je niet aantonen dat hij compliant was.

Governance. AI system register, AIBOM, DPIA waar van toepassing, risk acceptance, model/tool/vendor register, incident playbooks.

Compliance. GDPR Article 22 review, NIS2 incident routing, ISO 27001 control mapping, EU AI Act classificatie, data retention and erasure process.

De zwakte van het document

Het document is sterk als maturity- en board-alignmentdocument, maar nog geen volledig implementatiehandboek. De grootste waarde zit in drie reframings: agent identity als control plane, runtime governance als vervanging van statische compliance, en AI supply chain als dynamische execution/authority chain in plaats van alleen dependency inventory.

Maar voor echte enterprise readiness moet je het combineren met concrete architectuurpatronen. Vier lagen:

1. Identity & Delegation. Wie handelt, onder wiens autoriteit, met welke scope, voor hoe lang?
2. Tool & Runtime Control. Welke acties zijn toegestaan, onder welke voorwaarden, met welke gating?
3. Supply Chain & Provenance. Wat is het volledige runtime-compositieplaatje, inclusief dynamisch ingeschakelde componenten?
4. Monitoring & Incident Response. Detectie, containment, forensische traceerbaarheid, kill switch.

Die vier lagen samen vormen wat ik het DjimIT Agentic AI Control Framework zou noemen — niet als commercieel product, maar als referentiearchitectuur die OWASP bestuurbaar, auditable en direct toepasbaar maakt op zowel een interne development-stack als enterprise-klantcontexten.

---

Het OWASP State of Agentic AI Security and Governance 2.01 is beschikbaar op genai.owasp.org. De AIUC-1 crosswalk met de OWASP Top 10 for Agentic Applications staat hier.