Agentic AI Security Reference Architecture

Agentic AI Security Reference Architecture (AAI-S RA)

The Agentic AI Security Reference Architecture (AAI-S RA) secures agentic AI applications under a vendor-neutral trust model. A single layered design covers every common deployment shape: web and desktop chatbots, generative coding tools, data-science copilots, RAG systems, MCP servers, agent skills, and multi-agent meshes.

On this page

• What this RA delivers
• Design principles
• The six planes
• Mapping to deployment shapes
• Threat-control matrix (OWASP Agentic AI Top 10 → planes)
• Trade-offs
• Gaps in the architecture
• Prior work and comparison

block-beta
  columns 2
  
  User(["Human user"]):2
  
  Identity["Identity plane"]:2
  
  Control["Control plane"]:2
  
  Runtime["Runtime plane"]:2
  
  Egress["Egress plane"]
  Data["Data plane"]
  
  Obs["Observability plane"]:2

  classDef pip stroke:#0d6efd
  classDef pdp stroke:#fd7e14
  classDef pep stroke:#dc3545
  classDef mixed stroke:#6f42c1
  classDef user stroke:#198754
  
  class User user
  class Identity pip
  class Control pdp
  class Runtime pep
  class Egress pep
  class Data mixed
  class Obs pip

What this RA delivers

The architecture below is the implementation surface of an oversight layer: the system that monitors, evaluates, and intervenes in AI agent behavior in production. The six planes decompose the layer into the four roles codified in NIST SP 800-162 §2.2: PDPs (Policy Decision Points, concentrated in Control), PEPs (Policy Enforcement Points, distributed across Runtime / Egress / Data), PIPs (Policy Information Points, spanning Identity / Data / Observability), and PAP (Policy Administration Point, cross-cutting policy lifecycle). The Sentinels and Operatives split (PIPs feed PDP+PEP) is the runtime decomposition. The goal is verified accountable autonomy: agents act independently, but every action is verifiable, auditable, and bounded by enforced policy.

Gartner calls this layer a guardian agent in its procurement taxonomy. The architectural primary term (oversight layer / PDP+PEP) applies when discussing components; the procurement synonym (guardian agent) applies when discussing vendor categories. See Oversight Layer (PDP + PEP for Agentic AI) §Cross-walk for the full term comparison.

Design principles

Five principles anchor the architecture, drawn from Q1 2026 incident data and practitioner consensus.

1. Platform-level enforcement, not prompt-level. Every control that matters runs in the runtime/platform, below the model. Prompt-level guardrails are bypassable by definition. (Consensus across AI Security Standards in Q1 2026: Agentic Threats Outpace Frameworks, Emerging Cybersecurity Practices for Agentic AI Applications, Securing the Autonomous Future: Trust, Safety, and Reliability of Agentic AI.)
2. Least agency, not just least privilege. Autonomy and agency are distinct governable dimensions: agency is the scope of permitted actions; autonomy is the degree of independent decision-making within that scope (definitions per the AWS Agentic AI Security Scoping Matrix). An agent’s allowed tier (auto / notify / confirm / block) is set per-action, not per-agent. (OWASP, Least Agency Principle.)
3. Verifiable identity for every actor. Every agent has a cryptographic identity that traces back to a human. Action-to-identity binding is the foundation for audit, revocation, and compliance. (AI Agent Identity Architecture, NIST CAISI Concept Paper, Feb 2026.)
4. No agent owns credentials. The credential proxy pattern is load-bearing; 5+ tools converged on it independently. Even successful prompt injection cannot extract credentials that never enter context. (Credential Proxy Pattern for AI Agents.)
5. The “Lethal Trifecta” is a structural test. Any deployment combining private data, untrusted content, and external comms is unconditionally vulnerable. The architecture must break the trifecta at the platform layer. (Lethal Trifecta, Simon Willison.)

Competing evidence on principles 1 and 5

See Wiki Novelty and Counter-Arguments §Thesis 1 (platform vs prompt) and §Thesis 3 (Lethal Trifecta).

Principle 1: the framing is hierarchy, not exclusivity. Prompt-layer guardrails reduce ASR materially (LlamaFirewall PromptGuard 2 on AgentDojo: 17.6%→7.5%, combined with AlignmentCheck to 1.75%; Anthropic Constitutional Classifiers: 86%→4.4% jailbreak success).¹ Platform-layer is primary because injection cannot bypass it; prompt-layer is residual-risk reduction. RAG hardening + system-prompt architecture pages already carry residual-risk callouts in this spirit.

Principle 5: “unconditionally vulnerable” is design-time pedagogy. In production, Stripe’s containment architecture runs trifecta agents and reports 1.5–6.7% ASR depending on model (single-source practitioner data, not independently replicated): probabilistically exploitable, not unconditional. The Lethal Trifecta is necessary for natural-language exfil at scale and sufficient given current defense maturity to require platform-layer containment. Containment can drive ASR very low but not to zero, which remains unacceptable for high-risk-tier actions.

The six planes

The architecture decomposes into six logical planes. Multiple planes may be implemented by a single product, but the controls must be addressable independently.

Plane order reflects action flow (User → Identity → Control → Runtime → Egress / Data). Each plane is annotated with its XACML role (PIP / PDP / PEP / PAP). Observability spans the bottom as a cross-cutting plane consuming signals from all five above.

Each plane table carries a Type column classifying its reference implementations: OSS (open-source software), COTS (commercial off-the-shelf vendor product or SaaS), Std (formally governed standard or specification: IETF, CNCF, OWASP, NIST), Infra (generic infrastructure primitive such as a cloud VPC or Docker networking), Research (academic prototype with no shipped production implementation), Concept (architectural concept without a canonical implementation yet), and Exploratory (forward-looking prototype or ecosystem project, e.g., OpenClaw, that indicates where agentic security is heading; treat as an emerging indicator, not a foundational control). Many rows combine types (e.g., “OSS + COTS”) where a capability has both free and commercial implementations in common use.

block-beta
  columns 2
  
  User(["Human user"]):2
  
  Identity["Identity plane · PIP-side<br/>Workload identity · Agent lifecycle<br/>NHI governance · Credential proxy"]:2
  
  Control["Control plane · PDP + PAP<br/>Policy evaluation · Capability tokens<br/>Least-agency tiers · HITL"]:2
  
  Runtime["Runtime plane · PEP (in-process)<br/>Lifecycle hooks · Input filtering<br/>CoT auditing · Code scanning<br/>Sandboxing"]:2
  
  Egress["Egress plane · PEP (broker)<br/>Agent/MCP proxy · Tool authorization<br/>Tool integrity · Egress filtering"]
  Data["Data plane · PIP + PEP<br/>AI-BOM · RAG provenance<br/>Memory integrity · State rollback<br/>Supply-chain scanning"]
  
  Obs["Observability plane<br/>PIP (cross-cutting)<br/>Distributed tracing<br/>Behavioral monitoring · AI-SPM<br/>Red-team integration"]:2

  classDef pip fill:#cfe2ff,stroke:#0d6efd,color:#000
  classDef pdp fill:#fff3cd,stroke:#fd7e14,color:#000
  classDef pep fill:#f8d7da,stroke:#dc3545,color:#000
  classDef mixed fill:#e2d5f3,stroke:#6f42c1,color:#000
  classDef user fill:#d1e7dd,stroke:#198754,color:#000
  
  class User user
  class Identity pip
  class Control pdp
  class Runtime pep
  class Egress pep
  class Data mixed
  class Obs pip

The six planes map one-to-one onto the CMM’s per-plane domains: Identity ↔ D2, Control ↔ D3, Runtime ↔ D4, Egress ↔ D5, Data ↔ D6, Observability ↔ D7.

The domain recalibration carries six calibration points into this architecture:

1. Identity-first sequencing. Per-agent identity is the prerequisite for per-agent egress and observability (the D2→D5 and D2→D7 caps), so build the Identity plane before investing in Egress or Observability.
2. Per-task capability tokens remain leading-edge. As of 2026-Q2 no hyperscaler platform ships them natively; the only implementation is the early-stage Tenuo OSS primitive (see D2, which places them at L5+).
3. The Control plane now has platform-native PDPs: AWS AgentCore Policy (GA) and the Microsoft Agent Governance Toolkit (OSS).
4. Runtime’s reasoning-layer controls are preview, not GA: chain-of-thought auditing and groundedness checks.
5. The Data plane’s load-bearing control for a closed-corpus bot is answer-time entitlement enforcement against oversharing / inference exposure, not corpus attestation; the Azure RAG chatbot security profile works this case end to end.
6. Licensing is near-zero for an E5 incumbent across most planes; the real cost is labor and SIEM run-rate.

For an all-Microsoft deployment, the 2026-Q2 ZT4AI review maps named, deep-linked controls to each plane: Entra Agent ID and Conditional Access (Identity), least-action design plus the Agent Governance Toolkit PDP (Control), Prompt Shields with preview Groundedness / Task Adherence (Runtime), Entra Internet Access and the APIM AI Gateway (Egress), Purview answer-time entitlement and DSPM (Data), Defender XDR and Sentinel agentic-SOC tooling (Observability). The preview status of the adaptive Runtime and Observability controls is what the recalibration’s grading reflects.

1. Identity plane

The Identity plane binds every agent to a verifiable identity that traces back to a human principal. It covers workload identity, agent and Non-Human Identity (NHI) lifecycle governance, the credential-proxy primitive, action-to-identity tracing, and OAuth 2.1 / OIDC delegation extensions for agents.

Capability	Reference implementation	Type	Status
Workload identity	SPIRE	OSS + Std	Mature
Agent identity & lifecycle	Microsoft Entra Agent ID + Agent 365 Registry (GA May 1, 2026); AWS Bedrock AgentCore identities (GA); GCP Agent Identity (GA, SPIFFE-based); Okta for AI Agents (Early Access; GA expected FY27)	COTS	GA platform-native on all three hyperscalers
Non-Human Identity governance	Aembit, Astrix Security, CyberArk Conjur, Okta NHI, Oasis Security	COTS	Developing
Credential proxy	AgentKeys, Keychains.dev, Aegis (local), OneCLI, AgentSecrets	OSS / COTS	Developing — 5-tool convergence
Action-to-identity tracing	Microsoft Agent 365, Anthropic Compliance API (Mar 24, 2026)	COTS	Mature (vendor-stack-locked)
OAuth 2.1 / OIDC for agents	Standard OIDC + NIST CAISI Concept Paper extensions (Feb 2026)	Std	Developing

The credential proxy is the load-bearing control of this plane. Five OSS and commercial tools converged on the same architecture independently. A credential that never enters the model’s context cannot be extracted by prompt injection. See Credential Proxy Pattern for AI Agents.

2. Control plane

The Control plane adjudicates policy and issues capability tokens before an agent’s tool call reaches the runtime. It evaluates Cedar / OPA Policy Decision Points, issues task-scoped Warrants, runs the OWASP four-tier least-agency engine, gates high-impact actions through HITL, and applies CSA ATF risk-based step-up.

Capability	Reference implementation	Type	Status
Policy language / PDP engine	Cedar, Rego; platform-native PDPs: AWS Bedrock AgentCore Policy (Cedar, GA Mar 2026), Microsoft Agent Governance Toolkit (OSS, sub-0.1 ms)	OSS + COTS	GA platform-native
Capability tokens / Warrants	Tenuo Warrants — task-scoped, signed, ephemeral, holder-bound capability authorizations with monotonic attenuation (the ambient-to-derived authority shift)	OSS	Leading-edge — no platform-native implementation; single early-stage OSS primitive
Least-agency tier engine	OWASP four-tier (auto / notify / confirm / block)	Std	Conceptual; needs reference implementation
Tool annotation enforcement	Anthropic tool annotations, OpenAI function-call schemas; Stripe Toolshed annotation PEP	COTS	Mature
HITL primitive	Human-in-the-loop confirmation gate before high-impact tool calls; Plan-Validate-Execute deterministic gate (Google Workspace); distributed kill switch for halt authority	Concept + Practice	Developing
Risk-based step-up	CSA Agentic Trust Framework v1.0 (Feb 2, 2026) — 4 maturity levels gated by 5 promotion gates2	Std	Developing

The control plane breaks the Lethal Trifecta. If a tool call combines private-data scope, untrusted-content provenance, and external-comms reach, the PDP downgrades to a safer tier (notify or confirm) or denies the call.

3. Runtime plane

The Runtime plane defends the agent process itself. It installs lifecycle hooks (Google ADK, Anthropic), filters input for prompt injection, audits chain-of-thought alignment, scans code output statically, classifies content safety, and sandboxes each task. At research stage, it also separates the privileged and quarantined LLMs.

Capability	Reference implementation	Type	Status
Lifecycle hooks	Google ADK before_model_callback / before_tool_callback; Anthropic tool-use hooks	OSS + COTS	Mature
prompt-injection detection	LlamaFirewall PromptGuard 2, NVIDIA NeMo Jailbreak Detection NIM, Palo Alto Prisma AIRS, Onyx Platform runtime protection	OSS + COTS	Mature
Chain-of-thought alignment auditing	LlamaFirewall AlignmentCheck	OSS	Developing — novel primitive
Code-output static analysis	LlamaFirewall CodeShield, GitHub Copilot for Security	OSS + COTS	Developing
Topic / content safety	NVIDIA NeMo Content Safety NIM, Lakera Guard, Lasso, Microsoft Prompt Shields	COTS	Mature
Sandbox / containment	Firecracker (per-task VM), gVisor container, WebAssembly sandbox; Agent Sandbox (Kubernetes-native CRDs: SandboxTemplate blueprint + SandboxClaim, gVisor default)	OSS	Mature
Compartmentalized LLMs (CaMeL pattern)	Privileged + Quarantined LLM split (Google DeepMind)	Research	Research-stage
Proof-of-Guardrail attestation	AWS Nitro Enclaves + Miggo Security	COTS	Research-stage

Note on bypass risk. The Trendyol Tech LlamaFirewall bypass (non-English and leetspeak prompt injections) confirms no single guardrail is sufficient. Defense-in-depth across all six planes is required.

4. Egress plane

The Egress plane mediates an agent’s reach to tools, MCP servers, peer agents, and the open internet. It proxies MCP / A2A / LLM traffic through a gateway, authorizes MCP calls at runtime, defends against tool poisoning and rug-pulls, enforces agent-to-agent cryptographic identity, filters egress destinations, and segments the network per agent.

Capability	Reference implementation	Type	Status
MCP / A2A / LLM proxy	AgentGateway (Linux Foundation, July 2025), Solo Enterprise for agentgateway	OSS + COTS	Mature (OSS)
MCP runtime authorization	Operant MCP Gateway, Natoma; Stripe Toolshed (annotation PEP); AgentCordon (OSS Cedar PDP + MCP gateway)	OSS + COTS	Developing
rug-pull defense	Solo Enterprise tool-server fingerprinting, versioning, runtime policy	COTS	Developing
Agent-to-agent cryptographic identity	A2A v1.0 §8.4 signed Agent Cards (Std baseline); Oktsec (Ed25519 sigs, 268 detection rules, content scanning)	Std + COTS	Developing
Network-layer prompt-injection containment	Microsoft Entra Internet Access prompt-injection protection (GA Mar 2026); Layer-0 control outside the agent process	COTS	GA
Egress destination filtering	Credential proxy destination allowlists, Smokescreen SSRF egress proxy (Stripe OSS), Docker DOCKER-USER chain	OSS	Mature
Network segmentation	Per-agent subnet, agent VPC isolation	Infra	Mature

The egress plane contains the MCP attack surface. Q1 2026 produced 30+ MCP CVEs (see MCP CVEs Q1 2026), revealing systematic path traversal and injection vulnerabilities across server implementations; AgentGateway’s automatic token exchange limits each tool’s permissions to exactly what it needs.

5. Data plane

The Data plane attributes trust and enforces integrity across training data, retrieval corpora, knowledge bases, per-session memory, and the AI Bill of Materials. It generates and reconciles the ML-BOM, attests RAG provenance, defends against memory poisoning, maintains cognitive file integrity for agent identity files, rolls back corrupted state, and scans the supply chain.

OpenClaw provenance. Five rows in this table (RAGShield, TrustRAG, SecureClaw / cognitive file integrity, Brain Git, Aguara Watch) come from the OpenClaw ecosystem, which indicates where agentic data-plane security is heading rather than providing battle-tested controls. They are retained because they identify real capability gaps and likely future directions, but they are classified Exploratory and are not foundational evidence on par with OWASP AIBOM, sigstore, or Miggo Security. Treat them as emerging indicators and validate independently before production deployment.

Capability	Reference implementation	Type	Status
Answer-time entitlement enforcement / oversharing remediation	Microsoft Purview DSPM for AI + oversharing assessments; label-aware DLP for M365 Copilot; Restricted SharePoint Search (site-capped stopgap); generalizes to the usage-control (UCON) model of continuous authorization	COTS	GA — the load-bearing control against inference exposure for closed-corpus member/customer bots (see D6 deep dive)
AI/ML-BOM generation	OWASP AIBOM Generator (CycloneDX ML-BOM, v1.7 current), SPDX 3.0 AI extensions, IBM Granite 4.0 disclosures	OSS + Std	Developing
Runtime AI-BOM	Miggo Security DeepTracing (behavioral baseline)	COTS	Developing — novel
RAG provenance / attestation	RAGShield (cryptographic doc attestation), TrustRAG	Exploratory	Exploratory — OpenClaw ecosystem; not production-validated
Memory poisoning defense	Microsoft Defender for Cloud Apps memory-injection detector (50+ examples found, March 2026); namespace isolation (structural — memory keyed by code, not LLM-assertable)	COTS + Concept	Developing
Cognitive file integrity	SHA-256 monitoring of SOUL.md, IDENTITY.md; SecureClaw	Exploratory	Exploratory — OpenClaw ecosystem; emerging indicator, not foundational control
State rollback	Brain Git (SlowMist)	Exploratory	Exploratory — OpenClaw ecosystem; no production adoption evidence
Skill / model registry signing	sigstore / cosign, OWASP AIBOM	OSS	Developing
Supply-chain scanning	JFrog ML scan, ReversingLabs; AgentShield (OSS — scans the agent-harness config tree: secrets, hooks, MCP, permissions)	OSS + COTS	Developing
Supply-chain scanning (emerging)	Aguara Watch (5 registries daily, SlowMist)	Exploratory	Exploratory — OpenClaw ecosystem; forward indicator for registry hygiene direction

The data plane sustained the most damage in Q1 2026: ClawHavoc (1,184+ malicious skills), SANDWORM_MODE (npm worm into MCP), LiteLLM compromise. Defense requires registry, pre-install, checksum, and cognitive-file integrity controls layered together.

6. Observability plane

The Observability plane provides full-stack visibility across the five upstream planes. It implements OpenTelemetry gen_ai.* semantic conventions, agent-aware tracing, AI-SPM, agent behavioral monitoring, identity multiplexing in logs, and SIEM/SOAR with agent playbooks. It integrates AI red-teaming as a continuous feed rather than a point-in-time exercise.

Capability	Reference implementation	Type	Status
OpenTelemetry gen_ai.* semantic conventions	OTel SemConv v1.37+ (CNCF standard; SIG contributors: Amazon, Elastic, Google, IBM, Langtrace, Microsoft, OpenLIT, Scorecard, Traceloop)	Std	Mature (experimental status, broad adoption)
Agent-aware tracing	LangSmith, Langtrace, Traceloop, Helicone	OSS + COTS	Mature
AI-SPM (Security Posture Management)	Wiz AI-SPM, Palo Alto Prisma AIRS, Orca AI-SPM, Reco, Onyx Platform, Google Agent Security dashboard (Security Command Center, preview)	COTS	Mature
Agent behavioral monitoring (anomaly detection on agent activity)	Vectra AI, Miggo behavioral drift, Google SecOps Agent Anomaly Detection (LLM-as-a-judge on agent reasoning, preview); pattern: three-level behavioral anomaly detection over a cost-ordered detection cascade	COTS	Developing
Agent behavioral monitoring (emerging)	SecureClaw nightly audits	Exploratory	Exploratory — OpenClaw ecosystem; forward indicator for agent audit direction
Trip-wire / canary detection	Canary tokens planted in system prompts and RAG wrappers; fires on injection / system-prompt exfil at the post-LLM hook	Concept	Developing
Security-event preservation	Context-aware trimming — pin tagged security events so a multi-attempt injection cannot hide across the context-window trim boundary	Concept	Developing
Identity multiplexing in logs	Agent Observability §3	Concept	Developing
SIEM / SOAR with agent playbooks	Splunk + agent IOCs, Sentinel + Defender for Cloud, Falcon AIDR + NeMo Guardrails	COTS	Developing
AI red-teaming integration	Promptfoo, Mindgard CART, PyRIT (Microsoft), Garak (NVIDIA), Palo Alto Prisma AIRS (continuous CART)	OSS + COTS	Mature

Observability scaling is a primary engineering constraint for agentic workloads. At production volume, pre-aggregation at the runtime hook is required: raw per-span emission overruns the SIEM.

Mapping to deployment shapes

The six-plane structure applies to every deployment shape; the active controls and their relative weight differ by shape. The table below specifies which planes are exercised and which controls are load-bearing for each shape.

Deployment shape	Identity	Control	Runtime	Egress	Data	Observability
Web/desktop chatbot (no tools)	OIDC for human; agent runs as bot identity	Topic-control, content-safety policies	NeMo Content Safety, Lakera Guard	None (no tools)	RAG corpus only	OTel gen_ai.*
Generative coding tool (Copilot, Cursor, Claude Code)	Workspace identity + per-repo scope; agent rules files (.cursorrules / IDENTITY.md) baselined	Pre-commit hooks, Cedar policy on file mutation; destructive-action classification routes force-push / mass refactor / prod-config writes to confirm or block	LlamaFirewall CodeShield + AlignmentCheck; per-task sandbox; rogue IDE extension detection (Kirin / equivalent)	Source-control + LSP only; typosquat-aware dependency install gate	Repo content + skill registry; cognitive file integrity for rules files AND IDENTITY.md	LangSmith / Langtrace; tool-call audit; MCP usage + rule changes + policy-violations dashboard (Kirin-class)
Data-science copilot (Jupyter, notebooks)	User identity passthrough	Sandbox-resource policy; HITL on dataset writes	Per-notebook sandbox (Firecracker)	Internal data warehouse via credential proxy	Dataset lineage + AI-BOM	OTel + behavioral drift
RAG application (Azure worked example)	Per-tenant agent identity	Source-trust attribution; lethal-trifecta breaker	Input filter on prompts; output classifier + groundedness check	Vector store + per-source allowlist	Closed corpus: answer-time entitlement enforcement + oversharing remediation (the live risk); open/multi-writer corpus: document attestation + PoisonedRAG defense	Retrieval-pattern behavioral monitoring
MCP server (consumed by agents)	mTLS + workload identity (SPIFFE)	OAuth 2.1 token exchange (CoSAI / NIST CAISI)	Tool-fingerprinting, rug-pull detection (Solo Enterprise)	n/a (server-side)	Skill/server signing, version pinning	MCP CVE feed integration
Agent skill (e.g., Claude skill, Anthropic plugin)	Skill author identity (signed)	Skill-scoped Cedar policy	Skill manifest validation; runtime sandbox	Per-skill egress allowlist	Skill registry signing (sigstore); cognitive file integrity	Skill execution telemetry
Multi-agent mesh (A2A v1.0)	Per-agent Ed25519 identity (Oktsec-side; not in spec); SPIFFE/SPIRE workload identity	Cross-agent ACL (Oktsec default-deny); A2A opacity principle; per-skill authorization advertised in Agent Card; stop-mesh-vs-isolate containment doctrine (Multi-Agent Runtime Security)	Per-agent runtime sandbox; AgentGateway broker between	A2A v1.0 over HTTPS / TLS 1.3 + signed Agent Cards (§8.4) + content scanning (Oktsec 268 rules); replay protection layered by impl (timestamps + nonces)	Shared memory / blackboard with provenance; cross-agent OTel gen_ai.* trace propagation	Pairwise/triadic traffic baselines; graph-walk anomaly detection (SentinelAgent / TraceAegis-class, prototype); cross-agent drift correlation; cascade detection per ASI08 doctrine

Recommended stacks by org profile

Opinionated tool selections per plane for two common org profiles. Neither stack is exhaustive — treat each as a starting point extensible per deployment shape and risk profile.

Enterprise stack (COTS-heavy)

Suited for large organizations with existing vendor relationships, centralized IAM, and SOC/SIEM infrastructure. Prioritizes vendor SLAs, support contracts, and integrations with Microsoft 365 / AWS / GCP environments.

Plane	Primary choices	Notes
Identity	Microsoft Entra Agent ID + Microsoft Agent 365 Registry (GA), AWS Bedrock AgentCore, or GCP Agent Identity (all GA); Okta for AI Agents (Early Access, GA expected FY27); CyberArk Conjur or Aembit for NHI governance	Per-agent identity is GA platform-native on all three hyperscalers; build this plane first (it gates Egress and Observability); per-task capability tokens remain off-stack / leading-edge
Control	AWS Cedar managed policy service (March 2026 AI governance release); Anthropic Compliance API or Microsoft Agent Governance Toolkit (Apr 2026); Permit.io for RBAC UI	Cedar is the enterprise-grade choice; COTS wrappers add audit + workflow tooling
Runtime	LlamaFirewall (Meta OSS — no license cost) + NVIDIA NeMo NIMs (commercial inference); Microsoft Prompt Shields for content safety; per-task Firecracker VM or Hyper-V sandbox	Mix OSS guardrail (LlamaFirewall) with COTS NIM delivery for SLA coverage
Egress	Azure API Management AI Gateway (Microsoft stack: LLM token governance + inline Content Safety + MCP brokering with Entra/OAuth authorization, GA) or Entra Internet Access for network-layer PI / Shadow-AI filtering; Solo Enterprise for AgentGateway, Kong AI Gateway, or Cloudflare AI Gateway; Operant MCP Gateway for MCP-specific authorization; mTLS via Istio / Linkerd	All-Microsoft shops have a native LLM gateway (APIM); MCP tool-integrity / rug-pull defense and per-task capability tokens still require an off-stack tool (Solo / Operant / Tenuo)
Data	Microsoft Purview AI (M365 environments); Wiz AI-SPM or Palo Alto Prisma AIRS; JFrog ML Catalog for AI-BOM; ReversingLabs for supply-chain scanning	Stack assumes M365 + cloud environment; swap Purview for CASB equivalent if GCP/AWS-native
Observability	DataDog AI Monitoring or New Relic AI Monitoring (OTel-native); LangSmith for agent-specific tracing; Mindgard CART for continuous red-teaming; Vectra AI or Palo Alto Cortex XSIAM for behavioral monitoring	OTel gen_ai.* spans feed into existing SIEM; Mindgard replaces point-in-time red-team for CARTS programs

FOSS / small-team stack

Suited for research teams, security teams running internal agent experiments, startups, or orgs with open-source mandates. Prioritizes zero licensing cost, community support, and composability. Requires more operational ownership.

Plane	Primary choices	Notes
Identity	SPIRE for workload identity; standard OAuth 2.1 + OIDC (any provider) for delegation; Aegis or AgentKeys for credential proxy	SPIFFE is the vendor-neutral workload-identity standard; pairs with any OIDC-compatible IdP
Control	Rego or Cedar (open-source distribution); Tenuo Warrants (Rust OSS) for task-scoped capability tokens; OWASP least-agency four-tier guidance for tier design	Both Cedar and OPA are fully OSS; Tenuo adds cryptographic delegation without a license
Runtime	LlamaFirewall PromptGuard 2 + AlignmentCheck + CodeShield (Meta OSS); NVIDIA NeMo Guardrails (OSS portion); Firecracker or gVisor for per-task sandboxing	Full LlamaFirewall stack is zero-cost; Firecracker is AWS OSS (Apache 2.0); gVisor is Google OSS
Egress	AgentGateway (Linux Foundation, Apache 2.0); mTLS via Istio (CNCF OSS) or Linkerd (CNCF OSS); Docker DOCKER-USER iptables chain for egress filtering	AgentGateway is the canonical OSS agent proxy; Istio adds mTLS with near-zero operational overhead vs DIY
Data	OWASP AIBOM Generator (CycloneDX ML-BOM, OSS); sigstore / cosign for artifact signing; lockfile enforcement + SCA for slopsquatting; RAGShield or TrustRAG for RAG attestation; Brain Git (SlowMist) for state rollback	All zero-cost; for a closed-corpus bot the load-bearing control is answer-time entitlement enforcement (no strong FOSS option — this is a COTS/platform gap); RAGShield/TrustRAG are research-grade
Observability	OpenTelemetry gen_ai.* SemConv (CNCF standard, v1.37+); Langtrace or Traceloop (OSS) for agent-aware tracing; PyRIT (Microsoft OSS) + Garak (NVIDIA OSS) + Promptfoo (OSS) for red-team coverage	OTel is the zero-cost observability foundation; the three red-team tools cover orchestration / probe / regression — all open-source

The enterprise stack exceeds the FOSS stack primarily in operational overhead reduction (vendor support, pre-built integrations), not raw security capability: at L4 CMM a well-operated FOSS stack reaches comparable controls. The FOSS stack is production-viable at D3–D4 of the CMM for most deployment shapes. The Research-type items (CaMeL, RAGShield at scale) are not yet production-ready for either stack.

Threat-control matrix (OWASP Agentic AI Top 10 → planes)

Maps OWASP Agentic AI Top 10 (ASI01–ASI10) risk categories to the planes that primarily mitigate them. Most categories have controls in multiple planes; the following table identifies the primary control surface and lists reference controls for each.

flowchart LR
    subgraph Threats[Threats]
        ASI01[ASI01: Goal Hijack]
        ASI02[ASI02: Tool Misuse]
        ASI03[ASI03: Identity & Privilege]
        ASI04[ASI04: Supply Chain]
        ASI05[ASI05: Unexpected Code Execution]
        ASI06[ASI06: Memory Poisoning]
        ASI07[ASI07: Inter-Agent Comms]
        ASI08[ASI08: Cascading Failures]
        ASI09[ASI09: Human-Agent Trust]
        ASI10[ASI10: Rogue Agents]
    end
    subgraph Planes[Planes]
        ID[Identity]
        CTL[Control]
        RT[Runtime]
        EG[Egress]
        DT[Data]
        OBS[Observability]
    end
    ASI01 --> RT & CTL
    ASI02 --> CTL & EG
    ASI03 --> ID
    ASI04 --> DT
    ASI05 --> RT & CTL
    ASI06 --> DT
    ASI07 --> EG
    ASI08 --> CTL & OBS
    ASI09 --> OBS & CTL
    ASI10 --> ID & OBS

OWASP ASI	Primary plane	Reference controls
ASI01 Goal Hijack	Runtime + Control	LlamaFirewall AlignmentCheck; HITL on goal-changing actions
ASI02 Tool Misuse	Control + Egress	Cedar/OPA tool-call policy; AgentGateway runtime authz
ASI03 Identity & Privilege	Identity	Okta for AI Agents; Microsoft Entra Agent ID; credential proxy
ASI04 Supply Chain	Data	OWASP AIBOM Generator; sigstore; Aguara Watch
ASI05 Unexpected Code Execution (RCE)	Runtime + Control	Sandboxed execution (e.g. mcp-run-python); ban eval / safe interpreters; code-generation/execution separation with validation gates; LlamaFirewall CodeShield
ASI06 Memory Poisoning	Data	RAGShield; cognitive file integrity; M365 memory-injection detector
ASI07 Insecure Inter-Agent	Egress	A2A v1.0 over HTTPS + signed Agent Cards (§8.4); Oktsec Ed25519 message signing + content scanning (268 rules)
ASI08 Cascading Failures	Control + Observability	Step-up gates (CSA ATF); pairwise/triadic baselines; graph-walk anomaly detection; stop-mesh-vs-isolate doctrine (Multi-Agent Runtime Security)
ASI09 Human-Agent Trust Exploitation	Observability + Control	Plan-divergence detection; provenance UI with risk-differentiated prompts; HITL confirmation on sensitive actions; oversight-personnel training
ASI10 Rogue Agents	Identity + Observability	Behavioral drift detection; Okta Agent Discovery; distributed kill switch

The ASI categories above are the awareness-level labels; the underlying reference threat model the RA defends against is the T1–T17 catalog in OWASP Agentic AI Threats and Mitigations, which places each threat on a single-agent and multi-agent reference architecture and resolves them into six defensive playbooks that map cleanly onto these planes. For the certification view of where these controls are required, the OWASP ASI to AIUC-1 crosswalk maps each ASI category to specific AIUC-1 requirements and records eight areas — inter-agent authentication, agent identity attestation, cascading-failure containment, tool-call observability, runtime monitoring, resource-abuse controls, supply-chain attestation, and I/O schema controls — where AIUC-1 has no requirement the plane controls here address.

Threat classes beyond the ASI list

The ASI categories are per-component risks. The five threat classes are cross-cutting adversary models that no single plane absorbs. The table below places each class against the planes that carry its controls; the full plane-and-domain mapping for every taxonomy is consolidated in the Threat Taxonomy Reconciliation matrix.

Class	Planes that carry the control	Note
1 — AI-aware insider	Identity, Control, Data, Observability	Absorbed by the AI-BOM plus continuously-executed customer eval harness on the Data plane
2 — Long-running APT campaign	Runtime, Egress, Observability	Cross-version eval continuity and sustained threat hunting; an operations function, not a single control
3 — Collusion	Control, Runtime, Observability	Requires monitor isolation and output canonicalization; multi-agent cascade detection is research-stage (see Gaps)
4 — Model-version degradation	Runtime, Data	Customer eval suite versioned independently of the vendor; pin-by-hash
5 — Jurisdictional adversary	Governance only	No technical plane control mitigates a legal cutoff; resolves to governance and vendor-abstraction, an honest plane gap

Two coverage limits are deliberate, not oversights. Multi-agent cascade containment (ASI08) and agent collusion (Class 3) rest on research-stage detectors: the wiki tracks the stop-mesh-versus-isolate doctrine in Multi-Agent Runtime Security, but no integrated product ships with documented thresholds. Model-layer attacks (extraction, membership inference, trojaned weights) are named under the Data plane and Class 4 but carry thinner controls than the prompt- and tool-layer risks, because the customer-side defense is the eval-harness delta, not a runtime guardrail. Both limits are recorded in Gaps below and on the threat-classes page.

Trade-offs

Architectural trade-offs that vary with deployment scale, latency tolerance, and risk profile. Each row names the decision axis and the recommended default; deviations should be documented with a strategic-rationale field per the CMM reporting convention.

• Single broker vs mesh. AgentGateway-as-broker is simpler and provides a single policy chokepoint. Mesh (per-service AgentGateway sidecar) scales better but multiplies the policy surface. Default to broker for up to roughly 50 agents; move to mesh above that.
• PDP location. Inline (in-process with the agent) has the lowest latency but couples policy to runtime. Sidecar gives clean separation. External service is the standard zero-trust answer but adds a network round-trip, typically single-digit to low-tens of milliseconds per call. Default to sidecar.
• Sandbox grain. Per-call sandbox is safest but expensive; per-task sandbox is the practical default; per-agent sandbox is too coarse for high-risk-tier actions.
• Fail-closed vs fail-open. Default to fail-closed for high-risk-tier actions, fail-open for read-only / informational tier. CSA ATF Promotion Gates encode this directly.

Gaps in the architecture

Known unfilled spots

1. Compartmentalized LLM (CaMeL) reference pattern. Privileged-LLM-coordinates-quarantined-LLM is theoretically sound but lacks a vendor-neutral reference implementation. (Google DeepMind research-stage.)
2. Cross-tenant MCP server signing. MCP CVE rate (30+ in Q1 2026) suggests the ecosystem is pre-supply-chain-hardening. sigstore-for-MCP-servers is needed but not standardized.
3. Multi-agent failure containment. ASI08 (Cascading Failures) and ASI10 (Rogue Agents) have no traditional cybersecurity equivalent. Multi-Agent Runtime Security covers the cascade-detection / behavioral-baseline / inter-agent IR depth, but 2026 remains the academic-prototype era: graph-walk monitors (SentinelAgent, TraceAegis) ship as papers, and vendor primitives exist (Oktsec rate limits + ACLs) without an integrated cascade-detection product shipping documented thresholds.
4. AI-BOM operationalization gap. CycloneDX 1.6 ML-BOM is the format; the operational workflow (CI/CD integration, vendor disclosure norm, AI-VEX equivalent) is thin.
5. Identity binding when humans are decommissioned. When the human owner of an agent leaves, the agent must be rotated or revoked. Okta and Microsoft Agent 365 cover this for managed agents; orphaned shadow agents are still discoverable but not always governable.

Prior work and comparison

None of the six comparison frameworks below combines a vendor-neutral stance with a control-architecture specification for agentic deployments. Prior work falls into two categories: cloud-specific operational guidance (hyperscaler “how to secure AI on our platform” documents) and vendor-neutral threat taxonomies (threat enumeration without control specification). The table summarizes each and the gap it leaves.

Framework	Published	Vendor neutral?	Agentic-specific?	What it covers	Key gap
Microsoft ZT4AI	March 2026	No (Azure / Microsoft stack)	Strong yes — agent identity, MCP governance, multi-agent verification	Seven-pillar Zero Trust applied to AI (the “700 controls / 116 groups” figure is the whole Zero Trust Workshop, not an AI-pillar count — see ZT4AI review); Entra Agent ID, Agent 365 registry, Purview DSPM, Content Safety, APIM AI Gateway, Sentinel/Defender agentic SOC	Azure-tooling-locked; no per-task capability tokens; MCP tool-integrity is guidance-only (no single Azure service); much of the adaptive agent-runtime layer is preview as of May 2026
Azure OpenAI Reference Architecture	Ongoing (Feb 2026 update)	No (Azure)	Partial — adds Entra Agent ID, scoped tokens, HITL via Logic Apps	5-layer: Network isolation · Identity/access · Content/prompt · Data protection · Monitoring	Assumes static LLM API invocations; no multi-agent orchestration architecture; no MCP, A2A, or memory/state security
Microsoft MCRA	April 2025	No (Microsoft ecosystem)	Minimal	Enterprise security architecture diagrams across ZT pillars; AI section = Microsoft Security Copilot as a security tool	Not a defense-of-AI architecture; treats AI as defender-assistant, not as a class of workloads to secure
AWS Well-Architected Generative AI Lens	November 2025	No (AWS)	Partial — names “excessive agency” as a risk; adds an agentic AI preamble	6 WAF pillars applied to GenAI lifecycle; security pillar covers: endpoint protection, output risk, prompt security, monitoring, model integrity	”Excessive agency” named but mitigations unspecified; no agent identity, tool sandboxing, agent-to-agent trust, or MCP coverage
Google Cloud AI Security Foundations	2025 (ongoing)	No (GCP)	Partial — 6-layer model includes “Agents and Applications” layer	6 architectural layers: foundation → infrastructure → models → data → tools → agents; Model Armor for runtime guardrails; VPC/IAM/CMEK controls	”Agents and Applications” layer exists as a named category but is underspecified; no agent identity governance, tool execution sandboxing, inter-agent trust, or memory security
CSA MAESTRO	February 2025	Yes	Full — built exclusively for agentic AI systems	7-layer threat taxonomy: Foundation Models → Data Operations → Agent Frameworks → Deployment/Infra → Evaluation/Observability → Security/Compliance → Agent Ecosystem3	Taxonomy only — identifies threats but specifies no controls, no implementation guidance, and no compliance mapping

What this RA adds

The six-plane model occupies the gap between cloud-specific operational guides and vendor-neutral threat taxonomies. Four contributions distinguish it:

Vendor-neutral control architecture. Unlike ZT4AI, the Azure RA, the AWS GenAI Lens, and the Google Cloud guidance, this RA specifies how to implement controls without mandating a particular hyperscaler. Reference implementations are labeled OSS / COTS / Std / Exploratory so organizations can substitute equivalent tools per plane.

Agentic-throughout. Unlike MCRA (AI = security tool) and the AWS / Google guidance (agentic = a paragraph), all six planes assume autonomous multi-step agent loops: credential proxy in the identity plane, per-task sandboxing in the runtime plane, A2A v1.0 in the egress plane, Warrant-based delegation in the control plane, memory-poisoning defense in the data plane, and behavioral-drift detection in the observability plane.

MCP-specific surface. The MCP attack surface — with 30+ disclosed CVEs in Q1 2026 (see MCP CVEs Q1 2026) — is absent or underspecified across the comparison frameworks above. The egress plane addresses MCP runtime authorization, tool fingerprinting, and rug-pull defense, controls absent from all six comparison frameworks above.

Tool supply chain. The data plane covers AI-BOM generation, skill / model registry signing, and supply-chain scanning. This surface is absent in the cloud-specific guides and only named (not addressed) in MAESTRO’s Agent Frameworks layer.

Inherited inputs. The RA synthesizes rather than originates; it inherits from:

• ZT4AI’s principle of per-agent scoped identity with cryptographic binding
• CSA MAESTRO’s 7-layer threat taxonomy as the threat-model input
• CSA ATF’s promotion gates as the basis for the least-agency tier model
• OWASP ASI Top 10 as the explicit control-to-threat mapping
• NIST CAISI Concept Paper’s OAuth 2.1 extensions for agent delegation

The primary contribution is the synthesis: a single vendor-neutral document connecting a threat taxonomy (MAESTRO + OWASP ASI Top 10) to a plane-by-plane control library (this RA) to a maturity model (Agentic AI Security CMM 2026), a chain that none of the six comparison frameworks provides end-to-end.

• Implemented by: Agentic AI Security Capability Maturity Model — the CMM measures organizational maturity in operating this architecture.
• Defender-operations counterpart: Agentic SOC Reference Architecture (with the Agentic SOC CMM) — the architecture of an agentic Security Operations Center. This RA secures agentic-AI applications; the SOC RA structures the SOC that monitors and responds. They share only the securing-the-agents layer (this RA’s Identity / Control / Observability planes ↔ the SOC RA’s Identity & Action-Authority / Policy & Enforcement / Observability & Evaluation planes), and the SOC RA treats in-house AI applications as a monitored surface that this RA secures by design.
• Built on: Security Controls for AI Stacks (six-layer inventory), AI Agent Identity Architecture.
• Validated against: OWASP Top 10 for Agentic Applications (ASI Top 10), MITRE ATLAS, CSA Agentic Trust Framework (layer/element/gate names verified in the 2026-Q2 review), CoSAI — Coalition for Secure AI.
• Compared with (§Prior Work): Microsoft ZT4AI (March 2026), Azure OpenAI Reference Architecture, Microsoft MCRA, AWS Well-Architected Generative AI Lens (Nov 2025), Google Cloud AI Security Foundations, CSA MAESTRO 7-layer model.
• Threat-anchored to: ClawHavoc — Agentic Skill Marketplace Supply Chain Attack, SANDWORM_MODE npm worm — AI Toolchain Poisoning, Meta Sev 1 AI Agent Breach, MCP CVEs Q1 2026, GTG-1002 — First Reported AI-Orchestrated Cyber Espionage Campaign.
• Stress-tested against: Agentic AI Threat Classes — 2026 Expansion — the five threat classes beyond the OWASP ASI / MITRE ATLAS / Lethal Trifecta baseline (insider, APT campaign, collusion, model-version regression, jurisdictional adversary).

Footnotes

1. LlamaFirewall PromptGuard 2 / AlignmentCheck attack-success-rate reductions come from Meta’s evaluation on the AgentDojo benchmark (arXiv:2406.13352); the Constitutional Classifiers jailbreak-success figure is Anthropic’s reported result (2025). Both reductions are restated and contextualized in Wiki Novelty and Counter-Arguments §Thesis 1. ↩

2. CSA — The Agentic Trust Framework: Zero Trust Governance for AI Agents, retrieved 2026-06-22. Four maturity levels (Intern → Junior → Senior → Principal) advanced through five promotion gates; see the 2026-Q2 review. ↩

3. CSA — Agentic AI Threat Modeling Framework: MAESTRO, retrieved 2026-06-22. Seven layers L1–L7, verified in the 2026-Q2 standards review. ↩