CSA AICM AI Audit Evidence: What a STAR for AI Assessment Asks You to Produce

The Cloud Security Alliance published the AI Controls Matrix on 10 July 2025, carrying 243 control objectives across 18 security domains. Each objective is analyzed along five dimensions: control type, applicability and ownership, architectural relevance across the generative AI stack, relevance to a lifecycle stage from preparation through service retirement, and threat category across nine categories including model manipulation and data poisoning. CSA's STAR for AI assurance programme runs against it, with the Level 1 self-assessment arriving as a CAIQ for AI at the end of 2025.

The ownership dimension is what makes AICM evidence different from every other framework I work with. A single control objective can sit with the cloud provider, the model provider, the orchestrated service provider, or the application provider, and the assessment asks which one you are before it asks what you have. I want to walk what an assessor actually requests from an enterprise sitting in the application provider role, because that is where most readers of this sit and the artifacts land squarely in the request path.

The identity record (Identity and Access Management)

The IAM domain carries forward from the Cloud Controls Matrix and gains weight in an AI context, because the caller of a model endpoint is frequently a service account standing in for a person or an agent. An assessor asks for the record binding a named principal to a specific inference request.

Most deployments cannot produce it. The application authenticates the user with a JWT, then calls the model with one API key that carries no user context, so the identity the IAM controls depend on gets dropped one layer before the request leaves. Closing that is the post-authentication gap in AICM terms.

The data record (Data Security and Privacy Lifecycle Management)

The DSP domain asks where regulated data lives, how it is classified, and how it moves. AI traffic creates a data object that exists for the duration of one API call: the context window, assembled from several stores into a payload no catalogue ever classified as a unit.

The artifact that satisfies a DSP review is a per-request classification of prompt content evaluated before transmission, alongside the destination endpoint and its region. Document-level labels inherited from a source system answer a different question, which is why prompt-level DLP is the control that produces this evidence.

The model record (Model Security)

Model Security is the domain with no CCM ancestor, and it is where the AICM's threat categories bite: model manipulation, data poisoning, and prompt-based attacks. For an application provider consuming a hosted model, the testable evidence is what reached the model and what came back.

That means a request and response record showing the input, the applied policy, the model and version, and the output classification. Model provider assurance documents cover the provider's own controls and stop at the API boundary, which leaves the application provider's half of the split unevidenced without a record on your side.

The supply chain record (Supply Chain Management, Transparency and Accountability)

The STA domain asks who is in the chain and what each party is accountable for. An AI application chain routinely runs four deep: cloud provider, model provider, an orchestration layer, then your application. An assessor asks for the inventory and then for proof the inventory matches production.

Traffic answers that. A destination log naming every model endpoint actually called during the period is the artifact, and it regularly surfaces endpoints nobody put in the inventory. That gap is the same one behind shadow AI discovery, arriving under a supply chain heading.

The logging record and its independence

Logging and Monitoring carries into the AICM from the CCM, and AI raises the stakes on one property: who wrote the log. An application that makes the AI call and also writes the compliance record is attesting to itself. That record breaks in three ways: the application logs its successes and misses its edge-case failures, the log can be modified by the same system that failed, and a crash between the model response and the log commit leaves the action taken with the evidence gone. I set this out in You Own the AI Liability, Not the Vendor.

The lifecycle dimension nobody instruments

Each AICM objective is tagged to a lifecycle stage running from preparation through service retirement, and assessors use that tagging to scope. Retirement is the stage teams skip. When a model version is decommissioned or a route repointed, the evidence covering requests handled by the old configuration still has to be retrievable and still has to say which version handled them.

My candid view: the AICM's ownership dimension is the most useful thing CSA has published on AI, because it forces a question most assurance conversations avoid, which is whose control failed when a prompt carrying customer records reached a third-party endpoint. Four parties in the chain and one API key between them is how that question ends up unanswerable.

DeepInspect

This is the evidence layer an AICM assessment reaches for on the application provider side. DeepInspect sits inline between your users or agents and the LLM APIs they call. For every request it evaluates identity, data classification, and destination, enforces per-role and per-route policy, then writes a signed, tamper-evident record before the response returns. The record holds the caller, the classification in the prompt, the model endpoint and version, the policy decision, and the response.

When a STAR for AI assessor asks which principal sent regulated data to which model on a given date, the answer is a query against records the application never controlled. The AICM controls mapping shows how each domain lines up with an enforcement point. Book a technical deep dive at deepinspect.ai.