Many organisations cannot say which AI models, endpoints, datasets and agents are running in their cloud accounts, who can reach them, or which identities and keys can call them. AI security posture management (AI-SPM) is the discipline, and the product category, that answers those questions continuously: it discovers AI assets across cloud and code, checks them for misconfiguration, finds exposed keys and over-permissive workload identities, and traces attack paths to training data and models. This guide explains what AI-SPM covers, how it relates to CSPM, DSPM and CNAPP, what the major cloud providers document, and how to roll it out and measure it. It is for cloud security, platform and AI engineering teams and the architects deciding whether AI-SPM is a feature, a module or a separate purchase.
Key takeaways
- AI-SPM is posture, not runtime protection. It inventories and checks configuration of AI services, models, data and agents; it does not inspect prompts in real time. Pair it with guardrails and logging.
- The inventory is the product. An AI bill of materials linking models, endpoints, data, agents and their identities gives every finding its context.
- Most serious findings are identity findings. Key-based authentication left enabled, long-lived API keys, managed identities with broad data access and public endpoints without strong authentication recur across the major clouds.
- AI-SPM extends CSPM, DSPM and CNAPP rather than replacing them. It adds AI-specific resource types, checks and attack paths on top of the same cloud graph.
- Measure exposure, not finding counts. Track the share of AI endpoints that are private and keyless, the age of AI credentials, and time to fix attack paths that reach sensitive training data.
What AI-SPM covers
AI workloads add resource types that classic cloud posture checks were not written for: model registries, managed model endpoints, vector stores, fine-tuning jobs, notebooks with GPU access, agent runtimes and Model Context Protocol (MCP) servers. Each has its own network, encryption, logging and identity settings. Microsoft describes its AI-SPM capability as discovering "the generative AI Bill of Materials (AI BOM), which includes application components, data, and AI artifacts from code to cloud". Google's Security Command Center AI Protection lists models (foundation, fine-tuned, first-party and custom), endpoints, data sources such as BigQuery tables and Cloud Storage, apps and agents, and MCP servers as supported resources.
| Asset type | Examples | Posture questions |
|---|---|---|
| Managed AI services | Amazon Bedrock, Azure OpenAI and Azure AI Foundry, Google's Vertex AI platform | Is key access disabled? Is the endpoint private? Is invocation logging on? |
| Self-hosted models and endpoints | Inference containers on Kubernetes, SageMaker endpoints, open-source model servers | Is the endpoint internet-reachable? Does it require authentication? Is the model artefact from a trusted registry? |
| Training and grounding data | Object storage buckets, data lakes, feature stores, vector databases | Which identities can read or write it? Is it encrypted with a managed key? Does it hold sensitive data? |
| Development environments | Managed notebooks, Workbench instances, Colab Enterprise, Databricks clusters | Public IP? Root access? Secrets in notebook files? Patched images? |
| AI libraries and code | PyTorch, TensorFlow, LangChain; infrastructure as code | Known vulnerabilities? Insecure template defaults? |
| Agents and tools | Foundry agents, Bedrock agents, MCP servers | Which tools, data and identity does the agent use? |
| AI credentials | Model API keys, service principals, managed identities, roles | Owner, age and effective permission? |
Discovery has to reach beyond the AI console. Google's documentation distinguishes declarative assets (tracked by the AI platform), inferred assets (general compute and storage processing AI data) and Model-as-a-Service usage seen only through API calls. Inferred assets, such as a GPU virtual machine serving an open-weights model, are where unmanaged AI hides. See the Shadow AI Discovery Guide for the SaaS and browser side of the same problem.
AI-SPM, CSPM, DSPM and CNAPP compared
The categories share one model: a graph of cloud resources, identities, network paths and data. AI-SPM adds AI resource types and checks to that graph. Microsoft ships it inside the Defender CSPM plan and Google as AI Protection in Security Command Center: a module of a cloud platform, not a separate tool.
| Category | Primary question | What it adds for AI | Gap if used alone |
|---|---|---|---|
| CSPM | Are cloud resources configured securely? | Generic checks on storage, network and IAM that also protect AI resources | No awareness of models, agents, AI endpoints or AI-specific settings |
| DSPM | Where is sensitive data and who can reach it? | Classifies training, grounding and fine-tuning data | Does not know which model was trained on which dataset |
| CIEM | Which identities have excessive or unused permissions? | Right-sizes roles of pipelines, notebooks and agents | Lacks the AI context that makes a permission dangerous |
| CNAPP | What is the combined risk from code to cloud? | Correlates vulnerabilities, posture, identity and data on one graph | AI coverage depends on the vendor's AI resource support |
| AI-SPM | Which AI assets exist and how exposed are they? | AI inventory, AI BOM, AI misconfiguration checks, attack paths to models and data | No runtime inspection of prompts and outputs |
See the CNAPP Guide for how posture, workload protection and attack path analysis fit together, and the Data Security Guide for DSPM. Runtime controls on prompts and outputs belong to a different layer: see the AI Guardrails and AI Firewalls Guide.
Common AI misconfigurations
The same handful of issues appears in every cloud. The table uses check names as the providers publish them, so you can search for them in your own tooling.
| Misconfiguration | Why it matters | Documented check (examples) |
|---|---|---|
| Key-based access left enabled on AI services | A leaked key works from anywhere and is not tied to an identity | Microsoft: "Azure AI Services resources should have key access disabled (disable local authentication)" |
| Public network access to AI endpoints | Anyone with a credential, or an unauthenticated endpoint, can call the model | Microsoft: "Azure AI Services resources should use Azure Private Link"; "AWS Bedrock should use AWS PrivateLink"; "A Private Service endpoint should be used for Vertex AI Online endpoints" |
| Notebooks with internet access or root | Notebooks hold data, credentials and code | AWS Security Hub SageMaker.1 (no direct internet access), SageMaker.3 (no root access); Microsoft: "Root access should be disabled on Workbench instances" |
| Model invocation logging off | No record of who called which model with what input during an investigation | Amazon Bedrock model invocation logging is "disabled by default"; Microsoft: "AWS Bedrock should have model invocation logging enabled" |
| Data stores reached with keys rather than identities | Storage keys grant broad, unattributed access to grounding data | Microsoft: "Microsoft Entra ID should be used when connecting to data stores on Microsoft Foundry project (Preview)" |
| Models without network isolation or from untrusted registries | Exfiltration from the container; malicious code in unvetted images | SageMaker.5 (models network isolation), SageMaker.16 (private registry in VPC for primary containers) |
| Unsafe model artefacts | Serialisation formats such as Python pickle can execute code when a model is loaded | Microsoft: "Security findings should be resolved on AI models within Azure Machine Learning resources (Preview)", covering serialisation exploits and malware |
| Agents with unrestricted tools | An injected instruction can drive any tool the agent can reach | Microsoft: "Foundry Agent's MCP tool should be configured with allowed tools list (Preview)" |
| Training data without customer-managed keys where required | Weaker control over who can decrypt and when access can be revoked | Bedrock.1 (data sources encrypted with customer managed KMS keys); SageMaker.17 and SageMaker.21 |
What the cloud providers document
Native tooling is a baseline and a yardstick for third-party products. Features below are as documented in October 2026; several are in preview.
- Microsoft Defender for Cloud: AI security posture management is part of the Defender CSPM plan and covers Azure, AWS and Google Cloud. It automatically discovers Azure OpenAI Service, Azure AI Foundry, Azure Machine Learning, Amazon Bedrock and Google Vertex AI workloads, builds an AI BOM, scans infrastructure as code and container images for vulnerable AI libraries "such as TensorFlow, PyTorch, and Langchain", and runs attack path analysis including "data exposure during model grounding and fine-tuning". From 1 July 2026, agent-level discovery and posture requires a Microsoft Agent 365 licence.
- Google Security Command Center AI Protection: asset inventory is available in all tiers; vulnerability findings (including plaintext secrets in agent workloads), Attack Path Simulation that treats agents and MCP servers as high-value resources, over-privileged agent detection, Event Threat Detection rules for AI assets and Risk Engine attack exposure scores need the Premium or Enterprise tier. Google's current documentation files Vertex AI under the name Gemini Enterprise Agent Platform and states that the Enterprise tier shuts down on 21 May 2027.
- AWS: AWS Security Hub publishes SageMaker controls SageMaker.1 to SageMaker.25 backed by AWS Config rules (for example
sagemaker-notebook-no-direct-internet-accessandsagemaker-model-isolation-enabled) and one Bedrock control, Bedrock.1 (bedrock-data-source-encryption-enabled). Bedrock model invocation logging sends request, response and metadata for Converse, ConverseStream, InvokeModel and InvokeModelWithResponseStream calls to CloudWatch Logs or S3 in the same account and Region, but only for calls through thebedrock-runtimeendpoint.
Native coverage is strongest for each provider's own AI services, so a multi-cloud estate either accepts uneven coverage or adds a cross-cloud layer. Check connector permissions too: Microsoft notes that an AWS connector set to least-privilege access must be reconfigured before AI posture works.
Where identity fits
AI workloads run on non-human identities, and the findings worth fixing first are mostly about them. Microsoft describes the goal as highlighting "externally reachable AI endpoints so teams can enforce strong authentication and least privilege identities".
- Model provider API keys: keys to hosted models are bearer credentials. Amazon Bedrock now offers two kinds: short-term keys that last up to 12 hours and inherit the permissions of the principal that created them, which AWS recommends for production, and long-term keys that create an IAM user and that AWS says are "Recommended only for exploration". Posture checks should find long-term keys, cap their lifetime with the
iam:ServiceSpecificCredentialAgeDayscondition, and denybedrock:CallWithBearerTokenfor identities that should never use keys. See the LLMjacking Guide and the API Key Management Guide. - Workload identities for pipelines and endpoints: training jobs, notebooks and inference services run as managed identities, service accounts or IAM roles that often keep the whole-data-lake access granted during experimentation. Right-size them with CIEM data and use separate identities per environment. See the AI Infrastructure Workload Identity Guide and the Cloud PAM and CIEM Guide.
- Agent identities: agents act with an identity and a set of tools. Google's AI Protection flags over-privileged agents and alerts on token creator roles granted to agents, which would let an agent mint credentials for other identities. See the Agentic AI Identity Guide.
- Secrets in AI artefacts: notebooks, container images and agent code often hold hard-coded keys; Google's agent vulnerability assessment looks for plaintext secrets in agent images. See the Secrets Management Guide.
Key posture can change without any change to the key. The Google API keys exposure showed that enabling Gemini in a project turned previously low-risk public Maps and Firebase keys into credentials that could reach AI data, so AI-SPM must re-evaluate existing keys when AI APIs are switched on.
Attack paths to models and training data
A public endpoint, a broad role or a sensitive bucket is often low priority alone; attackers use the combination. Typical paths:
- Leaked key to model abuse: a model API key found in a public repository or image is used to run inference at the victim's expense. MITRE ATT&CK lists this under T1496.004 Cloud Service Hijacking, which notes attackers "may engage in LLMJacking by leveraging reverse proxies to hijack the power of cloud-hosted AI models". The LLMjacking campaigns followed this path.
- Exposed workload to training data: an internet-facing inference container with a vulnerable library runs as an identity that can read the training bucket, giving data theft (T1530 Data from Cloud Storage) and, with write access, a route to data poisoning (OWASP LLM04:2025 Data and Model Poisoning).
- Notebook to cloud control plane: a notebook with internet access and a powerful role is compromised through a malicious package; the attacker reads instance metadata credentials (T1552.005 Cloud Instance Metadata API) and moves to other resources.
- Agent to sensitive data: an agent with an injection-prone data source and broad tool access is steered into sending data out. Microsoft recommends human approval of MCP tool actions for such agents.
- Unauthenticated AI platform: a self-hosted AI gateway, vector database or orchestration tool is exposed with default or missing credentials. The Moltbook database exposure leaked AI agent API keys from an open database, and the LiteLLM MCP auth bypass involved default master keys on an AI gateway.
Risk scoring and prioritisation
Vendor risk scores are a starting point, not a decision. Triage on four factors: reachability (internet or less trusted network), authentication strength (keyless identity, short-lived key, long-lived key or none), data sensitivity (including grounding and fine-tuning data) and blast radius (the effective permissions of the identity the asset runs as). Fix internet-reachable, key-authenticated assets with sensitive data access within days.
Choosing your approach
| Situation | Reasonable choice | Trade-off |
|---|---|---|
| One cloud, AI on that provider's managed services | Enable the provider's native AI posture features and benchmarks | Lowest cost; weak on self-hosted models and other clouds |
| Multi-cloud, already running a CNAPP | Turn on the CNAPP's AI module and test its coverage of your AI services | One graph and one queue; AI depth varies widely by product |
| Large AI engineering estate, self-hosted models and many agents | A platform with strong AI BOM, model scanning and agent coverage, integrated with CNAPP and identity tooling | More tools and integration effort; risk of duplicate findings |
| Small organisation using AI mainly through SaaS | Prioritise shadow AI discovery and API key hygiene | AI-SPM adds little; risk sits in SaaS and keys |
Whichever route you choose, the posture tool's own connectors hold read access across every account: require read-only, federated credentials, because they are privileged non-human identities too.
Implementing AI-SPM
- Agree scope and connect read-only: list the accounts, subscriptions and projects that host AI, name an owner in each, and onboard them with read-only, role-based connectors. Record every permission requested.
- Build the inventory first: run discovery for two to four weeks before enforcing anything. Reconcile the AI BOM against the governance use case register and shadow AI findings. Unknown assets are the first finding.
- Turn on audit-only checks: enable AI recommendations in report mode and agree severity thresholds with platform teams.
- Fix the top paths: start with internet-reachable endpoints using key authentication, long-lived AI keys, notebooks with internet and root access, and identities with write access to training data.
- Shift left: add the same checks to infrastructure as code pipelines, warning first, then blocking high severity only, with expiring exceptions.
- Enforce with preventive policy: once false positives are understood, use organisation policies, Azure Policy or service control policies to block public AI endpoints and key creation in production. Pilot in one non-production account, then one production business unit, before wider rollout.
- Plan rollback: keep preventive policies in a separate assignment you can disable quickly, and confirm legitimate identities still reach each AI service before enforcing network restrictions.
Detection and measurement
Posture tells you what could happen; logs tell you what did. Enable Bedrock model invocation logging, Azure AI services diagnostic logs, machine learning workspace resource logs and control plane audit logs. Alert on new AI API keys, keys used from new locations, sudden spikes in token consumption (OWASP LLM10:2025 Unbounded Consumption), role grants to agent identities and public access changes on AI endpoints.
Metrics that show the programme working:
- Inventory coverage: percentage of AI assets in the AI BOM with a named owner and a matching entry in the governance register.
- Keyless rate: percentage of AI services with key or local authentication disabled.
- Private endpoint rate: percentage of AI endpoints not reachable from the internet.
- Credential age: number of AI API keys older than 90 days, trending to zero.
- Attack path time to fix: median days to close critical attack paths that reach sensitive training or grounding data.
- Logging coverage: percentage of model endpoints with invocation or diagnostic logging enabled.
Framework mapping
| Framework | Reference | AI-SPM relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02 (software, services and systems inventoried), ID.RA-01 (vulnerabilities identified), PR.AA-05 (least privilege), PR.PS-01 (configuration management), DE.CM-09 (computing environments monitored) | Inventory, configuration, least privilege, monitoring |
| NIST SP 800-53 Rev. 5 | CM-8, CM-6, RA-5, AC-6, AU-2, CA-7 | Same controls applied to AI components |
| NIST AI RMF 1.0 | GOVERN 1.6 (mechanisms to inventory AI systems) | AI BOM feeds the AI system inventory |
| CIS Controls v8.1 | 1.1 and 2.1 (asset and software inventory), 3.3 (data access control lists), 4.1 (secure configuration), 5.3 (disable dormant accounts), 6.8 (role-based access) | Inventory and hygiene for AI workloads |
| ISO/IEC 27001:2022 Annex A | A.5.9 (inventory of assets), A.8.2 (privileged access rights), A.8.9 (configuration management), A.8.16 (monitoring activities) | Same controls applied to AI assets |
| OWASP Top 10 for LLM Applications 2025 | LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM06 Excessive Agency, LLM10 Unbounded Consumption | Risks posture checks reduce |
| MITRE ATT&CK v20 | T1496.004 Cloud Service Hijacking, T1078.004 Cloud Accounts, T1552.005 Cloud Instance Metadata API, T1530 Data from Cloud Storage | Techniques behind common AI attack paths |
Common failure patterns
- Scanning only the AI console: discovery limited to managed AI services misses open-weights models on GPU virtual machines and Kubernetes, which are often the least protected. The Carbonato botnet hunted AI API keys on exposed Docker hosts, outside any AI service inventory.
- Treating AI keys as configuration: keys stored in notebooks, environment files and images are found by attackers before posture tools look. The Docker Hub secrets leak included AI keys in public container images.
- Disabling key access without an inventory of key users: production breaks, the change is rolled back and never retried. Measure key usage first, migrate callers to identities, then disable.
- Ignoring write access: teams fix read exposure to training data but leave write access to datasets and model registries, the path to poisoning and tampering, which is harder to detect than theft.
- Posture without logging or owners: invocation logging stays off by default and AI resources built by data science teams have no platform owner, so findings age and abuse leaves no evidence.
Practitioner checklist
- List every account, subscription and project hosting AI, with an owner, and connect it read-only to your posture tooling.
- Build an AI BOM and reconcile it with the AI governance register and shadow AI discovery.
- Disable key-based authentication on AI services where callers can use workload identities.
- Find and retire long-lived model API keys; cap lifetimes and deny key use where it is not needed.
- Make AI endpoints private by default and block public endpoints in production through policy.
- Remove internet access and root from notebooks; run models with network isolation from trusted registries.
- Right-size identities used by pipelines, endpoints and agents, removing write access to training data where not required.
- Turn on model invocation and diagnostic logging and alert on key creation, unusual usage and role grants to agents.
- Report the metrics monthly and track critical attack paths to closure.
Standards and references
- NIST: AI 100-2 E2025 Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
- NCSC: Guidelines for secure AI system development
- OWASP: Top 10 for LLM Applications 2025
- MITRE ATT&CK: T1496.004 Cloud Service Hijacking
- Microsoft Learn: AI security posture management in Defender for Cloud
- Google Cloud: AI Protection overview (Security Command Center)
- AWS: Security Hub controls for Amazon SageMaker
- AWS: Amazon Bedrock API keys
Related NHI Mgmt Group resources: CNAPP Guide · AI Infrastructure Workload Identity Guide · LLMjacking Guide · AI Security Platform Buyer's Guide · Shadow AI Discovery Guide