CSA AI Controls Matrix (AICM): Control Domains for Agent Governance (2026)

When the Cloud Security Alliance shipped the AI Controls Matrix (AICM) on July 10, 2025, it did something most AI frameworks at the time did not: it gave security teams a concrete, auditable control set rather than another set of principles. AICM defines 243 control objectives across 18 domains, and because it is built on top of CSA's widely deployed Cloud Controls Matrix (CCM), it slots into governance programs that already speak the CCM dialect of IAM, AIS, GRC, and LOG.

For teams wrestling with autonomous AI agents and Model Context Protocol (MCP) servers, AICM matters for a specific reason: it is one of the few mainstream control frameworks that names agentic AI explicitly. Two controls in particular, AIS-11 (Agents Security Boundaries) and IAM-19 (Agent Access Restriction), speak directly to the problem of over-privileged, loosely scoped agents reaching tools and data they were never meant to touch. This guide walks through what AICM is, its actual structure, how its domains map onto agent and MCP risk, and how a security team operationalizes it without drowning in 243 line items.

What AICM is (and what it isn't)

AICM is a vendor-agnostic AI security and governance control framework published by CSA. Its job is to help organizations build, deploy, and operate AI systems, especially generative AI and LLM systems, securely and responsibly. Version 1.0 was released on July 10, 2025.

It is important to be clear about what AICM is not. It is not a threat taxonomy like MITRE ATLAS, and it is not a scoring model. It is a control catalogue: a structured list of what good looks like, against which you assess coverage. In the CSA ecosystem it functions as the control backbone for assurance, the way CCM does for cloud.

AICM ships with companion artifacts that make it operational rather than aspirational:

• The AI Consensus Assessment Initiative Questionnaire (AI-CAIQ) for self-assessment and third-party vendor evaluation.
• Implementation guidelines describing how to satisfy each control, addressed to the GenAI service roles in CSA's shared-responsibility taxonomy.
• Auditing guidelines for assessors validating control coverage across the AI lifecycle.
• Crosswalk mappings to other frameworks so one control set serves several regimes.

The structure: 18 domains built on CCM

AICM does not reinvent the wheel. CCM has 197 control objectives across 17 domains; AICM inherits those 17 domains and their short codes, then adds one genuinely new AI-specific domain: Model Security (MDS). AI-specific control objectives are also woven into the inherited domains rather than bolted on as a separate appendix. If your GRC team already maps controls to CCM codes, the lift to adopt AICM is incremental, not a rebuild.

The 18 domains and their codes:

How controls are characterized

Each control objective is not a flat statement. AICM characterizes controls along multiple dimensions so you can filter the matrix to your situation:

• Architectural relevance: physical, network, compute, storage, application, and data layers.
• AI lifecycle relevance: from data preparation through to model retirement.
• Threat categories: including model poisoning, prompt injection, model theft, and sensitive data disclosure.

This multi-axis tagging is what lets a CISO say "show me the controls relevant to the application layer that address prompt injection during inference" rather than reading all 243 objectives top to bottom.

How AICM maps to AI agents and MCP servers

Most frameworks treat AI as a monolithic model you call. Agents are different: they hold an identity, make autonomous decisions, and invoke tools, increasingly MCP servers, on their own. That autonomy is exactly where AICM's agentic controls earn their place. If you are new to why this layer is so exposed, our explainer on why AI agents and MCP servers are the new shadow IT sets the scene.

The two named agentic controls

AIS-11 (Agents Security Boundaries) is about constraining what an autonomous agent can do and reach. An agent that can call any tool, hit any endpoint, and chain actions without a boundary is the textbook definition of excessive agency. AIS-11 is the control that says: draw the box, and keep the agent inside it.

IAM-19 (Agent Access Restriction) is about identity and privilege. Every AI agent and MCP server should have a distinct, attributable identity with least-privilege scoping, not a shared service account or, worse, a human's credentials. CSA frames the control around task-based tool access, scoping actions to an agent's assigned objective or workflow stage, and integrating agent access decisions with existing IAM. The gap most orgs have here is structural: shadow agents and MCP servers that authenticate as a developer leave no way to tell who, or what, actually performed an action.

The supporting domains

The agentic story does not stop at two controls. Several inherited domains carry direct weight for agents and MCP:

The AIS and STA mappings are where the most common attack path lives. An agent calling an untrusted MCP server is, in AICM terms, an interface-security failure (AIS) feeding a supply-chain risk (STA). This is not theoretical, our analysis of an MCP tool poisoning campaign shows hidden instructions in tool descriptions crossing exactly that boundary, and the broader pattern is covered in our MCP server security guide.

The honest caveat

AICM is GenAI/LLM-centric, and CSA itself notes that traditional ML systems may need additional interpretation. More importantly for agent teams: AIS-11 and IAM-19 are a small, emerging subset of the 243 controls. AICM does not yet provide a deep, standalone agentic control set comparable to a dedicated agent threat model.

The practical implication is to pair AICM with agent-specific guidance such as OWASP's agentic security work and the MAESTRO threat-modeling approach. Use AICM as the governance and assurance spine; use the agent-specific frameworks to enumerate the autonomous-tool-use attack surface in depth. They are complementary, not competing.

Operationalizing AICM for an agent fleet

A 243-control matrix is daunting if you treat it as a checklist to satisfy in one pass. For agentic AI, a more useful sequence is scope first, then assess, then close gaps, then prove it.

1. Scope and inventory

Nearly every agentic control assumes you already know what exists. IAM-19 cannot restrict an agent's access if you do not know the agent is running. STA cannot vet an MCP server you have never inventoried. So the first move is a continuous, attributed inventory of every AI agent and MCP server across the fleet, including the ones developers stood up locally. When we run this exercise, the findings are consistent with what we documented in what we find when we scan AI agent configs: undeclared MCP servers, agents on shared credentials, and tools nobody approved.

2. Map controls to your environment

Use the multi-axis tagging to filter AICM down to what applies. For an agent fleet, that core set is typically IAM, AIS, MDS, DSP, STA, LOG, plus GRC and A&A for governance. Assess each against your current state using the AI-CAIQ questionnaire, which doubles as a way to evaluate third-party vendors whose agents or MCP servers you consume.

3. Close gaps with enforcement

Translate control objectives into enforcement. For IAM-19, that means issuing distinct identities and least-privilege scopes per agent. For AIS-11, defining and enforcing what each agent may reach. Coding assistants are a high-priority slice here, since they sit on developer machines with broad local access, covered in securing AI coding agents and CLIs and at fleet scale in governing AI coding assistants across your fleet.

4. Produce assurance evidence

Because AICM is mapped to BSI AIC4, NIST AI 600-1, ISO/IEC 42001:2023, and the EU AI Act (the ISO/IEC 42001 and EU AI Act mappings released in August 2025), evidence you gather once can satisfy several regimes. It is also the control backbone for STAR for AI, CSA's assurance program offering Level 1 self-assessment and Level 2 third-party audit, launched October 23, 2025 (Level 2 became available in November 2025). The A&A and GRC domains are where you maintain the inventory, demonstrate coverage, and assemble audit evidence.

Where continuous agent and MCP visibility fits

Read the agentic controls closely and a pattern emerges. IAM-19 presumes you can attribute every agent identity. STA presumes you have a list of every MCP dependency. LOG presumes you are capturing agent and MCP behavior continuously enough to spot a deviation. AIS-11 presumes you know where each agent's boundary should sit. Every one of these is downstream of a single capability: knowing, at any moment, which agents and MCP servers exist, what identities they carry, what they can reach, and how they are behaving.

This is the category Anomity works in. We discover and inventory every AI agent and MCP server on the endpoint and across the fleet, attribute each to an identity, monitor permissions and behavior, alert on anomalies, and produce the audit trail. In AICM terms that is the data layer beneath IAM-19, STA, LOG, and A&A. You can read how the discovery side works in inside Anomity discovery. The framing is deliberately simple, and it is the same principle that animates AICM's logging and assurance domains: you can't govern what you can't see.

AICM gives security leaders something the agentic space badly needed, a credible, mappable, auditable control set with the CSA assurance ecosystem behind it. Treat its agentic controls as the start of an agent governance program rather than the whole of one, ground it in a real-time inventory of your agents and MCP servers, and pair it with agent-specific threat modeling. Do that, and the 243 controls stop being a checklist and become a working operating model for the fleet of autonomous software now running inside your org.