CSA AICM AI Controls Mapping: 18 Domains and Four Owners Against One HTTPS Request

The AI Controls Matrix tags every one of its 243 control objectives with an owner. That owner is the cloud provider, the model provider, the orchestrated service provider, or the application provider, and the Cloud Security Alliance built that dimension in when it released the framework on 10 July 2025 because AI supply chains run four parties deep and assurance conversations kept stalling on whose control failed.

Ownership is the dimension that makes an AICM mapping useful and the one most mapping exercises drop. A spreadsheet row reading "Model Security: covered by our model provider's SOC 2" answers the domain and leaves the application provider's half of the split unaddressed. I want to set out, domain by domain, which control an enterprise in the application provider role has to run itself, and where in the request path it fires.

The control point: one HTTPS request

Every mapping below resolves to the same moment: an HTTPS POST carrying a context window to a model endpoint. That request is where identity is known, where classification is evaluable, where the destination is selected, and where a decision is recorded or lost. It also happens to be the exact seam between the application provider and the model provider in the AICM's ownership model, which is why so many objectives land on it.

Identity and Access Management

The IAM domain asks whether access to resources is granted to authenticated principals under least privilege. For AI traffic the resource is a model endpoint and the principal is frequently a service account. The control is identity binding at the boundary, carrying the end user or agent identity into the policy decision rather than collapsing everyone into one API key. The evidence is an identity-bound per-request record, and the architecture is described in identity-aware AI gateway architecture.

Data Security and Privacy Lifecycle Management

The DSP domain governs classification, handling, and movement of regulated data. AI creates a data object with a lifespan of one API call, assembled from several stores into a context window nobody classified as a unit. The control is prompt-level classification evaluated before transmission, tied to per-role policy so a caller whose role lacks a basis for health data gets blocked. The evidence is a per-request classification decision and the policy decision recorded against it.

Model Security

Model Security is the domain with no Cloud Controls Matrix ancestor, and it carries the AICM threat categories covering model manipulation, data poisoning, and prompt-based attacks. An application provider consuming a hosted model controls the input and the handling of the output rather than the weights. The control is inspection and policy on both directions of traffic, with the model and version stamped onto each decision. The evidence is a request and response record joined to the model version that served it.

Supply Chain Management, Transparency and Accountability

The STA domain asks who is in the chain and what each party is accountable for. Enforcement takes the form of destination-aware routing with an allowlist, so a request reaches an approved endpoint or fails closed. The evidence is a destination log naming every model endpoint actually called during the period, which is the artifact that reconciles a vendor inventory against production and routinely finds endpoints nobody registered.

Logging and Monitoring

The LOG domain asks whether security-relevant events are recorded, protected, and reviewed. For AI the demanding property is custody. The control is write-path independence, meaning the record is produced by a system the application making the call has no ability to modify. The evidence is an externally written, signed log, and the reasoning is set out in AI audit log immutability.

Governance, Risk and Compliance

The GRC domain covers policy, risk treatment, and external obligation tracking. For AI the control is a policy decision point that renders written policy executable at the request boundary, with versioned policy state attached to each decision. The evidence is a per-request policy decision record, which is what turns an approved AI usage policy into something an assessor can test rather than read.

Security Incident Management and Threat and Vulnerability Management

The SEF and TVM domains activate around incidents. Reconstructing an AI-channel exposure means answering which prompts carrying which classifications reached which endpoints during a window. The control is the same independent request log every row above produces, retained long enough to cover the investigation. The evidence is a reconstructable timeline, which is what an AI incident response playbook depends on existing before the incident.

The mapping at a glance

The lifecycle and threat dimensions change scope, not controls

Each objective is also tagged to a lifecycle stage from preparation through service retirement, and to one of nine threat categories. Assessors use both to scope an engagement, which means the same seven controls above get examined repeatedly under different headings. Building them once and presenting them against several tags is the pattern that survives a STAR for AI assessment without duplicating engineering work.

My frank opinion: the AICM's most quietly demanding requirement is service retirement. When a model version is decommissioned, the records covering requests it handled still have to be retrievable and still have to name the version, and I have yet to see a team instrument that before an assessor asks.

DeepInspect

Each row above resolves to an enforcement point, and DeepInspect is that point. It sits inline between your users or agents and the LLM APIs they call, evaluates identity, classification, and destination on every request, enforces per-role and per-route policy with a fail-closed default, and writes a signed record of the decision before the response returns. The AICM mapping stops being a spreadsheet with an owner column and becomes a running control with evidence attached.

For an application provider preparing a STAR for AI self-assessment, that means the IAM, DSP, STA, and LOG rows have a per-decision record standing behind them rather than a description. The AICM audit evidence view covers what each artifact looks like under assessment. Book a technical deep dive at deepinspect.ai.