Agentic AI Security Capability Maturity Model

An evidence-based Capability Maturity Model for agentic AI security. It applies the design lessons from CMMI, BSIMM, OWASP SAMM, CMMC 2.0, and NIST CSF 2.0 (see Cybersecurity Capability Maturity Models — Exemplars and Design Lessons for the per-exemplar treatment) to the threat surface and control stack in the Agentic AI Security Reference Architecture.

The model is descriptive at Levels 1–3 (controls observed in production at well-run organizations), prescriptive at Level 4 (controls a mature program operates), and achievable-today at Level 5 (capabilities available in shipping products and current specifications: Microsoft Agent 365, AgentGateway-LF, LlamaFirewall, AIUC-1 certification, Miggo DeepTracing). Integration across all nine domains remains rare. Research-stage and unshipped capabilities (TEE-backed guardrail attestation, multi-agent cascade-detection rule libraries, CaMeL privileged/quarantined LLM split, cross-vendor AI-BOM federation, named standards contribution) sit in a separate L5+ Leading Edge tier that is aspirational and not required for L5. The CMM Calibration Stress Test (2026-05-02) introduced the L5 / L5+ split to keep L5 achievable today with shipping products.

On this page

Foundational distinction: governance is not security

The CMM measures both security (preventing harm) and governance (defining authority and accountability); the two are not interchangeable.

Security controls (firewalls, EDR, prompt filters, sandboxes, credential proxies) prevent or contain harm.

Governance defines who has the authority to act, under what justification, with what oversight, and with what record. An organization can be at L4 in security controls (D2 / D4 / D5 / D8) and still be at L1 in governance (D1 / D3 / D9), or the reverse.

Both must climb together. The AI Coding Agent Governance (Knostic, 2025–2026) page sharpens this distinction, and the Decision Rights for AI Agents concept operationalizes it. It is what makes Shadow Automation a structurally different risk from shadow IT.

What this CMM is and is not

Is:

Is not:

  • A certification program. Certification belongs to IEC 42001 and AIUC-1; this is a measurement scaffold.
  • A replacement for risk assessment. The CMM measures capability; risk assessment measures exposure.
  • A vendor-neutral promise. Vendors and OSS projects are named where load-bearing at a given level. The intent is concreteness, not endorsement.

Five levels + a leading-edge tier (cumulative)

LevelNameNotes
L5+Leading Edgeresearch-stage / standards contribution (aspirational, not required)
L5Optimizingplatform-level enforcement (achievable today)
L4Managedquantitative, continuous
L3Definedorg-wide standardization
L2Developingpolicy + inventory
L1Initialad hoc

Cumulative semantics (CMMC lesson, modified): Level N requires every Level N–1 control plus the new criteria at Level N. **An organization’s overall rating is reported as a per-domain matrix; aggregation uses dependency-resolved effective scores rather than a single floor

A domain’s effective score = min(its raw score, the raw scores of its upstream-dependency domains under the active rule set). The active rule set is small and conservative; see Effective-Score Dependency Rules (v1 = 3 rules: D2→D5, D2→D7, D3→D4, all anchored to lethal-trifecta and Sondera/AgentCordon practitioner evidence). The headline is a three-number summary: typical (median effective), weakest (min effective, with cap source labeled), and strongest (max raw, labeled).

This replaces the prior single-floor rule drawn from CMMC 2.0. The floor misreported 3 of 5 realistic archetypes per the stress test (Stripe-style architectural containment, enterprises deploying a platform-native agent registry such as Agent 365, resource-constrained startups). Effective-score scoring captures cross-domain attack-path failures where they are real (weak D2 caps D5 because per-agent egress cannot be enforced without per-agent identity) without punishing unrelated weakness (weak D9 ops lag does not drag D2 identity controls down). Mandatory matrix disclosure and a strategic-rationale field prevent cherry-picking; mathematical aggregation does not. The dependency-rule registry is scaffolding: it grows with new attack-path evidence and practitioner architectures via the documented promotion protocol.

Threat coverage and proportionality

The domains are calibrated to the threats the wiki documents, mapped in the Threat Taxonomy Reconciliation matrix. The OWASP ASI categories land on a primary domain each (ASI03/ASI10 → D2, ASI02/ASI08 → D3, ASI01/ASI05 → D4, ASI07 → D5, ASI06 → D6, ASI09 → D7, ASI04 → D8), and the five threat classes land cross-cutting: Class 1 (insider) across D2/D3/D6/D8, Class 2 (APT) across D4/D5/D7, Class 3 (collusion) across D3/D4/D7, Class 4 (model-version) across D4/D6/D8, Class 5 (jurisdictional) on D1, and every class touching D9 operations. Each domain deep dive names its threat coverage explicitly.

The dependency caps are the proportionality mechanism, not a scoring penalty. They exist because the upstream control is what makes the downstream threat addressable. Per-agent egress mediation (D5) and behavioral baselining (D7) cannot contain a per-agent threat, such as an APT operating one agent or a colluding pair, without per-agent identity (D2). A runtime guardrail (D4) cannot enforce a decision a weak policy decision point (D3) never makes, so a strong guardrail over ASI01/ASI02 is inert without it. Investing in the capped domain ahead of its dependency is the disproportion the model is built to surface.

Two coverage limits are deliberate. Multi-agent cascade containment (ASI08) and collusion (Class 3) detection are research-stage, so the relevant evidence bars sit at D3/D7 L4+ rather than claiming a shipping control. Model-layer attacks and Class 5 jurisdictional risk resolve to the eval-harness delta (D6/D8) and governance (D1/D9) respectively, because no runtime control mitigates a trojaned weight or a legal cutoff. Both limits are scoped in the threat-classes page and the RA Gaps section, not silently dropped.

L5 vs L5+ semantics

L5 is a maturity tier: every L5 criterion in this CMM points to a shipping product, an open-source project at v1.0+, or a documented capability deployable with currently available components. L5+ is a leading-edge tier: it requires L5 across all 9 domains plus research-stage capabilities and active named contribution to one or more standards bodies. A sufficiently resourced 2026 program can clear L5. L5+ is the bar a frontier-lab or research-shop program clears. The measurement protocol’s per-domain matrix view reports both.

Global evidence rule

Applies at L3 and above: all findings, gaps, eval results, and incident artifacts MUST be tagged with the standards-anchor IDs they relate to:

  • OWASP Agentic AI Top 10 — ASI01ASI10 (the agentic risk taxonomy)
  • OWASP LLM Top 10 (2025) — LLM01:2025LLM10:2025 (still apply to non-agentic and agent-as-LLM surfaces); the full code range is verified against the 2025 source by the LLM Top 10 standards review
  • OWASP AIVSS v0.8 — full vector with the ten Agentic Risk Amplification Factors (Execution Autonomy, External Tool Control Surface, Natural Language Interface, Contextual Awareness, Behavioral Non-Determinism, Opacity & Reflexivity, Persistent State Retention, Dynamic Identity, Multi-Agent Interactions, Self-Modification)
  • MITRE ATLAS v5.6.0 — AML.T#### techniques and AML.M#### mitigations
  • NIST SP 800-53 control IDs (via NIST IR 8605A COSAiS overlay) where compliance evidence is needed
  • For incidents: CVE IDs and MCP CVEs Q1 2026-class references
  • The five threat classes (insider, APT, collusion, model-version, jurisdictional) where a finding addresses a cross-cutting adversary model the ASI list does not name

Without ID tagging, a finding is L2-grade evidence at best. ID-tagging is the boundary between a CMM that maps to standards and one that operates on them, and it enables downstream automation: machine-checkable findings, cross-domain query, and longitudinal trend analysis.

Level 1: Initial

Reactive and ad hoc: AI agents run in production with no inventory, no identity, and no platform-level controls.

Auditor evidence: none / point-in-time interview.

Level 2: Developing

A written AI security policy exists; the agent inventory is manual; some prompt-level guardrails are in place; identity is delegated through the human user only.

Auditor evidence: policy doc + spreadsheet inventory + sample agent design review.

Level 3: Defined

Practice is standardized org-wide: every agent has its own identity; platform-level hooks intercept tool calls; an AI-BOM exists for production agents; an AI-specific incident-response playbook is documented.

Auditor evidence: identity graph for all agents + Cedar/OPA policy repo + AI-BOM artifact + IR runbook.

Level 4: Managed

Quantitative metrics are tracked continuously; agent behavioral monitoring detects drift; a red-team eval program runs at least quarterly; a credential proxy is in use; high-risk tasks run in a sandbox.

Auditor evidence: dashboard with KPIs + red-team report + cred-proxy traffic logs + sandbox config.

Level 5: Optimizing

Every control is reachable with shipping products as of May 2026: platform-level enforcement everywhere across all 9 domains; AIUC-1 certified against the most recent quarterly refresh, or ISO/IEC 42001 certified; real-time AI-BOM (Miggo DeepTracing or equivalent shipping product); capability tokens / Warrants per task; a mesh AgentGateway sidecar per agent; at least two quarters of stable L4 operation; bus-factor ≥2 with a documented continuity test.

Auditor evidence: per-domain matrix at L5 across all 9 domains + most-recent cert dated within the last quarter + ≥2-quarter L4 history + continuity-test report.

Level 5+: Leading Edge

All of L5, plus research-stage primitives in production: cryptographic guardrail attestation in a TEE (Nitro Enclaves-class); a CaMeL-style privileged/quarantined LLM split for trifecta-positive workloads; a cascade-detection rule library with tuned thresholds for ASI07/08/10 multi-agent risk; cross-vendor AI-BOM federation with reconciliation; sigstore-for-MCP cross-tenant signing; and an active named contributor to one or more of CoSAI / OWASP / AIVSS / NIST CAISI / OASIS / Linux Foundation AAIF AI working groups (PR / RFC / spec authorship, not just membership).

Auditor evidence: TEE attestation logs + cascade-rule registry with thresholds + cross-vendor AI-BOM reconciliation report + named contributor list with PR/RFC/spec links.

**L4 → L5 is a campaign, not a step

Before claiming L5, the program MUST show: (a) ≥2 quarters of stable L4 operation across all 9 domains (no regression in the per-domain matrix); (b) AIUC-1 readiness assessment scheduled with an accredited auditor (Schellman or equivalent); (c) bus-factor ≥2 with a documented continuity test (anti-pattern I3 recovery); (d) gap-closure plan from the floor-domain to L5. This gate applies in addition to per-domain L5 criteria — meeting every per-domain L5 row without the gate evidence is L4-stable, not L5. Adopted from stress-test §Change 5.

Nine domains

The CMM uses 9 domains, derived from the 6 reference-architecture planes plus 3 cross-cutting concerns (governance, supply chain, and operations/human factors). The 9-domain breakdown sharpens focus on agentic-specific controls and adds a domain for the operational and human-factors gaps that no surveyed standard covers as a coherent set (per the 11-standard validation §3).

Cross-cutting domains (D1, D8, D9) wrap the per-plane domains as bands top and bottom. Per-plane domains (D2–D7) sit in a single row matching the RA’s plane order, with the same XACML / NIST SP 800-162 §2.2 four-role color palette (PIP blue, PDP yellow, PEP red, mixed purple, cross-cutting green).

block-beta
  columns 6

  D1["D1 Governance & Accountability"]:6

  D2["D2 Identity & Authorization"]
  D3["D3 Control & Least-Agency"]
  D4["D4 Runtime & Guardrails"]
  D5["D5 Egress & Network"]
  D6["D6 Data, Memory & RAG"]
  D7["D7 Observability & Detection"]

  D8["D8 Supply Chain & AI-BOM"]:6
  D9["D9 Operations & Human Factors"]:6

  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 cross fill:#d1e7dd,stroke:#198754,color:#000

  class D1 cross
  class D2 pip
  class D3 pdp
  class D4 pep
  class D5 pep
  class D6 mixed
  class D7 pip
  class D8 cross
  class D9 cross

D1. Governance & Accountability

The Governance & Accountability domain fixes who is accountable for agent behavior, with what authority, and on what auditable record. It spans AI security policy, executive ownership, the agent and NHI inventory, decision-rights matrices, and certification readiness. It treats accountability as a first-class security principle alongside Confidentiality, Integrity, and Availability: the CIAA augmentation of the classical CIA triad, introduced by Arora & Hastings (MAAIS, 2025) for agentic systems.

Maps to: NIST AI RMF Govern, ISO/IEC 42001 §5–§9, EU AI Act Art. 9 risk management, CoSAI Shared Accountability principle, MAAIS Layer 5 (Accountability and Trustworthiness), Operational XAI for Action Gating (justification-capture as the runtime accountability artifact); Microsoft ZT4AI Governance — Responsible AI Standard, Purview Compliance Manager AI templates, Agent 365 registry (control-level anchors in the ZT4AI review).

See the D1 deep dive for capability-decoupled criteria, the cost model, and right-sizing by deployment shape. The material change: **L5 no longer mandates a single certification

L5 now requires scheme-neutral third-party assurance, ISO/IEC 42001 preferred and AIUC-1 or a reviewed internal-equivalent accepted, per the AIUC-1 critical evaluation.

Level 1: Initial

No AI governance role exists; agents deploy without security review.

Evidence: none.

Level 2: Developing

A named AI security owner (CISO designate) holds the role, an AI use policy is published, and an agent risk-tier classification scheme exists on paper.

Evidence: policy doc; signed RACI.

Level 3: Defined

An AI Risk Committee (CISO + Legal + Privacy + Eng) meets at least monthly; agent risk tiers gate deployment; each agent carries a least-agency tier; a Decision Rights for AI Agents matrix is documented per agent type (action class × decision right × approver × justification × time bound); a shadow-agent inventory and reaper SLA are defined (see Shadow Automation).

Evidence: meeting minutes; deployment-gate evidence; decision-rights matrix; shadow-agent reaper runbook.

Level 4: Managed

The program tracks quantitative risk metrics (incidents, drift events, HITL escalations), reports AI risk at board level, completes a readiness assessment against a recognized third-party assurance scheme (IEC 42001, AIUC-1, or a documented internal equivalent), and maintains a standards-crosswalk matrix (CMM domain × Annex IV × AIUC-1 safeguard × ISO 42001 Annex A × NIST SP 800-53 via IR 8605A — see Agentic AI Security CMM — Standards Crosswalk Matrix); board metrics carry ASI## / AIVSS rollups.

Evidence:

  • dashboard;
  • board pack;
  • gap report;
  • crosswalk matrix.

Level 5: Optimizing

The capability is current, independent, third-party assurance of the governance program, satisfied by any one of:

  • a current IEC 42001 certification under active surveillance (preferred — standards-body-governed, multi-auditor, regulator-recognized);
  • a current AIUC-1 certification at the latest quarterly refresh (accepted, with the concentration and freshness caveats the evaluation documents);
  • or a documented internal-equivalent attestation independently reviewed by a qualified third party and crosswalk-mapped.

The org also publishes quantitative risk metrics internally with board attestation, operates the AI Risk Committee with a decision history of at least one year, and refreshes the standards-crosswalk matrix each quarter. Where the chosen scheme re-tests on a cadence (AIUC-1 quarterly), L5 means “current at the last refresh,” not “ever certified.”

Evidence: current certification or reviewed attestation; board-attested risk metrics; committee minutes ≥1 year; refreshed crosswalk.

Level 5+: Leading Edge

All of L5, plus:

  • an active named contributor to one or more of CoSAI / OWASP ASI / AIVSS / NIST CAISI / OASIS / Linux Foundation AAIF (PR, RFC, or working-group authorship — not membership alone);
  • published peer-reviewed or vendor-disclosed research with empirical agentic-AI security findings;
  • org-level AI risk-observability metrics published externally (e.g. a CSAI Foundation AI Risk Observatory contribution).

Evidence:

  • named-contributor evidence (commit / PR / spec authorship);
  • published research artifact;
  • external observability dataset.

D2. Identity & Authorization

The Identity & Authorization domain assigns every agent a per-agent (non-human) identity and governs its credential lifecycle: issuance, scoping, rotation, and revocation. The target state is zero-credentials-in-agent-context operation, with explicit treatment of coupled-credential workflows where credential and identity cannot be separated.

Maps to: OWASP ASI03, NIST CAISI Concept Paper (Feb 2026), ISO 27090 (FDIS Mar 2026); Microsoft ZT4AI Identity — Entra Agent ID, the three access patterns, attribute/blueprint Conditional Access, ID Protection for agents, Entra PIM time-limited active role assignment for agents (auto-expiring; agents cannot be PIM-eligible, so no agent self-activation — surfaced by the ZT4AI adversarial pass) (control-level anchors in the ZT4AI review).

See the D2 deep dive. Per-agent identity is now GA platform-native on all three hyperscalers (Entra Agent ID, AWS AgentCore, GCP Agent Identity). Per-task capability tokens move to L5+: no platform ships them, and the only implementation is an early-stage OSS primitive. D2-L3 is the most consequential rung in the model: it raises the D5 and D7 effective-score ceilings (the D2→D5 and D2→D7 caps).

Level 1: Initial

Agents share human credentials or service accounts, and no agent inventory exists.

Evidence: none.

Level 2: Developing

Agents hold distinct service-account identities, tracked in a spreadsheet inventory.

Evidence: inventory artifact.

Level 3: Defined

  • Every agent has a verifiable identity (Okta for AI Agents / Entra Agent ID / SPIFFE workload ID);
  • the audit log traces every action to a human; OAuth 2.1 token exchange handles delegation;
  • the NHI lifecycle binds to the code-deploy pipeline rather than to HR joiner/mover/leaver events (per What Are Non-Human Identities? (Oasis Security));
  • the inventory distinguishes coupled from decoupled NHIs (see Identity-Credential Coupling);
  • every NHI carries a mandatory human-owner field.

Evidence: identity graph; sample audit trail; CI/CD-registered NHI list; owner-field coverage report.

Level 4: Managed

A credential proxy enforces zero-credentials-in-context (AgentKeys / Keychains.dev / Aegis); per-agent policies run in Cedar/OPA; the orphaned-agent kill switch is tested; rotation runs on an automated cadence per credential class (short-lived JWT-class auto-rotates; coupled credentials rotate per a documented dependency map — see D9 L4); each NHI has a behavioral baseline; a migration plan replaces coupled credentials (SAS tokens, storage access keys) with decoupled alternatives (managed identities, role-based access).

Evidence: cred-proxy logs; policy repo; tabletop; rotation-cadence report; coupled-credential migration plan.

Level 5: Optimizing

A unified agent governance program operates in production — registry, lifecycle API, per-agent identity graph, ownership transfer, scoped RBAC, and audit-log integration (reference deployments: Microsoft Agent 365 GA May 1 2026, Anthropic Compliance API Mar 2026; Okta for AI Agents in Early Access, GA expected FY27); shadow-AI discovery is operational; identity binding carries cryptographic attestation (SPIFFE JWT-SVID or equivalent shipping today); zero coupled credentials remain for agent-class NHIs (full migration off SAS / storage access keys / Snowflake-class API keys per Identity-Credential Coupling). Findings tag with ASI03 and applicable AML.T#### IDs.

Evidence: registry export; ISPM dashboard; attestation chain; coupled-credential migration report; ASI03-tagged finding log.

Level 5+: Leading Edge

All of L5, plus:

  • NIST CAISI demonstrator alignment as a named participant (concept paper Feb 2026;
  • demonstrator profile contributed);
  • multi-vendor agent identity federation across two or more IDaaS platforms (Entra + Okta + Keycard) with cross-platform identity-graph reconciliation;
  • contribution to SPIFFE / OAuth 2.1 / OIDC working groups on agent-specific extensions.

Evidence: NIST CAISI participation evidence; cross-platform reconciliation report; standards-WG contribution evidence.

D3. Control & Least-Agency

The Control & Least-Agency domain authorizes agent actions (their scope, timing, human-in-the-loop coverage, and segregation of duties) at a Policy Decision Point outside the model context. It adds progressive-autonomy promotion gates and time-bounded elevation.

Maps to: OWASP ASI02 (Tool Misuse and Exploitation — least-privilege tool profiles, Intent Gate PEP/PDP) and the OWASP Least-Agency principle (ASI09 in the published 2026 list is Human-Agent Trust Exploitation, not autonomy control), Least Agency Principle, AWS Agentic AI Security Scoping Matrix (anchor for the agency-vs-autonomy distinction used throughout this domain), CSA Agentic Trust Framework progressive autonomy gates, CoSAI risk-based governance; Microsoft ZT4AI least-privilege — deny-by-default least-action design and the Agent Governance Toolkit policy decision point (control-level anchors in the ZT4AI review). ZT4AI defines no progressive-autonomy tier model — that comes from the CSA ATF.

See the D3 deep dive. Platform-native PDPs now sit at L3/L4 (AWS Bedrock AgentCore Policy, GA Mar 2026; Microsoft Agent Governance Toolkit, OSS). The L5+ formal-verification line is reframed: Cedar Analysis ships as OSS, so the leading-edge residual is the MCP-wired, trajectory-aware extension, not the analyzer.

Level 1: Initial

No tool-call policies exist; agents may call any tool.

Evidence: none.

Level 2: Developing

Each agent has a tool allowlist, and HITL for “destructive” actions is defined informally.

Evidence: allowlist config.

Level 3: Defined

The OWASP four-tier least-agency model is implemented (auto / notify / confirm / block); a Cedar or OPA Policy Decision Point sits inline before every tool call; each action’s risk tier is documented.

Evidence: PDP config; tier assignments.

Level 4: Managed

A four-stage progressive-autonomy promotion model is implemented (CSA Agentic Trust Framework v1.0 (Feb 2, 2026): Intern → Junior → Senior → Principal, i.e. Observe+Report → Recommend+Approve → Act+Notify → Autonomous-within-domain), advanced through the ATF’s five promotion gates (Performance, Security Validation, Business Value, Incident Record, Governance Sign-off), whose names are verified in the 2026-Q2 standards review. Each stage documents promotion criteria (minimum time at level, accuracy thresholds, availability targets, named security validations, and a sign-off matrix), and an org-authored rubric supplies the Principal-tier hardware-bound identity and policy-as-code prerequisites that the ATF leaves abstract — the ATF gates name criteria categories without measurable thresholds (per the review). HITL coverage is measured per agent and per action class. A lethal-trifecta breaker runs continuously, auto-detecting private-data + untrusted-content + external-comms combinations and downgrading the tier. Time-bounded elevation applies: any decision-right above the agent’s baseline tier (e.g. autoauto-with-write) is JIT, scoped to a maintenance window or a single approval, and auto-reverts at expiry. Segregation of duties is enforced — the agent proposing a change is not the agent approving or deploying it. Findings tag with ASI02 and any AIVSS amplification factor (Execution Autonomy, External Tool Control Surface).

Evidence: promotion-gate runbook (org-authored); HITL telemetry; trifecta-detection log; JIT-elevation expiry log; SoD policy.

Level 5: Optimizing

Capability tokens / Warrants are issued per task with cryptographic binding (Tenuo Warrant or equivalent shipping today); risk-adaptive step-up downgrades the agent’s autonomy tier automatically when D7 behavioral monitoring raises an anomaly score, following the D3 L4 promotion model; a deny-by-default Cedar/OPA policy is compiled and reviewed every release, with no policy drift; SoD is enforced cryptographically — the deploying agent’s signing key cannot also approve. Findings tag with ASI02 and the AIVSS Execution Autonomy / External Tool Control Surface amplification factors.

Evidence: Warrant samples; step-up logs; policy-compile artifact per release; cryptographic SoD evidence.

Level 5+: Leading Edge

All of L5, plus a CaMeL-style privileged/quarantined LLM split for lethal-trifecta-positive workloads in production (Google DeepMind 2025 research; no shipping vendor as of May 2026); formal verification of policy contradictions, vacuity, and shadow subsets via the Cedar Lean compiler over MCP (the Sondera harness approach extended to credential / tool-call PDPs); temporal-logic policy for trajectory-aware constraints (an open research area, given Cedar’s statelessness).

Evidence: CaMeL pilot charter + production deployment evidence; formal-verification reports; temporal-logic policy artifact.

D4. Runtime & Guardrails

The Runtime & Guardrails domain defends against prompt injection, jailbreak, grounding failure, and output-safety violations at runtime. It instruments each guardrail with latency and cost budgets and fails closed on critical paths.

Maps to: OWASP ASI01, ASI02; MITRE ATLAS AML.T0051 (LLM Prompt Injection — incl. .000 Direct / .001 Indirect / .002 Triggered) and AML.T0054 (LLM Jailbreak); CoSAI Maximize Oversight; Microsoft ZT4AI runtime — Prompt Shields (GA), Groundedness Detection + Task Adherence (preview), Defender AI-agent runtime protection (preview), per the ZT4AI review (the preview status confirms the L4-spine grading below); Model-Layer Attacks (output-randomization and query-pattern-monitoring controls applicable at L4); Agent Availability Threats (runtime step / token / recursion budgets at L3+); EU AI Act Art. 15 (cybersecurity) names the attack classes (data poisoning, model poisoning, adversarial examples / model evasion, confidentiality attacks, model flaws) as outcomes but specifies no control, threshold, or test procedure — the gap this domain’s per-level evidence rubric and the ATLAS mitigation anchors fill (2026-Q2 EU AI Act review claim 3).

See the D4 deep dive. The L2/L3 input-and-output safety layer is GA and largely inside Azure entitlements, but the L4 spine is graded honestly: chain-of-thought auditing and groundedness checking are preview or experimental rather than GA (Task Adherence preview; Groundedness Detection preview and English-only; AlignmentCheck experimental). Report D4 as raw + effective: the D3→D4 cap pulls effective D4 down wherever the PDP is weak.

Level 1: Initial

No guardrails exist, or only system-prompt “guardrails.”

Evidence: none.

Level 2: Developing

A vendor prompt filter (the model provider’s default safety filter) runs, with some content-safety classifier on output.

Evidence: provider config.

Level 3: Defined

Platform-level lifecycle hooks are in place (Google ADK, Anthropic hooks, or equivalent); LlamaFirewall PromptGuard 2 or NVIDIA NeMo Jailbreak Detection NIM sits in path; high-risk-tier actions run in a per-task sandbox.

Evidence: hook code; firewall logs; sandbox config.

Level 4: Managed

LlamaFirewall AlignmentCheck (or equivalent CoT auditing) runs on agentic workloads; CodeShield runs on code-gen agents; output classifiers check hallucination and grounding (Azure Groundedness Detection); injection-resistant context boundaries (system-prompt architecture markers) are enforced.

Evidence: AlignmentCheck logs; CodeShield findings; grounding scores.

Level 5: Optimizing

  • Every L4 control is enforced platform-level across every agent surface, with no opt-out for “internal-only” or “low-risk” agents;
  • multi-language injection coverage is measured against the current bypass-class library (LlamaFirewall PromptGuard 2 multi-language + Lakera Guard or NeMo Jailbreak NIM, all shipping);
  • output classifiers update continuously against the latest jailbreak corpora (vendor weekly refresh);
  • response-leak scanning at egress (e.g. an AgentCordon-style outbound credential check) catches credentials echoed in API responses before they reach the agent;
  • per-agent guardrail latency / cost budgets are enforced with fail-closed on critical paths.

Evidence cites specific AIVSS-scored vulnerabilities and the AML.T#### techniques covered.

Evidence: platform-enforcement coverage report (zero opt-outs); multi-language eval log; classifier refresh receipts; response-leak alert log; latency/cost dashboard with fail-closed proof.

Level 5+: Leading Edge

All of L5, plus: (a) cryptographic attestation that guardrails executed in a TEE (AWS Nitro Enclaves-class; reference: Miggo Security pilots, no GA product as of May 2026); (b) a CaMeL-style privileged/quarantined LLM split in production for trifecta-positive workloads (Google DeepMind research; no shipping product); (c) measurable bypass-class evidence covering post-Trendyol leetspeak, non-English, and Unicode-confusable bypasses, with vendor-acknowledged remediation cycles.

Evidence: TEE attestation logs; CaMeL production deployment evidence; bypass-class eval results with remediation timeline.

D5. Egress & Network

The Egress & Network domain mediates agent egress at the network layer. An agent-aware gateway enforces the MCP, A2A, and LLM protocols; per-task egress capability tokens bind to upstream resources; SSRF is closed at the network layer so the gateway is the only path out.

Maps to: OWASP ASI02, ASI07; CoSAI Model Context Protocol (MCP) Security (2026-01-20; the “12 categories / 40 threats” figure was not re-verifiable in CoSAI review and is flagged for a deeper-source check); CSA MAESTRO Layer 4 (Deployment and Infrastructure) + Layer 7 (Agent Ecosystem) per the 2026-Q2 review; Microsoft ZT4AI network — Entra Internet Access prompt-injection protection (GA), APIM AI Gateway with MCP brokering (GA), MCP tool-integrity guidance-only with no single Azure service (control-level anchors in the ZT4AI review).

See the D5 deep dive. Five of eight D5 capabilities are GA platform-native for a Microsoft shop (Azure API Management AI Gateway; MCP brokering with Entra/OAuth/JWT; Entra Internet Access prompt-injection + Shadow-AI; per-agent network policy; identity-scoped tokens). The three genuine off-stack residuals — MCP tool-integrity/rug-pull, per-task tokens, A2A authorization beyond identity — sit at L4–L5+ and do not block an L3 target. D5 investment is wasted ahead of D2 (the D2→D5 cap).

Level 1: Initial

Agents have unrestricted network egress.

Evidence: none.

Level 2: Developing

Each agent has an outbound allowlist (DNS or proxy-level).

Evidence: proxy config.

Level 3: Defined

An agent-aware proxy / gateway sits between agent and external tools, enforcing per-tool RBAC (AgentGateway in Linux Foundation, Solo Enterprise, Cloudflare AI Gateway, Kong AI Gateway, or equivalent); inter-agent A2A v1.0 communication runs over HTTPS / TLS 1.3 + OAuth/mTLS per spec §7 (§8.4 Agent Card signing is algorithm-agnostic, so each org documents its own A2A enforcement profile, including signing algorithm and replay-protection layering); tool fingerprinting is active. Findings tag MCP-server issues with applicable MCP CVEs Q1 2026-class CVE IDs.

Evidence: gateway config; certs; A2A enforcement profile; CVE-tagged finding log.

Level 4: Managed

OAuth 2.1 token exchange runs per tool call (CoSAI / NIST CAISI pattern); rug-pull and tool-poisoning detection is active; A2A content scanning runs (an Oktsec 268-rule equivalent or comparable); the MCP CVE feed is integrated.

Evidence: token-exchange logs; rule sets.

Level 5: Optimizing

A mesh-deployed AgentGateway sidecar (or an AgentCordon-style combined gateway+vault) runs per agent, and no agent egresses without one; per-task egress capability tokens (Tenuo Warrant or equivalent) bind to the specific upstream resource; SSRF and direct-egress paths are closed at the network layer (Smokescreen or equivalent) so the gateway is the only path; the A2A signing enforcement profile is published and audited per release; the MCP CVE feed is wired to auto-quarantine known-bad servers without human-in-the-loop. Findings tag MCP-server issues with applicable MCP CVEs Q1 2026-class CVE IDs.

Evidence: mesh topology with zero-bypass proof; per-task token samples; SSRF closure verification; A2A profile audit; CVE-feed auto-quarantine log.

Level 5+: Leading Edge

All of L5, plus sigstore-for-MCP cross-tenant signing (proposal stage as of May 2026 — no shipping verifier); behavioral A2A drift detection (research-stage; SentinelAgent / TraceAegis / Bi-Level GAD are papers, not products); cross-cloud egress federation with reconciliation across two or more agent-aware proxies.

Evidence: sigstore-for-MCP verifier deployment; A2A drift rule library; cross-cloud reconciliation report.

D6. Data, Memory & RAG

The Data, Memory & RAG domain attributes trust and enforces integrity for everything the agent ingests, retrieves, or persists: its own system prompts and identity files (cognitive file integrity), retrieval corpora, and per-session memory.

Maps to: OWASP ASI06 (Memory & Context Poisoning); MITRE ATLAS AML.T0020 (Poison Training Data), AML.T0024 (Exfiltration via ML Inference API), AML.T0044 (ML Model Inference API Access), AML.T0070 (RAG Poisoning), and AML.T0080 (AI Agent Context Poisoning — incl. .000 Memory / .001 Thread); NIST SP 800-218A PW.3 (PW.3.1/PW.3.2/PW.3.3 training-data integrity) + PS.1.2 training-data protection — the federal build-time anchor for data-integrity, though it carries no RAG/runtime-memory content (2026-Q2 review); CoSAI MCP server data threats; PoisonedRAG / ConfusedPilot literature; Differential Privacy (DP-SGD as L4/L5 control for training-data privacy); Model-Layer Attacks (extraction / inversion / membership-inference defenses); Microsoft ZT4AI data — Purview answer-time entitlement (VIEW + EXTRACT), DSPM for AI oversharing remediation, label-aware DLP, all GA (control-level anchors in the ZT4AI review).

See the D6 deep dive for capability-decoupled criteria, honest tooling-maturity grades, and the cost model. The material change: for a closed-corpus member- or customer-facing RAG bot, the live risk is oversharing and inference exposure (over-permissioned content surfaced or reconstructed for an unentitled asker), not corpus poisoning. Answer-time entitlement enforcement is now the L3 spine; poisoning controls move to L4/L5 and to open / multi-writer corpora.

Level 1: Initial

The RAG corpus has no provenance and agent memory has no integrity controls.

Evidence: none.

Level 2: Developing

RAG retrievals carry document-source labels; skill/plugin source code is reviewed manually; a sensitivity-labeling scheme exists on paper; a first oversharing / data-risk assessment has been run.

Evidence: labeling sample; oversharing-assessment report.

Level 3: Defined

Per-source trust attribution is in place (system-prompt architecture markers); retrieved content is scanned for RAG injection; ingest is scanned for data poisoning; cognitive file integrity (SHA-256) covers agent identity files (SOUL.md / IDENTITY.md / system prompts), extending the AIUC-1 B008.6 model-artifact-integrity primitive (cryptographic checksums for tamper detection on model artifacts) to the prompt / identity-file surface that AIUC-1 does not name. Answer-time access enforcement respects per-user entitlements (not merely source ACLs), oversharing is remediated on the reachable corpus, and answers carry a groundedness check — the load-bearing controls against inference exposure for a member- or customer-facing bot.

Evidence: scan results; CFI baseline; oversharing-remediation record; entitlement-enforcement and groundedness config.

Level 4: Managed

Trust-weighted retrieval (document provenance scoring) runs; a memory- / context-poisoning detector is deployed and wired to the SIEM; a documented PoisonedRAG-class defense is active; continuous oversharing posture management, sensitivity-label inheritance into outputs, and label-aware DLP gating of responses operate; state rollback is tested. The capabilities are stated independent of product; see the D6 deep dive for the dated tooling landscape and which controls are genuinely GA versus research-grade.

Evidence: provenance-scoring config; detector-to-SIEM wiring; DLP response-gating policy; rollback drill.

Level 5: Optimizing

Real-time corpus-drift detection runs (trust-weighted retrieval extended to streaming ingest); a poisoning-rate bound is documented from domain-appropriate empirical evidence (the corpus owner sets the threshold and cites the supporting study — the Nature Medicine 2024 medical-imaging finding is one example, not a general bound); cross-source contradiction detection runs via per-document trust scoring and retrieval-time conflict flagging; system-prompt confidentiality controls operate in production (anti-leakage monitoring per OWASP LLM07:2025, canary tokens active across all agent system prompts, leak-detection alerting wired to SIEM); continuous answer-time semantic-boundary enforcement closes inference exposure — need-to-know enforced at the knowledge layer and re-checked within a session; state rollback (transactional memory) is tested at least quarterly with measured RTO. Findings tag with ASI06, LLM01:2025 / LLM07:2025, and applicable AML.T0080 (AI Agent Context Poisoning: Memory).

Evidence: drift dashboard; threshold-justification memo; conflict-flagging logs; canary-token deployment log; semantic-boundary enforcement config; rollback drill report with RTO.

Level 5+: Leading Edge

All of L5, plus cryptographically attested document attestation at ingest (per-document signature + hash chain; no shipping product as of May 2026 — the closest reference is sigstore for software artifacts, not yet adapted to RAG corpora); a formal taint lattice for cross-source contradiction (research-stage; theoretical foundation in IFC literature, no production system as of May 2026); zero-knowledge proofs for sensitive RAG retrievals.

Evidence: per-doc attestation chain; taint-lattice implementation evidence; ZK-proof verifier logs.

D7. Observability & Detection

The Observability & Detection domain provides telemetry, detection, and continuous evaluation of running agents. Agents emit under OpenTelemetry gen_ai.* semantic conventions; behavioral-drift and AI-SPM monitoring run continuously; red-team evaluation spans distinct attack categories with multiple tools; analyst-actionable alerting wires back to closed-loop controls updates.

Maps to: NIST CSF 2.0 Detect, MITRE ATLAS detection layer, Agent Observability, OWASP ASI08 / ASI10, Agent Availability Threats (anomaly detection for runaway / recursive / resource-exhausting patterns); Microsoft ZT4AI observability — Agent 365 lifecycle telemetry (GA), Defender XDR AI-agent detections and Sentinel agentic-SOC tooling (preview), per the ZT4AI review (preview status confirms the behavioral-detection grading below).

See the D7 deep dive. D7 is the run-rate-heavy domain: high agent-log volume into the SIEM makes log tiering (route low-fidelity trace spans to a cheaper data-lake tier; reserve the analytics tier for detections that fire) the primary cost lever. The OTel gen_ai.* conventions remain experimental, and behavioral-detection products such as Defender XDR AI-agent detection are preview-stage and require platform licensing. Effective D7 is capped by D2 (the D2→D7 cap), so per-agent identity is the prerequisite, not the monitoring product.

Tension with the Stripe/Bullen architectural-containment view (mostly resolved)

Andrew Bullen’s Unprompted talk presents a production agent platform with no D7-style behavioral observability layer at all — Stripe’s defense is architectural containment (Smokescreen + agent-tag CI + Toolshed + ToolAnnotations + HITL on sensitive writes). In Q&A Bullen explicitly says detective controls “have a place, especially for customer-facing products” but Stripe leans on “more deterministic, architectural controls.” Implication for the CMM: a sophisticated practitioner with strong D3/D4/D5 may legitimately score lower on D7 and still have a sound program. The L4 row below requires behavioral monitoring + AI-SPM + quarterly multi-tool red-team — a Stripe-tier architecture would meet the CMM’s safety bar without all of those, and forcing them would be controls-for-controls’-sake.

Resolution (2026-05-04 revision): the new effective-score aggregation now reports D7 raw + the strategic-rationale field rather than dragging the headline rating down to D7’s level. Stripe’s matrix reads “L4 typical / L2 D7 (intentional trade-off — D3+D5 architectural containment)” instead of “L1 overall.” A future candidate rule (DR-C002 in the dependency-rules registry) considers whether D5 strength can raise the D7 ceiling for architectural-containment archetypes; that’s a v2+ design decision (negative-rules / floor-relaxation) parked as an open question on the dependency-rules page.

Level 1: Initial

No agent-specific logs exist; only the vendor console.

Evidence: none.

Level 2: Developing

A tool-call audit log records agent action history with user attribution.

Evidence: sample log.

Level 3: Defined

Agents emit OpenTelemetry gen_ai.* semantic conventions (model, request, tool, retrieval, agent spans); LangSmith / Langtrace / Traceloop or equivalent sits in path; logs carry identity multiplexing; every tool call populates a minimum action-log schema — {timestamp, agent_id, user_id, action_type, resource_path, approval_status, rollback_ref} — and rollback_ref points to a recoverable state (Brain Git commit, transaction ID, or a documented “irreversible” classification with prior approval).

Evidence: trace samples; span schema validation; action-log schema conformance check.

Level 4: Managed

Agent behavioral monitoring is operational (Vectra / Miggo / SecureClaw nightly audits); behavioral-drift alerts wire to SIEM/SOAR; AI-SPM is deployed (Wiz / Prisma AIRS / Orca); a quarterly red-team eval covers distinct attack categories — orchestration / multi-turn (PyRIT), probe library (Garak), regression suite (Promptfoo), and continuous CART (Mindgard CART or equivalent). Single-tool coverage is not L4. Eval results tag with AML.T#### and AIVSS scores; behavioral-monitoring alerts tag ASI08 / ASI10 per detection rule.

Evidence: behavioral-monitoring dashboards; multi-tool eval reports with ID tags.

Level 5: Optimizing

A real-time AI-BOM runs (Miggo DeepTracing or equivalent shipping ADR product); agent-aware SIEM playbooks are deployed in production (Falcon AIDR + NeMo Guardrails, or Sentinel + Defender for Cloud Apps, or an equivalent shipping vendor pair); per-agent behavioral baselines carry documented prompt-volume-to-alert ratios (per the Salesforce Rittinghouse case study: baseline ratio established and held over at least one quarter); high-fidelity alerting reaches a measured analyst-actionable rate of at least 80%; every triggered alert wires back to a controls update within a defined SLA. Detections tag with ASI08 / ASI10 per rule; behavioral findings carry applicable AIVSS amplification scores.

Evidence: DeepTracing graph; agent-aware playbook samples; prompt-volume-to-alert dashboard ≥1 quarter; analyst-actionable rate report; SLA-bounded controls-update log.

Level 5+: Leading Edge

All of L5, plus a cascade-detection rule library with tuned thresholds for ASI07/08/10 multi-agent risk (research-stage as of May 2026 — SentinelAgent, TraceAegis, Bi-Level GAD published; no production rule library shipping); cross-agent behavioral monitoring with statistical multi-agent baselines (joint-distribution, not just per-agent); model forward-pass activation monitoring per Glass-Box Security (Starseer pre-launch, no shipping product).

Evidence: cascade rule registry with thresholds; multi-agent joint-baseline statistics; forward-pass activation monitor evidence.

D8. Supply Chain & AI-BOM

The Supply Chain & AI-BOM domain establishes provenance, integrity, and disclosure for the model, skill, dependency, and tool artifacts that compose an agent’s runtime. It works through build-time and runtime AI-BOM, signed releases, registry and pre-install scanning, ML-VEX disclosure, and SLSA-graded provenance.

Maps to: OWASP ASI04, NIST SP 800-218A (SSDF AI Profile) — PS.3.2 model provenance, PW.4.4.R1 verify acquired models, PS.1.3.R4 weight protection; the Profile names SBOM/SLSA but specifies no AI-BOM artifact schema (2026-Q2 review claim 3), EU AI Act Art. 11 / Annex IV — the closest binding instrument to an AI-BOM mandate, but a prose disclosure schema, not a machine-readable BOM format (2026-Q2 EU AI Act review claim 5); CycloneDX ML-BOM (v1.7 current), SPDX 3.0; Microsoft ZT4AI supply chain — Defender for Cloud AI-SPM generative AI-BOM discovery across Azure/Bedrock/Vertex (GA), extended to MCP-server and AI-model-provider catalog coverage in Defender for Cloud Apps, and AI model scanning in CI/CD (preview), per the ZT4AI review.

See the D8 deep dive. D8 splits along the model-consumer vs model-producer axis: producer-grade controls (build-time ML-BOM generation, training-data provenance, weight protection, ML-VEX publishing) are producer-only, so a model consumer reaches L4/L5 on verification-and-reconciliation of acquired artifacts alone. A model-consumer persona scores L1 against the old D8 criteria, which measured producer controls it never operates; crediting consumer controls (lockfile SCA, signature verification, malicious-model scanning, mostly in E5 / GitHub entitlements) lifts it to L3. CycloneDX ML-BOM is version-agnostic here (v1.7 current); SLSA Build has no Level 4 in v1.0 (L1–L3 only).

Level 1: Initial

No model or skill provenance is tracked.

Evidence: none.

Level 2: Developing

Model and library versions are tracked manually, and vendor-attested model cards are collected.

Evidence: inventory.

Level 3: Defined

The OWASP AIBOM Generator (CycloneDX) or SPDX 3.0 AI extension produces an AI-BOM at build; releases are signed; skills and MCP servers pass registry-scan and pre-install scan (Aguara Watch / SecureClaw).

Evidence: AI-BOM artifact; sigstore log.

Level 4: Managed

sigstore/cosign signs every model and skill artifact; an ML-VEX equivalent handles vulnerability disclosure; a runtime AI-BOM (Miggo DeepTracing or equivalent) reconciles with the build-time AI-BOM; cognitive file integrity baselines cover every IDENTITY.md / SOUL.md. Findings tag with ASI04, applicable CVEs (e.g. MCP CVEs Q1 2026-class), and ATLAS AML.T#### supply-chain techniques (incl. “Publish Poisoned AI Agent Tool,” added in v5.4.0).

Evidence: sig-verified registry; reconciliation report; ID-tagged ML-VEX feed.

Level 5: Optimizing

A closed loop runs in production — cred-proxy → AI-BOM → AI-SPM: every vended credential reconciles against the AI-BOM, every AI-BOM artifact reconciles against AI-SPM posture findings, and every AI-SPM finding produces a controls update within SLA; AI artifacts reach SLSA Level 3 (signed provenance, hermetic builds, isolated build environments — achievable today with sigstore/cosign + GitHub Actions / Buildkite hardened runners); the runtime AI-BOM (Miggo DeepTracing or equivalent) reconciles against the build-time AI-BOM under a zero-tolerance drift policy; an ML-VEX feed is published for the org’s own AI components. Findings tag with ASI04, applicable CVEs, and ATLAS AML.T#### supply-chain techniques.

Evidence: closed-loop diagram with SLA evidence; SLSA L3 attestation; reconciliation report; ML-VEX feed.

Level 5+: Leading Edge

All of L5, plus hermetic, reproducible builds for AI artifacts beyond SLSA Build L3 (research-stage — SLSA v1.0 specifies no Level 4, and reproducible builds for stochastic model weights are unsolved); cross-vendor AI-BOM federation (reconciliation across two or more AI-BOM-emitting platforms; aspirational as of May 2026); cryptographic name→binary signing for MCP servers (the registry gives namespace provenance only, no such signing exists today); an active named contributor to the OWASP AIBOM Generator / CycloneDX ML-BOM / SPDX 3.0 AI-extensions working group (PR / spec authorship).

Evidence: SLSA L4 report; cross-vendor reconciliation; named-contributor evidence.

D9. Operations & Human Factors

The Operations & Human Factors domain collects the cross-cutting operational and human-factor controls that no surveyed AI security standard mandates as a coherent set (per the 11-standard validation): HITL-fatigue monitoring, decommission and rotation lifecycle, latency / cost discipline, system-prompt confidentiality, federated incident sharing, and model deprecation policy.

Maps to: NIST AI 800-4 post-deployment monitoring (human factors flagged as biggest blind spot); EU AI Act Art. 12 logging, Art. 14 human oversight; OWASP LLM07:2025 System Prompt Leakage; CoSAI AI Incident Response Framework (2025-10-30, per CoSAI review); CSA ATF Incident Response element (kill switch, demotion-to-Intern on critical incident) per the 2026-Q2 review; Microsoft ZT4AI operations — Entra ID Governance sponsors with automatic manager-transfer and time-bound access packages (GA), per the ZT4AI review, which also confirms ZT4AI ships no HITL-fatigue / human-factors tooling.

See the D9 deep dive. D9 is process- and labor-heavy and largely product-free: HITL-fatigue measurement and bus-factor continuity have no product on any stack (a market gap, not a Microsoft gap). Its dependencies are stable standards (CoSAI AI Incident Response Framework (2025-10-30), OTel/canary patterns, the GA Entra Agent ID lifecycle), so it is cadence-safe, and right-sizing matters most here: a contained low-autonomy bot targets a narrow L3, not mesh-grade IR. The L4→L5 “campaign, not a step” gate lives substantially inside D9 (the continuity test + two-quarter stable-L4 history), so D9’s continuity evidence is what every other domain’s L5 claim depends on.

**Why this domain exists

The validation page (Validation: Agentic AI Security CMM vs Widely Adopted Standards §3) surfaced seven operational gaps that no surveyed standard mandates as a coherent set but a credible agentic-AI program must operate: guardrail latency / cost budgets, non-adversarial drift, agent decommission lifecycle, human-factors monitoring, federated incident sharing, model deprecation, system-prompt confidentiality. D9 packages these into one cross-cutting domain which the assessor measures and improves independently of the per-plane domains.

Level 1: Initial

No operational SLAs for guardrails, no decommission procedure, no HITL-fatigue tracking, no system-prompt confidentiality controls.

Evidence: none.

Level 2: Developing

A runbook documents (a) guardrail timeout / fail behavior, (b) agent decommission and credential rotation when a human owner leaves, (c) HITL queue monitoring, and (d) basic system-prompt protection (system messages not echoed to the user).

Evidence: runbook artifact.

Level 3: Defined

Guardrail latency and cost budgets are measured per agent (p50/p95/p99); the fail-mode is explicit and tested (fail-closed for high-risk tier, fail-open documented for read-only); the orphaned-agent reaper runs on schedule with a measurable SLA; HITL approval-rate and queue-age are tracked; system-prompt extraction defenses are in place (canary tokens deployed; LLM07:2025 test cases in the red-team suite); a model deprecation policy is published; the org participates in incident disclosure in at least one community (CoSAI IR, OWASP LLM Top 10 contributors, MITRE ATLAS contributors).

Evidence: latency/cost dashboard; reaper logs; HITL telemetry; canary deployment proof; community participation evidence.

Level 4: Managed

Quantitative HITL-fatigue indicators are tracked (rubber-stamp rate, false-positive burnout metric); benign behavioral drift detection is separated from adversarial detection (per NIST AI 800-4 categories); decommission drills run quarterly (tabletop or live); a model version-pinning policy operates in production; an AI-VEX equivalent is published for the org’s own AI components; the org joins coordinated-disclosure exercises of the MCP CVEs Q1 2026 kind; a per-credential dependency map is maintained (which consumers depend on which NHI credential — required before automated rotation per What Are Non-Human Identities? (Oasis Security)); the rotation runbook is tested for coupled-credential cases per Identity-Credential Coupling. Findings tag with LLM07:2025 and any AIVSS amplification factors that apply to drift / autonomy.

Evidence: HITL-fatigue KPIs; benign-drift dashboard; drill report; AI-VEX feed; cross-org incident report; dependency map; rotation runbook test report.

Level 5: Optimizing

Closed-loop continuous improvement runs in production: every guardrail / decommission / HITL incident produces a measurable controls update within a defined, org-published SLA (e.g. P1 ≤ 24 hours, P2 ≤ 1 week); the org demonstrates zero orphaned credentials, zero prompt leaks, and zero undeprecated models in production for at least two quarters, with attestations; a deputy + runbook continuity test completes each quarter (anti-pattern I3 recovery); HITL-fatigue indicators stay within published thresholds (rubber-stamp rate, queue p95 within target).

Evidence: SLA-bounded controls-update log; clean-state attestations; quarterly continuity-test report; HITL-fatigue dashboard within thresholds.

Level 5+: Leading Edge

All of L5, plus organization-level AI risk-observability metrics published externally (e.g. a CSAI Foundation AI Risk Observatory contribution); active named contribution of drift-detection patterns and bypass classes back to standards bodies (CoSAI IR Framework, OWASP LLM Top 10, MITRE ATLAS); cross-org coordinated-disclosure leadership in MCP CVEs Q1 2026-class exercises.

Evidence: external observability dataset; named contribution evidence; coordinated-disclosure leadership artifacts.

Mapping to deployment shapes

A small organization with one chatbot will not pursue Level 5 across all 9 domains, and almost no organization will pursue L5+ across all 9 domains. L5+ is intentionally bleeding-edge and unachievable without category-creation work. The CMM is meant to be applied per agent application, not enterprise-wide. **The default expectation for a sufficiently resourced 2026 program is L4 across all domains with selective L5 where deployment exposure justifies it

L5+ ambitions are appropriate for frontier labs, hyperscalers’ own platforms, and dedicated AI-security research shops.

ApplicationRealistic target (most enterprises)Domains where Level 5 is justified
Web/desktop chatbot (no tools)L3 across allD4 (if processing high-stakes content), D9 (system-prompt confidentiality)
Generative coding tool (Cursor / Copilot / Claude Code class)L4 across allD2, D4, D8 (skill/MCP supply-chain risk), D9 (decommission cadence, prompt leakage); see coding-agent note below
Data-science copilotL3 → L4D2 (data scope), D6 (data integrity), D9 (operational drift in long-running notebooks)
RAG applicationL3 → L4 in D6 + D7D6 (closed corpus: oversharing / inference exposure, so entitlement enforcement; open / multi-writer corpus: PoisonedRAG / ConfusedPilot), D9 (model deprecation and embedding versioning)
MCP server (provider)L4 in D5 + D8D8 (consumed by many; signing is critical), D9 (federated CVE disclosure)
Agent skill (publisher)L4 across allD8, D2, D9 (skill deprecation policy)
Multi-agent meshL4 minimumD5, D7 (cascade / rogue-agent detection), D9 (HITL-fatigue at scale)

**Coding-agent specific evidence (L3+)

Per AI Coding Agent Governance (Knostic), a coding-tool deployment adds four evidence items at Level 3 and above:

  • Agent rules-file integrity — Cursor .cursorrules, Copilot Workspace rules, and Claude IDENTITY.md carry a baseline and drift detection, extending cognitive file integrity to rules files.
  • IDE extension provenance — an extension allowlist with sigstore-equivalent verification.
  • Typosquat / dependency-hijack defense at install time (Aguara Watch / Kirin / equivalent).
  • Destructive-action classification — force-push, branch deletion, mass refactor, and prod-config write auto-route to the confirm or block tier per the Decision Rights for AI Agents matrix.

Tooling map per domain

Three categories: Standards / Specs = formally governed specifications, frameworks, or guidance documents (IETF, CNCF, OWASP, NIST, CSA, etc.); OSS tools = open-source software with an Apache / MIT / similar license; COTS / SaaS = commercial off-the-shelf or managed cloud service. A single capability may appear in multiple categories when standards define the protocol and both OSS and commercial implementations exist. See Agentic AI Security Reference Architecture §Recommended stacks for opinionated per-profile selections.

DomainStandards / SpecsOSS toolsCOTS / SaaS
D1 GovernanceOWASP ASI Top 10, NIST AI RMF, ISO 42001, EU AI Act, AIUC-1 six pillars, CoSAI PrinciplesOWASP ASI Top 10 templates, AIUC-1 self-assessment checklistsKPMG / Schellman audits, RSAC governance services
D2 IdentitySPIFFE (CNCF standard); OAuth 2.1 (IETF RFC 9700); OIDC (OpenID Foundation); NIST CAISI Concept Paper (Feb 2026)SPIRE (CNCF OSS); AgentKeys; Keychains.dev; Aegis; OneCLI; AgentSecretsOkta for AI Agents (Early Access; GA expected FY27); Microsoft Entra Agent ID; Microsoft Agent 365 (GA May 1 2026); Aembit; Astrix; CyberArk Conjur
D3 Control & Least-AgencyOWASP four-tier least-agency model; CSA Agentic Trust Framework (Feb 2026) 5-gate modelRego (CNCF OSS); Cedar (Apache 2.0, AWS); Tenuo Warrants (OSS); AgentShield permission rules (MIT)AWS Cedar managed (Mar 2026 AI release); Anthropic Compliance API; Permit.io; Topaz
D4 Runtime & GuardrailsLlamaFirewall (Meta — PromptGuard 2, AlignmentCheck, CodeShield); NeMo Guardrails (NVIDIA OSS); Guardrails AI; Microsoft Agent Governance Toolkit (Apr 2026); AgentShield hook + agent + prompt-injection rules and MiniClaw sandboxed-runtime reference (MIT)Lakera Guard; Lasso; HiddenLayer; Microsoft Prompt Shields; NeMo NIMs (commercial); Robust Intelligence
D5 Egress & NetworkA2A v1.0 spec (Linux Foundation); CoSAI Model Context Protocol (MCP) Security (2026-01-20)AgentGateway (Linux Foundation, Apache 2.0); Oktsec; mTLS via Istio or Linkerd (both CNCF OSS); AgentShield MCP remote-transport rules (MIT)Solo Enterprise for AgentGateway; Operant MCP Gateway; Natoma; Cloudflare AI Gateway; Kong AI Gateway
D6 Data, Memory & RAGCycloneDX ML-BOM (OWASP); SPDX 3.0 AI extensions (Linux Foundation)OWASP AIBOM Generator; sigstore / cosign; LangChain PII Middleware. Research-grade, not deployable controls: RAGShield, TrustRAG, Brain Git (SlowMist), SecureClawGA, oversharing / answer-time: Microsoft Purview DSPM for AI; DLP for M365 Copilot; Azure AI Content Safety Groundedness (English-only); Restricted SharePoint Search (site-capped stopgap). ReversingLabs ML scan; JFrog ML scan; Protect AI; Cohere Embed. See D6 deep dive
D7 Observability & DetectionOTel gen_ai.* SemConv v1.37+ (CNCF); MITRE ATLAS detection layerLangtrace; Traceloop; Helicone; Promptfoo; PyRIT (Microsoft OSS); Garak (NVIDIA OSS)LangSmith; Wiz AI-SPM; Palo Alto Prisma AIRS; Orca AI-SPM; Reco; Mindgard CART; Vectra AI; Miggo Security
D8 Supply Chain & AI-BOMCycloneDX ML-BOM (v1.7); SPDX 3.0 AI ext; NIST SP 800-218A SSDF AI Profile; EU AI Act Art. 11 / Annex IV; GitHub Artifact Attestations (SLSA L2/L3)OWASP AIBOM Generator; sigstore / cosign; Aguara Watch; SecureClaw 55-check audit; AgentShield MCP-package-provenance + skill-marketplace rules (MIT)Anchore; Snyk AI; JFrog AI Catalog; ReversingLabs; IBM Granite disclosures; Lineaje
D9 Operations & Human FactorsNIST AI 800-4 monitoring categories; OWASP LLM07:2025 test cases; CoSAI IR Framework v1.0; MITRE ATLAS coordinated-disclosure templatesOTel latency / cost spans; canary-token tooling; AgentShield baseline-drift gate + time-bound policy-exception lifecycle audit (MIT)DataDog AI Monitoring; New Relic AI Monitoring; Sentry AI Tracing; AI-VEX disclosure platforms (emerging); Schellman / Coalfire AI risk-observability services

AgentShield placement rationale

AgentShield (Feb 2026, MIT, Knostic-adjacent — actually Affaan M and the Everything Claude Code ecosystem) treats the agent harness configuration tree as its unit of analysis, a control surface that application-code scanners and network-traffic tools do not cover. It appears in five rows above because its 102 rules across Secrets / Permissions / Hooks / MCP Servers / Agents map cleanly to multiple CMM domains: D3 (permission rules), D4 (hook + agent + prompt-injection rules + the MiniClaw reference sandbox), D5 (MCP remote-transport and network-exposure rules), D8 (MCP-package-provenance and skill-marketplace controls — the most distinctive contribution), and D9 (baseline-drift gate + time-bound exception-lifecycle audit). The provenance-aware runtimeConfidence discipline and the corpus-gate-with-prioritized-improvement-plan instrument are captured separately as Harness Config as Supply-Chain Artifact and Control-Efficacy Gate candidate primitives parked for the next CMM revision pass.

Application-code vuln-discovery tools are not in this map

OpenAnt (Knostic OSS), Codex Security / Aardvark (OpenAI), Claude Code Security (Anthropic), MDASH (Microsoft), Big Sleep + CodeMender (Google), and XBOW × Mythos (offensive evaluation) are intentionally not listed in the per-domain tooling map. These tools target application-code vulnerability discovery — finding bugs in the codebase — rather than agent-security maturity capabilities — controls protecting the agent itself. They are tracked instead on the Frontier AI for Vulnerability Discovery thesis page, which catalogs the six current production paths and the FP-control-as-architectural-primary discipline that converges across them. An org with a mature ai-vuln-discovery capability and an immature CMM posture is a normal observation; the two surfaces grade different things. If the CMM evolves to include “AI-driven secure-SDLC” as an evidence dimension at D8 — alongside the existing supply-chain controls — these tools would gain a placement; that is a candidate for a future CMM revision pass.

Practitioners worth following

These individuals and organizations have shipped substantive work on the controls in this CMM, cited where their output directly informed it.

Person / orgContributionRelevant page
Simon WillisonLethal Trifecta (Jun 2025); CaMeL coverage; structural test for prompt-injection vulnerabilitySimon Willison
Johann RehbergerEmbrace The Red; Month of AI Bugs (Aug 2025); Jules AI kill chainJohann Rehberger
Bill McIntyreSecuring Your Agents (2026, AIE / RMAIIG); 40-slide layered playbookBill McIntyre
Jason Clinton (Anthropic Deputy CISO)AIVSS Distinguished Review Board; CISO’s Guide to Agentic AI webinar(entity stub candidate)
Apostol Vassilev (NIST)NIST AI 600-1 lead; CAISI early contributorApostol Vassilev
Ken HuangOWASP AIVSS lead(entity stub candidate)
Meta Purple Llama teamLlamaFirewall (PromptGuard 2 / AlignmentCheck / CodeShield)LlamaFirewall
Solo.io / Linux Foundation AAIFAgentGateway → LF (July 2025); Solo Enterprise distributionAgentGateway
Microsoft Security ResearchFIDES (zero successful PI on AgentDojo); ZT4AI; Agent 365; M365 memory-injection detectorMicrosoft Responsible AI Standard (RAI)
Google DeepMindCaMeL privileged/quarantined LLM splitGoogle
NIST NCCoECAISI AI Agent Standards Initiative; Concept Paper Feb 2026NIST — National Institute of Standards and Technology
CoSAI / OASISModel Context Protocol (MCP) Security (2026-01-20); Principles for Secure-by-Design Agentic Systems; Agentic Identity and Access Management (2026-04-17)CoSAI — Coalition for Secure AI
OWASP Gen AI ProjectASI Top 10; AIVSS v0.8; AIBOM Generator; Practical Guide for Secure MCPOWASP — Open Worldwide Application Security Project
CSAMAESTRO threat model; Agentic Trust Framework with 5 promotion gates (Feb 2, 2026)CSA — Cloud Security Alliance
AIUCAIUC-1 standard; quarterly updates; Schellman accredited Feb 2026(entity stub candidate)

Implementation roadmap

The roadmap has four phases (Foundation → Standardization → Measurement → Optimization), with an optional fifth for organizations targeting L5+.

PhaseMonthsFocusTarget by end of phase
1. Foundation1–3Inventory + identity + operational baselineD1 L2, D2 L2, D8 L2, D9 L2
2. Standardization4–9Platform-level enforcement (the critical inflection) + system-prompt confidentialityD2 L3, D3 L3, D4 L3, D5 L3, D7 L3, D9 L3
3. Measurement10–18Behavioral monitoring + red-team + AI-BOM + HITL fatigue + decommission drillsD6 L3+, D7 L4, D8 L4, D9 L4
4. Optimization18+AIUC-1 / ISO 42001 cert; ≥2-quarter L4 stability; closed-loop ops improvement; bus-factor ≥2 with continuity testD1 L5, selective L5 in domains tied to deployment exposure, D9 L5
5. Leading Edge (optional)24+Research-stage primitives in production (TEE attestation, CaMeL split, cascade-detection); active named standards contribution; cross-vendor federationL5+ in 2–4 selected domains aligned to org’s research / product portfolio

The critical inflection in this roadmap is end of Phase 2 (month ~9): Level 3 across D2–D5 + D7 marks the boundary between platform-level enforcement and prompt-level reliance. Below that boundary, an organization remains structurally vulnerable to prompt injection per the Lethal Trifecta test.

Appendix: ten security dimensions (complementary threat-surface view)

The CMM’s nine domains are organized by where to enforce controls (governance, identity, control plane, runtime, egress, data, observability, supply chain, ops). The ten dimensions below are organized by what to defend against. One view drives architecture; the other drives threat modeling. The mapping back into CMM domains shows where each anchor threat lands.

#DimensionAnchor threatCMM domain(s)
1Adversarial resiliencePrompt injection, jailbreaking, multilingual / leetspeak bypassD4 Runtime
2Data integrityTraining, fine-tuning, RAG, MCP-tool-metadata poisoningD6 Data + D8 Supply Chain
3Model securityExtraction (API scraping, distillation, side-channel/TPUXtract)D2 Identity + D5 Egress
4Privacy protectionMembership inference, embedding inversionD6 Data
5Supply chain securityHugging Face / npm / model-registry compromise; ClawHavoc-classD8 Supply Chain
6RAG and vector securityCorpus poisoning, ConfusedPilot, embedding leakageD6 Data
7Agentic AI governanceMCP, tool poisoning, memory poisoning, autonomy creepD2 + D3 + D5
8Output safetyContent filtering, hallucination, misuse preventionD4 Runtime + D9 Ops
9Lifecycle managementTraining env, deployment hardening, monitoring, retirementD1 + D8 + D9
10AI incident responseIR for prompt injection / poisoning / agent containmentD7 + D9

Use this lens when reasoning about what kinds of AI threats a deployment is exposed to; use the CMM’s nine domains when deciding where in the stack to enforce the response.

Appendix: what this CMM contributes beyond reviewed standards

The contributions below were checked against eleven widely-adopted AI-security standards (NIST AI RMF / 600-1 / 800-4 / IR 8605A; ISO 42001 Annex A + 27090 + 42006; MITRE ATLAS v5.6.0; OWASP ASI / AIVSS / LLM Top 10; Google SAIF; CoSAI primaries; Microsoft RAI / ZT4AI; CSA MAESTRO + ATF; EU AI Act; AIUC-1) on 2026-05-06 via primary-source agent fetches. The check was keyword-level evidence collection; see §4 for per-claim tags and primary-source citations, and the audit backlog in Standards Validation Methodology for the deeper clause-by-clause reviews still pending. The items below are load-bearing pending deeper audit, and their “no reviewed standard does X” claims are bounded to that surveyed set.

  1. **Cross-domain aggregation discipline (dependency-resolved effective scores)

No reviewed AI security standard enforces cross-domain aggregation. CMMC 2.0 uses cumulative levels; the CMM imports the discipline but uses dependency-resolved effective scores (v1 = 3 caps: D2→D5, D2→D7, D3→D4) that capture real cross-domain attack-path failures without punishing strategic trade-offs. This prevents the “L4 in governance, L1 in egress” cherry-picking that plagues self-assessments. 2. **Cognitive File Integrity scoped to system prompts and identity files

AIUC-1 B008.6 mandates cryptographic checksums for model-artifact tamper detection, the closest near-miss in any reviewed standard. The CMM’s D6 L3+ extends the same primitive to system prompts and identity files (SOUL.md / IDENTITY.md), which no reviewed standard names. The file-discovery layer is not yet standardized; see CMM Known Limitations §5. 3. **Credential proxy at D2 L4 as a hard line

“Zero credentials in agent context” with named tooling (AgentKeys / Keychains.dev / Aegis). CoSAI MCP Security recommends token exchange and “do not pass through OAuth tokens” as a principle; CoSAI Agentic IAM and Google SAIF discuss credential management at principle level. None gates credential proxy by maturity tier. 4. **Lethal Trifecta as a structural test

D3 L4 “lethal-trifecta breaker active” makes Simon Willison’s structural argument (untrusted input + sensitive data access + external communication) auditable. A verbatim search across CoSAI / SAIF / AIUC-1 / CSA ATF returned zero hits for “trifecta” or any structural naming. SAIF Focus on Agents describes the chain in prose under Rogue Actions framing without naming the pattern. See Lethal Trifecta. 5. Real-time AI-BOM at L5 (Miggo DeepTracing or equivalent). CycloneDX ML-BOM treats machine-learning-model as a static build-time component with no runtime reconciliation fields. EU AI Act Annex IV item 9 requires documentation OF a post-market monitoring system (per Article 72), not runtime reconciliation between deployed system and AI-BOM. Only the CMM grades runtime reconciliation as a level criterion. 6. **Multi-agent cascade detection at L5+

MITRE ATLAS v5.6.0 cross-check: zero matches for “multi-agent / agent-to-agent / A2A / inter-agent / cascade / sub-agent” across the full canonical YAML. AML.T0108 “AI Agent” and AML.T0103 “Deploy AI Agent” treat the agent as a single Persona-actor, not as a member of an inter-agent graph. CSA MAESTRO has only partial coverage. The CMM names the gap and points at the rule-library shape that would close it (cascade-detection rule library is research-stage; lives at L5+ explicitly aspirational).

These six are the load-bearing positive contributions. For known limitations of the same CMM, see CMM Known Limitations (current state).

Open questions and gaps

Remaining gaps

  1. Agent-archetype tailoring — partially addressed The generative coding tool archetype now has specific evidence (rules-file integrity, IDE extension provenance, typosquat defense, destructive-action classification) per the AI Coding Agent Governance ingest. The customer-support / member-service chatbot archetype is now substantially addressed via the regulated-FI stress test and the D1 and D6 recalibration deep-dives (oversharing / inference exposure as the D6 spine; scheme-neutral assurance in D1). Still TBD: data-science copilot, multi-agent mesh, MCP-server-as-provider archetypes.
  2. Multi-agent governance depth D5 + D7 + D9 acknowledge ASI07/08/10. As of the 2026-05-04 calibration, the cascade-detection rule library now lives explicitly at L5+ rather than being an under-specified L5 requirement — “how many agents in your mesh, with what cascade-detection coverage” is the open quantitative question for L5+ adoption rather than a qualitative L5 gap.
  3. AIUC-1 Society pillar The CMM has no analogue for catastrophic-misuse / national-security externalities. Acknowledged in Agentic AI Security CMM — Standards Crosswalk Matrix.
  4. Quantitative thresholds at L4 “Quantitative HITL-fatigue indicators” lacks specific thresholds (rubber-stamp rate < X%, queue age p95 < Y minutes) — TBD pending early-adopter production data.
  5. Synthetic incident library Stage 2 of the measurement protocol calls for synthetic incidents (PoisonedRAG corpus injection, ClawHavoc-class skill swap, prompt-injection via retrieved doc, A2A impersonation) but no curated library exists.