CSA AI Controls Matrix for LLM Deployments
Written by Jakub Rusinowski · Last updated 2026-09-13 · Assessment logic is deterministic and runs in your browser
This section is practitioner guidance on deployment and governance mechanics, not legal advice. Regulatory classification turns on facts about intended purpose and real-world use that a questionnaire cannot establish — involve your counsel or DPO for decisions about your specific obligations.
The Cloud Security Alliance AI Controls Matrix is a control framework for securing and governing AI systems, built in the lineage of CSA's Cloud Controls Matrix. CSA describes AICM v1.1 as comprising 247 control objectives across 18 security domains, with published mappings to major AI governance frameworks including ISO/IEC 42001, ISO/IEC 27001 and the EU AI Act. It is the framework in this set that addresses AI-specific attack surface most directly.
CSA AICM Voluntary framework — no obligation, no certification
- Version 1.1
- Publisher Cloud Security Alliance
- Last verified 2026-09-13
A control framework for securing and governing AI systems, built in the lineage of CSA's Cloud Controls Matrix. CSA describes AICM v1.1 as comprising 247 control objectives across 18 security domains, with published mappings to the major AI governance frameworks including ISO/IEC 42001, ISO/IEC 27001 and the EU AI Act.
What this tool does not do
- CSA publishes AICM under its own terms. This repository stores control identifiers, our own short descriptions and mapping metadata — not CSA's control text.
- We map a deliberately small subset of AICM relevant to single-deployment LLM inference. The full matrix is far broader, covering model development and cloud-provider responsibilities this tool does not assess.
- AICM is not an audit standard and confers no certification.
Why AICM is in this set at all
The other five frameworks here were either written before the current generation of AI deployment patterns, or written about something other than security. AICM was written for this, and it shows in the places the others have gaps:
- Model and inference security as a domain in its own right, rather than as an awkward extension of application security.
- AI supply chain, which for most readers of this site means: where did these weights come from, is the artefact you are running the artefact you intended, and what do you know about what went into it.
- Model lifecycle — inventory, versioning, retirement — which is the operational substrate under every documentation obligation in every other framework.
The gap it fills most usefully is the one recorded as a structural gap on our ISO/IEC 27001 page: the 2022 Annex A control set has nothing addressing prompt injection, and forcing a mapping onto secure coding would tell a reader they are covered when they are not.
What this tool stores, and what it does not
AICM is published by CSA under its own terms. This repository stores, for each mapped control:
- the control identifier or domain as CSA publishes it,
- a short description in our own words of what the control objective is about,
- the mapping metadata — relationship type, confidence, rationale, last-verified date,
- a link to the official source.
It does not store CSA's control text. That is a licensing position, and it is enforced by the shape of the type rather than by a reviewer noticing: FrameworkMapping has no field capable of holding verbatim control text. If you need the actual objectives, get them from CSA — the link is on the card above.
The same rule applies to ISO and AICPA material, for the same reason.
One more limitation worth stating plainly: we map a deliberately small subset of AICM. The full matrix spans model development and cloud-provider responsibilities that a single-deployment assessment has no view of. Our subset is the part that a team running inference on their own hardware can actually act on.
The AI-specific controls a self-hosted deployment usually misses
From the domains AICM covers, four recur as gaps in real deployments and none of them are exotic:
Untrusted content in the context window. A retrieval system reads documents it does not control. Those documents can contain text aimed at the model. The control is not to filter the documents — that is an arms race you lose — it is to constrain what the model is *able* to do with whatever it reads: separate instructions from retrieved content, scope tool permissions narrowly, and never let retrieved text widen them.
Output treated as trusted. Model output that is rendered as markup, executed, or passed to another system is an injection sink. Validate it against an expected shape before anything acts on it.
The retrieval corpus as an access-control boundary. An index frequently ends up containing material with broader access than the index itself has, turning the assistant into a query interface over documents its users could not otherwise open. Access control belongs on the retrieval layer, not only on the endpoint.
Model artefact provenance. You downloaded a GGUF from somewhere. Do you know the file you are running is the file you intended? Checksums exist for this, and almost nobody checks them.
Deployment controls that relate to AICM domains
Domain identifiers with our own descriptions, per the licensing position above. This is a subset of AICM scoped to single-deployment LLM inference — the full matrix is substantially broader.
AI risk management process CTL-RISK-001
A documented, iterative process that identifies the risks this AI system poses to health, safety and fundamental rights, estimates them against the intended purpose and reasonably foreseeable misuse, and records the mitigations adopted. Reviewed on a schedule and after material change, not written once.
GRC domain — Partial · medium confidence
Governance, risk and compliance control objectives for AI systems
AICM's governance domain covers AI risk identification and treatment among a broader set of control objectives. Partial because AICM addresses the security posture of the AI system alongside governance, and only part of that overlaps with a fundamental-rights risk assessment.
Last verified 2026-09-13
Human oversight of AI output CTL-OVERSIGHT-001
A named human role that can understand the system's output and limitations, decide not to use it, and override or reverse it — with the authority and the time to actually do so. Oversight is a staffed procedure, not a checkbox in a UI.
HRO domain — Partial · medium confidence
Human oversight and responsible-use control objectives
AICM addresses human oversight within its governance and responsible-use objectives. Partial because AICM's treatment is oriented to AI service security rather than to fundamental-rights protection.
Last verified 2026-09-13
Input and reference data governance CTL-DATA-001
Know what data reaches the model and whether it is fit for the purpose: where it came from, whether it is relevant and sufficiently representative for the people the system is used on, what is excluded, and how errors and gaps are handled. For a retrieval system this covers the corpus, not just the prompt.
DSP domain — Partial · medium confidence
Data security and privacy lifecycle control objectives
AICM's data domain covers classification, handling and protection of data in AI systems. Partial: it addresses protecting data rather than assessing whether the data is representative of the population the system is used on.
Last verified 2026-09-13
Personal data handling in the inference path CTL-PRIVACY-001
Establish the lawful basis, the data minimisation position and the retention rule for personal data that enters prompts, retrieval context or logs. Inference logging is the common failure: a system designed not to store personal data often stores it anyway, in the log.
DSP domain — Strong · medium confidence
Data security and privacy control objectives
AICM addresses privacy of data handled by AI systems within its data domain.
Last verified 2026-09-13
Inference and audit logging CTL-LOGGING-001
Record what the system was asked, what it answered, which model version answered, who was involved and when — to a retention period you chose deliberately. For high-risk systems the deployer must keep the automatically generated logs.
LOG domain — Strong · medium confidence
Logging and monitoring control objectives for AI systems
AICM carries logging and monitoring objectives adapted to AI services.
Last verified 2026-09-13
System and model documentation CTL-DOC-001
A record of what is deployed: the model and its exact version, the quantisation and serving stack, the hardware, the configuration, the known limitations, and the intended purpose. This is the document every other control cites.
Model lifecycle domain — Strong · medium confidence
Model inventory, versioning and lifecycle documentation objectives
AICM includes model inventory and lifecycle documentation among its control objectives.
Last verified 2026-09-13
Access control and network isolation for the inference endpoint CTL-SEC-001
Authenticate and authorise every caller of the model endpoint, and place the endpoint where only intended callers can reach it. An internal model server on an open port is a data-exfiltration path with a chat interface.
IAM domain — Direct · high confidence
Identity and access management control objectives for AI services
AICM carries identity and access management objectives adapted to AI service endpoints.
Last verified 2026-09-13
Prompt injection and output handling CTL-MODELSEC-001
Treat model output as untrusted input to whatever consumes it. Where the model reads attacker-influenceable content — retrieved documents, user uploads, web pages — assume that content contains instructions aimed at the model, and constrain what the model is able to do about them.
AI model security domain — Strong · medium confidence
Control objectives specific to model and inference security
AICM is the framework in this set that addresses AI-specific attack surface most directly, which is why it is here at all.
Last verified 2026-09-13
Assess a specific deployment
The generic answer is on this page. The specific one depends on what your system is for, who it affects and what it decides — which is what the assessment asks about.
Automated assessment based on the information you provide. Not legal advice, certification or an audit.