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.

Control Objectives and Deployment Types

Each practice area carries numbered control objectives - for example GOV-03.1 or IAM-04.2. These map to the CSA AI Controls Matrix (AICM). Cross-references point to the NIST AI RMF, OWASP's LLM security work, and MITRE ATLAS.

CSA also tags every control objective with a deployment type: self-hosted, PaaS, or API/SaaS. PaaS covers provider-managed infrastructure like Bedrock or Azure OpenAI. A team running only API-based AI can filter the model to what actually applies. There's no need to assess against controls written for a self-hosted model it will never run.

The Levels Are Qualitative

CSA describes the levels as qualitative, not quantitative. There's no percentage of deployments that unlocks a level. The control objectives work as representative KPIs. They indicate an organization is likely at a given level - they aren't a scored checklist. Meeting one is evidence, not proof, and CSA is explicit that the list is representative rather than exhaustive.

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.

Why Maturity Isn't a Single Score

CSA doesn't publish data on where organizations actually land, and neither do we. What we see, working with engineering teams, is unevenness across categories rather than one clean number.

A team can have solid IAM for AI workloads and still have no written incident response playbook for prompt injection. A product group running agents in production is often ahead of a business unit that just turned on Copilot. Both can sit inside the same company.

CSA's own guidance expects this. Different parts of a program will sit at different levels. Different categories can reasonably target different levels depending on risk. The useful exercise isn't landing on one score. It's finding where the gaps actually sit, category by category.

Why the Jump From Level 2 to Level 3 Matters

The jump from Level 2 to Level 3 is where real risk concentrates. At Level 2, you have policies and a spreadsheet of providers. At Level 3, something structurally different exists.

The Level 3 Control Objectives That Trip Teams Up

These are representative Level 3 control objectives, not the complete list, but they capture where teams most often fall short.

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's not an incremental improvement. That's 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 doesn't cascade across the AI estate.

IAM-04.1 · L4 - Per-agent identities federated to the enterprise IdP or established via attestation.

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

The framework names implementation patterns for each deployment type as illustrative approaches, not a mandated product list. Examples include SPIFFE/SPIRE for self-hosted agents, and provider-native primitives like managed identities or per-agent service accounts for PaaS agents.

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, using an approach like Cedar or OPA/Rego, stored in version control, enforced deny-by-default at a policy-decision point such as an MCP 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 behind broad static keys, this model tells you exactly which level that puts you at.

Prompt Injection Gets a Dedicated IR Playbook

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

Level 3 (IR-03.1) requires written playbooks covering named attack categories with deployment-specific containment branches. A working majority should have been exercised within the trailing 12 months. Responders need pre-provisioned read access to telemetry, deployment configs, and provider consoles - not just-in-time provisioning during an active incident.

AI Supply Chain Risk Gets Serious Treatment

The AISMM dedicates a full practice area to AI Dev & Supply Chain Security. Many organizations still treat this as a footnote.

DEV-03.2 · L3 - AI libraries reach production only through an organization-managed package proxy. 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, and reconciled against runtime to catch drift.

DEV-05.2 · L5 - New vulnerabilities in AI-BOM components auto-correlate to a blast-radius list, routed to the owning team and triaged against a defined SLA.

What This Actually Changes for a Security Engineer

Moving from Level 2 to Level 3 isn't mainly about writing more policy. It's about giving policy technical teeth.

A written AI use policy is a starting point. A deny-by-default authorization layer enforces it at a gateway, not inside the agent's own reasoning. That's what separates policy from enforcement. Prompt injection can talk an agent out of following instructions. Because authorization is enforced outside the agent's reasoning, it cannot directly override that policy engine's decision.

That distinction matters most for identity. Most organizations already run working IAM for human users. Far fewer have equivalent lifecycle management for the machine identities an AI program creates continuously. Extending existing IAM patterns to non-human identities is usually faster than building a parallel system from scratch.

Why AI Inventory Gets Hard Fast

Multi-cloud makes AI discovery harder than it sounds. A model endpoint in one cloud, an agent framework in another, an AI feature quietly enabled in a SaaS tool. These rarely land in one inventory.

Traditional CMDBs weren't built to track model versions, agent-to-tool permission scopes, or MCP server connections. That's the practical reason Level 4 discovery leans on CSPM/CNAPP tooling with AI awareness, plus CASB and AI-SPM products. A manually maintained spreadsheet can't keep pace.

Automated discovery isn't a nice-to-have at scale. It's the only way the registry stays accurate as new deployments show up weekly.

Illustrative Code

The examples below illustrate one way to implement the patterns the AISMM describes. They're not prescribed by the framework - they're working patterns SiegePal uses to explain the concepts to engineering teams.

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.

python

# 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.

python

# 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

One example of how floating aliases can be avoided and self-hosted models cryptographically verified.

yaml

# Example production model manifest - avoids floating aliases
model_config:
  provider: openai
  model: gpt-4o-2024-08-06        # Pinned. "gpt-4o" is not acceptable.
  fallback: claude-sonnet-4-20250514

# Self-hosted models can require cryptographic integrity verification
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.

json

{
  "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 authorization is enforced outside the agent's reasoning, prompt injection cannot directly override the policy decision.

rego

# OPA policy - authorization runs outside the agent's reasoning
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 doesn't hold up at scale. Level 4 (ORG-04.2) calls for automated AI discovery across cloud environments and managed endpoints. This covers AI services, model endpoints, agents, MCP servers, and AI-enabled SaaS features. Discovery tooling includes CSPM/CNAPP with AI awareness, EDR visibility, CASB, and dedicated AI-SPM products. Discovered assets reconcile to a named owning team.

At Level 5 (ORG-05.1), the technical controls enforcing AI policy are managed as code in version control. This includes cloud org policies, OPA rules, and Cedar policies for agents and MCP servers. They deploy through CI/CD with staged rollout and exercised rollback.

Behavioral Baselines Underpin Everything at Level 5

Threat detection without baselines mostly produces noise. Level 4 (MON-04.2) calls for AI-specific detection content that fires on deviation from telemetry-derived baselines, not static thresholds. It spans prompt injection, data exfiltration, anomalous agent action sequences, and cost anomalies.

Level 5 (MON-05.1) requires high-severity AI events to trigger automated response within minutes - session termination, credential revocation, deployment throttling. Level 5 (IR-05.2) adds tamper-evident agentic telemetry, reconstructible on demand and checked by a quarterly forensic drill.

Compliance Automation Arrives at Level 4

Level 4 (CMP-04.1) calls for compliance evidence to collect automatically from source telemetry. It binds to each entry in the AI deployment registry, covering guardrail coverage, personal-data handling, and access controls.

Level 5 (CMP-05.3) adds a regulatory-intelligence feed tracking AI rule changes across operating jurisdictions. Each change routes to a tracked impact assessment within a defined SLA.

The Governance Question Nobody Wants to Answer

Governance sits first in the AISMM for good reason. Without it, everything downstream stays 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 decision.

GOV-04.3 · L4 - Executive and board members actively engage with the AI Council, signing off on governance policy and receiving regular reporting.

GOV-05.2 · L5 - A standing AI ethics review board holds, and demonstrably exercises, authority to halt, modify, or remediate production AI deployments.

The distinction that matters: the model measures programs, not policies. Not "has the authority to halt a deployment." Has actually done it.

The Data Security Detail Most Programs Miss

At Level 4, the AISMM introduces permission-aware retrieval (DAT-04.1). RAG applications pulling 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 access rules captured at ingestion. The retrieval layer fails closed when permission sync breaks.

At Level 5 (DAT-05.2), training data, fine-tuning data, and production RAG content get scanned for poisoning and adversarial patterns. This happens on ingestion and material update, covering embedded prompt-injection payloads and embedding-space shifts.

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

How to Use This

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

Three Areas Worth Examining Closely

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 runbooks" and exercised, AI-specific playbooks with pre-provisioned responder access.
Security Monitoring - the gap between "we have logs" and baseline-derived AI detection running through the SOC at standard cadence.

The Bottom Line

The AISMM is a genuinely useful structure for measuring enterprise AI security maturity. Its twelve practice areas carry numbered control objectives, AICM mappings, and cross-references to NIST, OWASP, and MITRE ATLAS. It reflects real operational functions and escalates with precision across levels.

What it won't do is hand you a single score. Maturity varies by category, and CSA designed the model expecting that. The value is in finding where your program's gaps actually are. Build the roadmap around evidence, not assumptions.

Teams working through this progression often want outside help; that's the focus of our AI security services. Executive teams wanting a facilitated walk-through against their own program can start with our AI strategy workshop.

Download the AISMM directly from the Cloud Security Alliance: cloudsecurityalliance.org/artifacts/ai-security-maturity-model.