Anthropic publiceert Zero Trust blauwdruk voor AI-agents. Dit is wat er nog ontbreekt.

Anthropic publiceerde op 18 mei 2026 een 36-pagina's tellend eBook: Zero Trust for AI Agents — A security framework for deploying autonomous AI agents in the enterprise. Het is een van de eerste documenten die Zero Trust principes concreet toepast op agentic AI, en het is verrassend goed. Dit is geen marketingfolder — het is een maturity baseline die je direct kunt gebruiken.

Maar voor productiegebruik in gereguleerde sectoren is het document niet compleet. Het ontbreekt aan harde policy-as-code, data-classificatie, BIO2/NIS2-mapping, cost governance, en compliance evidence. Die gaten zijn precies waar organisaties in 2026 tegenaan lopen — en waar wij als DjimIT de brug slaan.

Dit is onze analyse.

Wat het document goed doet

Anthropic behandelt agentic AI als een nieuw type non-human workload met eigen risico's. Een agent is geen chatbot maar een uitvoerende entiteit die doelen interpreteert, tools kiest, API's aanroept, context bewaart en andere agents aanstuurt. Daarmee verschuift security van "mag deze gebruiker dit systeem benaderen?" naar "mag deze specifieke agent, namens deze actor, voor deze taak, met deze context, deze actie uitvoeren, op dit moment, met deze data?"

Drie sprongen die het document maakt:

1. Van least privilege naar "least agency". Niet alleen beperken welke systemen een agent mag benaderen, maar ook welke acties, frequenties, toolketens, parameters en escalaties zijn toegestaan. De term komt uit OWASP's Top 10 for Agentic Applications 2026 en is het fundament onder Zero Trust voor agents.

2. Van statische API keys naar cryptografisch gewortelde agent-identiteiten. Static keys worden expliciet onvoldoende genoemd, zelfs voor de minimale Foundation-tier. Voor productie-agents zijn short-lived, scoped, auditable identities noodzakelijk.

3. Van monitoring achteraf naar runtime enforcement. Logging is niet genoeg. Agent-acties moeten vóór uitvoering gevalideerd worden, bij voorkeur buiten de agent zelf — een PreToolUse policy gate.

Het eBook hanteert een briljant auditprincipe: de "impossible vs. tedious"-test. Maakt je controle de aanval onmogelijk, of alleen maar vervelend? Agentic attackers hebben onbeperkt geduld en bijna nul kosten per poging. Een throttle of rate limit vertraagt ze, maar stopt ze niet. Alleen harde barrières — hardware-bound credentials, expiring tokens, cryptografische identiteit, netwerkpaden die niet bestaan — overleven deze test. Dit principe alleen is consultancygoud waard.

De drie maturity tiers

Het document structureert Zero Trust in drie opbouwende tiers:

Tier	Voor wie	Kern
Foundation	MKB, kleine teams	Short-lived tokens, cryptografische identiteit, identity-based isolation, geautomatiseerde first-pass triage
Enterprise	De meeste organisaties	Multi-agent deployments, ABAC, hardware-bound credentials, sandboxing, volledige audit trail
Advanced	Zeer gereguleerd, nationale veiligheid	Hardware-rooted identity, JIT access, real-time gedragsanalyse, air-gapped approval workflows

Opvallend: Foundation is bewust opgehoogd omdat AI-accelerated offense de baseline heeft veranderd. Wat vorig jaar "advanced" was, is nu "entry-level". Dit sluit aan bij onze eerdere analyse van AI-veiligheidsonderzoek waarin we dezelfde verschuiving signaleerden.

Voor onze praktijk is Enterprise de minimale standaard. Foundation is alleen acceptabel voor gecontroleerde proof-of-concepts — lokale development, read-only tools, geen gevoelige data, geen externe side effects. Zodra een agent kan schrijven, mailen, deployen, scannen, credentials gebruiken of tickets aanpassen, is Foundation te laag.

Vijf dreigingscategorieën die je nú moet kennen

Het eBook beschrijft een volwassen threat taxonomy die goed aansluit op OWASP's werk:

1. Prompt injection. Direct (gebruikersinput) én indirect (geïnfecteerde webpagina's, documenten, RAG-bronnen). Microsoft Research bevestigt: LLM's kunnen niet betrouwbaar onderscheid maken tussen informatie en instructies. Dit is exact het aanvalsmechanisme dat we analyseerden in onze EchoLeak forensische reconstructie.

2. Tool & resource misuse. Tool poisoning (MCP-server vervangen), tool chaining (combineer legitieme tools tot exfiltratie), resource exhaustion (loop amplification leidt tot DDoS/billing spikes). De eerste in-the-wild malicious MCP-server is al gedocumenteerd: hij deed zich voor als een legitieme email-tool en kopieerde stiekem alle verzonden emails.

3. Identity & privilege abuse. Unscoped privilege inheritance (manager-agent deelt volledige rechten met worker), confused deputy in multi-agent systems, memory-based privilege retention (cached credentials over sessies heen).

4. Supply chain risks. Model poisoning — Anthropic's eigen onderzoek toont aan dat 250 kwaadaardige documenten volstaan om een LLM te backdooren, en die backdoor overleeft supervised fine-tuning én RLHF. Tool supply chain: de PyTorch dependency confusion attack exfiltreerde SSH-sleutels tijdens package installatie. Security researchers vonden circa 100 kwaadaardige AI-modellen op grote platforms.

5. Memory & context poisoning. RAG poisoning, shared context in multi-tenant omgevingen, long-term memory drift — subtiele bias-verschuiving over tijd die geen enkele losse actie als "malicious" laat oplichten.

Zeven implementatiefases

Het document vertaalt de principes naar zeven concrete implementatiefases:

1. Agent identity — unieke cryptografische identiteit per agent-instantie
2. Network isolation — identity-based microsegmentatie
3. Agent boundaries — approved/prohibited actions, escalation triggers, blast radius
4. Prompt injection defense — input isolation, constitutional classifiers
5. Tool access — allow-listing, parameter validation, sandboxing
6. Credential protection — short-lived tokens, hardware-bound credentials, JIT access
7. Memory safeguarding — isolatie tussen sessies, context integrity validation

Voor wie met Claude Code werkt, zit een aanzienlijk deel van deze controls al in de tooling: unieke session.id per sessie, OAuth 2.0 met automatic token refresh, sandboxing met filesystem- en netwerkisolatie, PreToolUse hooks, en configurable retention policies. Maar voor MCP-servers, Telegram-bots, en custom agents moet je deze controls zelf bouwen — en dat is waar de meeste organisaties struikelen.

Wat ontbreekt: de zes blinde vlekken

Dit is waar het document tekortschiet voor enterprise en gereguleerde inzet:

1. Policy-as-code ontbreekt als harde kern

Zonder OPA/Rego, Cedar, Kyverno, Gatekeeper of vergelijkbare policy engine blijft veel afhankelijk van configuratie en conventie. Agent policies moeten afdwingbaar zijn op infrastructuurniveau, niet alleen als prompt-instructie waar een model zich "aan probeert te houden." We onderscheiden vier lagen:

• Model policy: wat het model probeert te weigeren
• Agent policy: wat de agent runtime mag plannen
• Tool policy: wat tool calls technisch toestaan
• Infrastructure policy: wat OS, container, netwerk, IAM daadwerkelijk afdwingen

Alleen laag 3 en 4 zijn echt betrouwbaar. Laag 1 en 2 zijn nuttig, maar niet voldoende.

2. Geen expliciete data-classificatie lifecycle

Agent policies moeten gekoppeld zijn aan dataclassificaties: publiek, intern, vertrouwelijk, bijzonder, geheim, persoonsgegevens, bijzondere persoonsgegevens, security-sensitive. Zonder deze koppeling weet een agent niet of hij gevoelige data leest, schrijft of exporteert — het model ziet alleen "een string."

3. Cost governance is onvoldoende

Denial-of-wallet is voor LLM agents een eersteklas risico. Budget, token rate, retry loops, context growth en tool loops moeten harde controls zijn, geen suggesties. Een agent die 12 uur in een loop draait met een cloud-model kan een AWS-factuur van duizenden euro's veroorzaken voor een taak die geen waarde opleverde.

4. Prompt/tool provenance

Je moet kunnen bewijzen welke versie van een prompt, tool schema, model, memory en policy actief was op het moment van uitvoering. Zonder provenance is elk incident een gokspel: "welke configuratie was actief toen dit gebeurde?"

5. Multi-agent trust is onderontwikkeld

Agent-to-agent communicatie moet behandeld worden als inter-service communication met mutual auth, policy checks, message signing, schema validation en replay protection. Het eBook erkent het probleem maar biedt geen architectuur.

6. Compliance evidence is niet uitgewerkt

Voor gereguleerde sectoren moet iedere control automatisch bewijs opleveren: logs, config snapshots, policy decisions, approvals, testresultaten, SBOM's en attestation records.

Directe vertaling naar een control plane

Voor wie Zero Trust voor agents wil operationaliseren, hier is de minimale architectuur:

1. Agent identity. Elke agent een unieke identiteit. Geen gedeelde API keys. Geen "bot token" dat alles mag. Short-lived tokens, workload identity, audience-bound tokens, scoped OAuth2/OIDC waar relevant.

2. Tool allowlisting. Elke agent krijgt een expliciete tool allowlist, deny-by-default. Voor een website-scanner: HTTP HEAD/GET toegestaan, POST/bruteforce/login geblokkeerd.

3. PreToolUse policy gate. Elke tool call valideren vóór uitvoering: mag deze agent deze tool gebruiken? Past de actie binnen de taak? Zijn parameters veilig? Is menselijke goedkeuring nodig?

4. Sandboxing. Shell, browser, crawler, scanner en MCP tools in container of microVM, read-only filesystem waar mogelijk, egress allowlist, resource quota.

5. Memory governance. Onderscheid tussen conversation memory, task memory, project memory, en security-sensitive memory. Voor persistent memory: provenance, timestamp, source, confidence, expiry, owner, tamper detection.

6. Audit en replay. Iedere agentactie reconstructable: wie gaf de opdracht, welke agent identity, welk model, welke prompt versie, welke tools, welke policy decision, welke output.

De commerciële propositie

Anthropic zegt het zelf: "This guide is offered as a framework for your own evaluation, not as legal, compliance, or security assurance for any particular environment." Dat is de opening.

Voor organisaties die agentic AI inzetten — van Claude Code tot MCP-servers tot interne agents — is de compliance-laag tussen Anthropic's raamwerk en de Nederlandse wet- en regelgeving onbestaand. BIO2, NIS2, AVG en de EU AI Act stellen harde eisen aan logging, toegangscontrole, supply-chain security en incident response die het eBook wel benoemt maar niet operationaliseert.

DjimIT's propositie: "Agentic Zero Trust Readiness Assessment." Een beoordeling van of autonome AI veilig, auditbaar en beheersbaar mag handelen binnen jouw organisatie. Geen generiek advies, maar concrete controls: agent inventory, tool risk assessment, identity review, prompt injection exposure analysis, runtime policy design, BIo2/NIS2 compliance mapping, en een 30/60/90-dagen roadmap.

De organisaties die nú een governance-laag bouwen, bepalen hoe compliance voor agentic AI eruit gaat zien. De rest moet rennen als de eerste AI-gerelateerde datalekken bij de Autoriteit Persoonsgegevens liggen.

---

Anthropic's Zero Trust for AI Agents eBook is hier te downloaden.