CSA AICM LLM Requirements: An Application Provider Baseline

An application provider's AICM obligations become visible in one production inference request. An authenticated principal asks the application to perform a task. The application assembles a prompt, chooses a model endpoint, receives a response and may turn that response into an action. Identity, data, model, supplier, logging and incident controls all touch that sequence.

The practical baseline is a set of requirements around the request, plus clear ownership for controls deeper in the AI service chain.

TL;DR

• AICM v1.1 contains 247 control objectives and assigns responsibilities across model, orchestration, application, customer and cloud actors.
• Application providers need controls for identity, data handling, model and route approval, logging, monitoring, failure, suppliers, change and incidents.
• Each requirement should produce versioned evidence tied to the deployed application and model route.
• DeepInspect covers authenticated HTTP traffic deliberately routed between users or agents and LLMs. Training, model weights, endpoints, local execution and provider infrastructure stay outside that boundary.

AICM requirements depend on the actor

The CSA AI Controls Matrix version 1.1, released June 22, 2026, contains 247 control objectives. CSA analyzes them using control type, applicability and ownership, architectural relevance, LLM lifecycle relevance and threat category. Its actor model allocates responsibility according to model development, orchestration, application delivery, customer use and cloud infrastructure.

CSA defines an application provider as the party building an end-user AI application with models and delivering domain-specific functions or user experiences. That party is accountable for controls in its own infrastructure and the services or products it offers. An enterprise buying the application may also occupy the AI customer role. A company fine-tuning or distributing a model can acquire model-provider responsibilities for that activity.

Write the role decision into the control scope. The AICM controls mapping shows how ownership changes the rows that apply. The baseline below focuses on an application provider consuming one or more LLM services through APIs.

Identity must survive the application boundary

IAM-01 requires identity and access management policies, while IAM-03 requires an inventory covering identities and access levels. CSA's AICM v1.1 auditing guidelines for application providers ask assessors to verify end-user IAM policy, application roles and privileges, federated identity integrations, human and non-human accounts, ownership, account status and role appropriateness.

For an LLM application, authentication at the user interface supplies only the first part. The authorization decision needs the person or agent represented by the model call, the role assigned to that identity and the requested model operation. Preserve that context through the application and into the policy record. A single provider API key can remain the transport credential, but it should never become the only identity in the evidence.

Test at least one human role and one non-human identity. Confirm that each reaches only approved routes and data classes. Disable or change the identity in the authoritative directory, then verify that model access follows. Our identity-aware AI gateway architecture covers the request structure behind that test.

Data requirements apply to the assembled prompt

DSP-01 requires policies for data preparation, classification, protection and handling across the lifecycle according to law, standards and risk. For application providers, CSA assigns primary responsibility for application-level data security and user privacy. The control reaches prompt construction, retrieval context, output handling, storage and later deletion.

Inventory the data sources that can enter a prompt. Record their classifications and the transformation that assembles the context window. Then classify the transmitted payload as a unit. A support prompt may combine a public product description, an internal runbook and customer account text. The final request carries the highest relevant handling requirement even when each fragment arrived through an approved connector.

Define allowed data classes by role, use case and destination. Apply the rule before transmission and again to the response. Decide which prompt or response content can be retained as evidence, which fields need masking or tokenization and which can be represented by classification and a controlled reference. The prompt-level DLP guide describes this control point in detail.

A model-provider privacy statement supports supplier review. It cannot classify a context window that exists only inside your application at request time.

Model requirements differ by consumption pattern

The Model Security domain covers documentation and validation alongside continuous monitoring. It also addresses failure handling, artifact checks, integrity and open-model assessment. Application-provider responsibility changes with the deployment pattern. Consuming a hosted model places emphasis on due diligence, documentation validation, integration behavior, monitoring and provider escalation. Fine-tuning or loading model artifacts adds direct responsibilities around the changed artifact and its lifecycle.

MDS-03, MDS-04 and MDS-05 require model documentation processes, baseline documentation requirements and validation against the current model. CSA's auditing guidance tells a consuming application provider to validate the third-party format and parameters, retain complete validation evidence, use an approved model-card template and periodically verify that documentation remains aligned with model changes.

Maintain an approved model record containing provider, model and version, endpoint, regions, intended uses, prohibited uses, context and output constraints, evaluation evidence, known limitations, owner, approval date and review trigger. Link that record to production routes. A model name written in an architecture deck can drift away from the alias currently serving traffic.

MDS-10 adds continuous monitoring for deployed application contexts. Track model performance in the application context, correlate interaction patterns, define application-specific metrics, integrate anomalies with incident response and escalate relevant findings upstream.

Failure behavior is an application requirement

MDS-11 requires a risk-based evaluation of model and serving failures and measures applied throughout the lifecycle. CSA's application-provider auditing guidance names redundant model services, multi-model routing or result aggregation, fallback behavior, response variation, monitoring, testing and failover records.

Choose the behavior per use case. A drafting assistant might defer a request when the approved model is unavailable. A support summarizer might use a reviewed secondary route. An application making a consequential recommendation may require human handling rather than returning a result from a materially different model. Document the policy and test the transition.

The fallback carries its own identity, data, destination and output risks. Verify that policy applies before traffic reaches the alternate model and that the record names the model actually used. Confirm that classification and response inspection stay active. Preserve the failover event and the user-facing behavior.

At 16:42 during a provider outage, the important visual detail is the route indicator changing on the operations screen while the policy record continues naming every destination. Silent fallback gives the business continuity team a green dashboard and leaves the audit trail describing the wrong system.

Logging must cover successful and failed interactions

LOG-01 establishes logging and monitoring policy. LOG-07 defines the required event and metadata scope. CSA's auditing guidance asks application providers to include authentication, authorization, API access, input validation failures, output anomalies, user access requests, model requests and responses, prompt-injection events, content-policy violations and both successful and failed interactions. It also calls for secure transmission to centralized logging and review after major application changes.

Build a request record around a correlation ID. Include timestamp, application-supplied identity and role, route, model and version, content classification, policy version, decision and outcome. Add response classification and handling when the response returns through the same controlled path. Retain configuration and change references so an assessor can reconstruct what rules were active at that time.

The AICM audit-evidence guide explains the assessment view. The operational requirement is more immediate: an engineer should be able to select one request and follow it across identity, application, policy, provider and incident systems without matching timestamps by eye.

Write-path independence strengthens the record. Centralized storage protects availability and integrity only when the application that made the inference call lacks authority to rewrite the compliance event.

Suppliers and changes need production reconciliation

STA-08 requires an inventory of supply-chain relationships. CSA's application-provider auditing guidance expects the inventory to cover infrastructure, data sources, model providers, APIs and platform components, with periodic review for completeness and current regulatory needs. STA-10 adds periodic risk review, while other supply-chain controls cover agreements, compliance and security assessment.

Compare the approved inventory with observed model destinations. The two lists answer different questions. Procurement records what the organization intended to use. Traffic records what production actually called. Reconcile them on a defined schedule and after a material release.

Change controls should cover model aliases, provider endpoints, orchestration settings, system prompts, tools, retrieval sources, access roles, content policy, retention and fallback routes. Record the request, approval, deployment, validation and rollback path. Trigger model-documentation and risk reviews where the change affects their assumptions.

My opinion is direct: a supplier inventory without production destination reconciliation is paperwork about intent. The running route decides where the data went.

Incident and assurance requirements close the loop

SEF controls require incident policy, response plans, exercises, metrics, category-based response and secure incident records. An LLM application playbook should cover data disclosure, prompt injection with impact, harmful or unauthorized output, route compromise, model failure and provider incidents affecting the application.

The incident record needs the request correlation fields plus detection and closure times, category and severity, affected assets and data, timeline, containment, recovery, root cause, lessons, corrective action and evidence artifacts. Test function disablement, model rollback, route denial, fallback, user communication and provider escalation. The AI incident response playbook provides the response mechanics.

A&A controls then govern policy, independent assessment, risk-based planning, audit management and remediation. Preserve findings with assigned owners, timestamps, status and completion evidence. Verify fixes after deployment and feed lessons into the application baseline.

The official STAR for AI programme states that Level 1 is earned through an AI-CAIQ self-assessment submitted to the STAR Registry. Level 2 combines third-party ISO/IEC 42001 certification with a Valid-AI-ted AI-CAIQ. Your baseline should therefore support both operational control and clear questionnaire evidence.

The HTTP boundary covers part of the baseline

Several application-provider requirements converge on authenticated HTTP traffic between the application and an LLM endpoint: identity binding, prompt and response classification, destination authorization, policy enforcement, request logging and route containment. A control point on that path can evaluate and record those facts before traffic proceeds.

Several other requirements live elsewhere in the service chain. Model cards and provider due diligence are governance artifacts. Training-data controls and model-weight integrity sit with parties handling those assets. Endpoint security, cloud infrastructure, local execution, STDIO tool traffic, business continuity decisions, human review design and regulatory interpretation require separate systems and owners. Direct API calls that bypass the configured route also bypass its policy and evidence.

AICM assessments work best with precise responsibility allocation. Put each requirement beside the actor and enforcement point that can satisfy it, then retain the handoff evidence. One product should never stand in for the full 247-control matrix.

DeepInspect

DeepInspect sits inline on the authenticated HTTP path between users or agents and LLM APIs. For traffic deliberately routed through it, policy can evaluate application-supplied identity and role, content classification, model destination and route before forwarding. The returning response can be evaluated on the same path.

Each decision produces a signed, tamper-evident record outside the calling application's write path, carrying the policy and model route used at that moment. That supports the identity, data, logging, destination and incident portions of the application-provider baseline. Provider due diligence, model documentation, training and weights, endpoints, local tools, cloud controls, business continuity and human governance remain outside the product boundary.

Book a technical deep dive at deepinspect.ai.