AI Security Maturity: There's a Map for That Now

Your company uses AI. Developers have GitHub Copilot. Customer support runs on an LLM. Someone in finance discovered ChatGPT six months ago and hasn't stopped. There's a policy - don't paste sensitive data into public AI tools - and everyone nodded when it was announced.

You have AI security handled. Except you probably don't. And until recently, there wasn't a structured way to find out exactly how far off you were. The Cloud Security Alliance just changed that with the AI Security Maturity Model (AISMM).

What the AISMM Actually Is

Three Domains, Twelve Practice Areas

The AISMM maps five levels of AI security capability across twelve practice areas organized into three domains:

Foundational: Governance, Organization Management, IAM, Security Monitoring.

Structural: Infrastructure Security, Model Security, App Security, Data Security.

Procedural: Risk & Provider Assessment, AI Dev & Supply Chain, Privacy/Compliance, Incident Response.

Numbered Control Objectives and Framework Mappings

Each practice area carries numbered control objectives - e.g., GOV-03.1, IAM-04.2 - explicitly mapped to the CSA AI Controls Matrix (AICM), NIST AI RMF, OWASP LLM Top 10, and MITRE ATLAS.

To claim a given level, an organization must meet all control objectives for that level across at least 85% of deployments. One beautifully instrumented flagship project doesn't carry the rest.

The Five Levels

Level 1 - Initial

Ad-hoc AI adoption. Default configurations, no AI-specific security visibility, no policies.

Level 2 - Repeatable

Initial policies in place. Service accounts inventoried. Provider logs enabled. Security engaged inconsistently.

Level 3 - Defined

Formal AI governance structure (AI Council or equivalent). Authoritative registries for providers, models, and deployments. AI-specific playbooks. Initial guardrails and prompt/response logging for high-risk deployments.

Level 4 - Capable

Centralized enforcement across clouds. AI-SPM deployed for automated discovery. Agents have per-agent identities federated to the enterprise IdP. Behavioral-baseline threat detection running in the SOC.

Level 5 - Efficient

Comprehensive automation. Ephemeral just-in-time credentials. Runtime behavioral analysis. Tamper-evident agentic telemetry. Automated compliance reporting and evidence collection.

The Hard Truth

Most organizations believe they are at Level 3. Most are at Level 2. A meaningful number are at Level 1 and don't know it.

The Gap Nobody Talks About

Why Level 2 to Level 3 Is a Different Program

The jump from Level 2 to Level 3 is where organizations consistently underestimate themselves - and where most real risk lives. At Level 2, you have policies and a spreadsheet of providers. At Level 3, you have something structurally different.

The Level 3 Control Objectives That Trip Teams Up

GOV-03.1 - A cross-functional AI Council publishing a catalog of approved use cases mapped to providers and data types, including PII permissions per use case.

GOV-03.2 - An authoritative deployment registry linking each AI application to an owning team, its underlying models, agents, and MCP integrations.

GOV-03.3 - Role-based AI training - baseline, developer, and high-risk-role tracks - with tracked completion.

IR-03.1 - Playbooks covering prompt injection, data exfiltration, model abuse, compromised agent credentials, tool/MCP misuse, and agent hijacking - with containment steps branching by deployment type.

That is not an incremental improvement. That is a different security program.

What the Model Gets Right

Non-Human Identities Are Finally a First-Class Concern

An agent is not a user. It has its own credential footprint, its own access scope, its own blast radius. The AISMM treats this with precise escalation requirements across levels.

IAM-02.2 · L2 - AI workloads run under inventoried non-human identities; no personal or shared credentials; each NHI traces to a named owner.

IAM-03.1 · L3 - Per-workload NHI with managed credential lifecycle. Compromise of one workload's identity does not cascade across the AI estate.

IAM-04.1 · L4 - Per-agent identities federated to the enterprise IdP or established via attestation. Self-hosted agents use SPIFFE/SPIRE; PaaS agents use provider-native primitives (AWS AgentCore, Azure Foundry managed identity, Vertex per-agent service accounts).

IAM-05.1 · L5 - Just-in-time ephemeral credentials wired into the agent pipeline. Long-lived static credentials exist only as time-bounded exceptions with executive sign-off.

MCP Authorization Has an Explicit Technical Standard

Most security frameworks haven't caught up with the Model Context Protocol. The AISMM has - with concrete requirements at each level.

IAM-03.3 · L3 - MCP and external tool calls authorized via OAuth-issued named scopes. Static API keys prohibited. Wildcard or catch-all scopes not permitted.

IAM-04.3 · L4 - Fine-grained scopes defined per operation (read vs. write, per-resource, per-action). Authorization policy expressed as code - Cedar, OPA/Rego, or equivalent - stored in version control, with a deny-by-default posture enforced at a policy-decision point such as an MCP server or gateway.

IAM-05.3 · L5 - The agent's declared task or user intent is evaluated at the decision point; actions outside that intent are denied. Stale permissions retire automatically.

If you're running MCP servers with broad static keys, the model tells you exactly which level that puts you at.

Prompt Injection Gets a Dedicated IR Playbook

Most IR teams today handle AI incidents exactly like any other application incident - generic triage, no AI-specific telemetry. The AISMM categorizes this as Level 1 for Incident Response.

Level 3 (IR-03.1) requires written playbooks covering named attack categories with deployment-type-specific containment branches: prompt injection, data exfiltration, model abuse, unauthorized usage, compromised agent credentials, tool/MCP misuse, and agent hijacking. A working majority must have been exercised within the trailing 12 months. Responders must hold pre-provisioned read access to telemetry, deployment configs, and provider consoles - no just-in-time provisioning during an active incident.

AI Supply Chain Risk Gets Serious Treatment

The AISMM dedicates a full practice area - AI Dev & Supply Chain Security - to what organizations largely treat as a footnote.

DEV-03.2 · L3 - AI libraries reach production only through an organization-managed package proxy (Artifactory, Nexus, etc.). Open or third-party models carry an integrity and safe-format record before first production use.

DEV-04.2 · L4 - An AI Bill of Materials (AI-BOM) is generated per release, covering models, AI libraries, MCP servers, and RAG data sources. Reconciled against runtime to catch drift and serves as the authoritative inventory consumed by Org Management and Risk Assessment.

DEV-05.2 · L5 - New vulnerabilities in AI-BOM components auto-correlate to produce a blast-radius list routed to the named owning team, triaged against a defined SLA. Abandoned AI libraries flagged for replacement before becoming a latent risk.

Illustrative Code

Agent Identity - OAuth 2.0 Token Exchange

The resulting token carries both sub (user) and act (agent) claims; the agent's scope is a strict subset of the user's.

# OAuth 2.0 Token Exchange (RFC 8693) - agent acting on behalf of a user
# The resulting token carries both `sub` (user) and `act` (agent) claims
# Agent scope must be a strict subset of what the user is authorized for

response = requests.post("https://auth.example.com/token", data={
    "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
    "subject_token": user_access_token,
    "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "scope": "read:documents",        # Narrower than the user's full scope
    "actor_token": agent_jwt,
    "actor_token_type": "urn:ietf:params:oauth:token-type:jwt",
})

Incident Response - Behavioral Envelope Monitoring

Flags tool calls outside an agent's sanctioned profile, rather than waiting for HTTP 500s.

# Behavioral envelope monitoring for agent tool usage
# Flag when an agent calls tools outside its sanctioned profile

SENSITIVE_TOOLS = {"delete_file", "send_email", "execute_code", "db_write"}
EXPECTED_TOOLS = {
    "customer-support-agent": {"search_kb", "create_ticket", "fetch_order"},
    "code-review-agent":      {"read_file", "list_directory", "post_comment"},
}

def detect_tool_abuse(agent_id: str, session_calls: list[str]) -> list[str]:
    expected = EXPECTED_TOOLS.get(agent_id, set())
    return [
        f"ALERT: {agent_id} called '{tool}' - outside sanctioned profile"
        for tool in session_calls
        if tool in SENSITIVE_TOOLS and tool not in expected
    ]

Model Provenance - Pinned Model Manifest

Floating aliases are prohibited at Level 3+; self-hosted models require cryptographic integrity verification at Level 4.

# Production model manifest - floating aliases are prohibited at Level 3+
model_config:
  provider: openai
  model: gpt-4o-2024-08-06        # Pinned. "gpt-4o" is not acceptable.
  fallback: claude-sonnet-4-20250514

# Self-hosted models require cryptographic integrity verification at Level 4
self_hosted:
  model_path: /models/llama-3-70b-instruct
  expected_sha256: "a3f1c9d2..."
  signing_key: "cosign/public-key.pem"
  load_policy: fail_closed_on_invalid_signature  # Never silently load an unverified model

MCP Authorization - Per-Agent Allowlist

Deny-by-default, with named scopes instead of static API keys or wildcards.

{
  "agent": "customer-support-agent",
  "mcp_servers": {
    "crm-mcp": {
      "allowed_tools": ["get_customer", "get_order_status"],
      "denied_tools":  ["delete_customer", "update_payment"],
      "scope": "crm:read"
    },
    "kb-mcp": {
      "allowed_tools": ["search_articles"],
      "scope": "kb:read"
    }
  },
  "default_action": "deny"
}

MCP Enforcement - OPA Policy Outside the Agent

Because the policy-decision point never sees the prompt, prompt injection cannot talk its way past it.

# OPA policy - runs outside the agent's reasoning, immune to prompt injection
package agent.tools

default allow = false

allow {
    allowed_tools[input.agent_id][input.tool_name]
}

allowed_tools := {
    "customer-support-agent": {"get_customer", "get_order_status", "search_articles"},
    "code-review-agent":      {"read_file", "list_directory", "post_comment"},
}

What Levels 4 and 5 Actually Look Like

Automated Discovery Is Mandatory at Level 4

Manual AI inventory is not a viable strategy at scale. Level 4 (ORG-04.2) requires automated AI discovery across cloud environments and managed endpoints - covering AI services, model endpoints, agents, MCP servers, and AI-enabled SaaS features - using CSPM/CNAPP with AI awareness, EDR endpoint visibility, CASB, and dedicated AI-SPM products. Discovered assets are auto-reconciled to a named owning team.

At Level 5 (ORG-05.1), technical controls enforcing organizational AI policies are managed as code in version control - SCPs, Azure Policy, GCP Organization Policy, OPA rules, and Cedar policies for agents and MCP servers - deploying via CI/CD with staged rollout and exercised rollback.

Behavioral Baselines Underpin Everything at Level 5

Threat detection without baselines produces noise. Level 4 (MON-04.2) requires AI-specific detection content that fires on deviation from baselines computed from observed telemetry - not static thresholds - spanning prompt injection, sensitive-data exfiltration, anomalous agent action sequences, abnormal delegation depth, and cost anomalies, all triaging through the primary SOC queue.

Level 5 (MON-05.1) requires defined high-severity AI events to trigger atomic automated SOAR responses within minutes: session termination, credential revocation, deployment throttling, or circuit-break shutdown. Level 5 (IR-05.2) adds tamper-evident, indexed agentic telemetry - prompts, tool I/O, context checkpoints, delegation and memory events - reconstructible on demand, validated by a quarterly forensic drill.

Compliance Automation Arrives at Level 4

Level 4 (CMP-04.1) requires compliance evidence to collect automatically from source telemetry and bind to each entry in the AI deployment registry, covering guardrail coverage, personal-data handling, access controls, and model-registry conformance. AI-CAIQs for major external-facing deployments generate from the same pipeline.

Level 5 (CMP-05.3) adds a regulatory-intelligence feed that catches AI rule changes across all operating jurisdictions - EU AI Act phased implementation, US state AI laws, sector-specific regulator guidance - routing each to a tracked impact assessment within defined SLAs.

The Governance Question Nobody Wants to Answer

Precise Escalation Across Levels

Governance is the first practice area in the AISMM for good reason. Without it, everything else is informal. The escalation across levels is precise.

GOV-04.2 · L4 - No high-risk AI use case reaches production without a cross-functional ethics and safety review producing a written go / go-with-conditions / no-go disposition. References EU AI Act Article 9 (risk management system) and Article 14 (human oversight).

GOV-04.3 · L4 - Executive and board members actively engaged with the AI Council, signing off on governance policies and receiving regular reporting with defined escalation triggers.

GOV-05.2 · L5 - A standing AI ethics review board has and demonstrably exercises enforcement authority - halting, modifying, or remediating production AI deployments.

Programs, Not Policies

The AISMM measures programs, not policies. Not "has the authority to halt a deployment." Has actually done it.

The Data Security Detail Most Programs Miss

Permission-Aware Retrieval at Level 4

At Level 4, the AISMM introduces permission-aware retrieval (DAT-04.1): RAG applications retrieving from access-controlled sources must filter results against the requesting user's entitlements before content reaches the model. Filtering happens at the vector layer using ACLs captured at ingestion. The retrieval layer fails closed when permission sync breaks.

Data Poisoning Detection at Level 5

At Level 5 (DAT-05.2), training data, fine-tuning data, and production RAG content are scanned for poisoning and adversarial patterns on ingestion and on material update - covering embedded prompt-injection payloads, embedding-space distribution shifts, and matches against an AI-specific threat-intelligence feed.

Most programs think about data security for AI in terms of "don't put PII in the prompt." That's Level 2 thinking.

How to Use This

Start With an Honest Self-Assessment

The AISMM doesn't tell you which tools to buy. It tells you what capability you should have, and when that capability becomes expected. The most useful starting point is an honest self-assessment - not "do we have a policy for this" but "can we demonstrate this control objective with evidence."

Where Organizations Most Consistently Overestimate Themselves

IAM for non-human identities - the gap between "we use service accounts" and per-agent federated identities with managed credential lifecycle.

IR for AI-specific threats - the gap between "we extended our existing runbooks" and exercised, AI-specific playbooks with pre-provisioned responder access.

Security Monitoring - specifically the gap between "we have logs" and baseline-derived AI threat detection running through the SOC at standard cadence.

The Bottom Line

The AISMM is the most practically structured framework available for measuring enterprise AI security maturity. Each of its 12 practice areas carries numbered control objectives, AICM mappings, and NIST/OWASP/MITRE ATLAS cross-references. It reflects real operational functions, escalates with precision across levels, and gives security teams something concrete to show leadership when explaining why "we have a policy" and "we have a program" are not the same sentence. Teams working through this progression often lean on outside help; that is the focus of our AI security services. Executive teams that want a facilitated walk-through of the model against their own program can start with our AI strategy workshop.

Download the AISMM here, free: cloudsecurityalliance.org/artifacts/ai-security-maturity-model