Generative AI has done to the enterprise what SaaS did a decade ago: it is being adopted faster than security teams can inventory it. KPMG research cited in Microsoft's own security blog found that 44% of employees have used AI in ways that contravene company policy, and only 41% say their organization even has a GenAI usage policy. The result is "shadow AI" — Azure OpenAI deployments, Amazon Bedrock agents, and Vertex AI pipelines spun up by product teams without a single security review. You cannot protect what you cannot see, and traditional cloud security posture management (CSPM) tools were never designed to answer questions like "which storage accounts feed training data to which models?" or "is that LangChain-based inference service internet-exposed?"

AI Security Posture Management (AI-SPM) is the discipline that emerged to close that gap, and Microsoft Defender for Cloud has made it a first-class capability of its Defender CSPM plan. This article walks through what AI-SPM is, how Defender for Cloud discovers AI workloads across Azure, AWS, and GCP, what kinds of risks it detects in GenAI pipelines, how its attack path analysis works, and — most importantly — what you should actually do with the findings.

What AI-SPM actually is

AI-SPM is a specialized extension of CSPM focused on the AI/ML stack: models, training and grounding data, pipelines, agent frameworks, and the infrastructure they run on. Where classic CSPM asks "is this storage account public?", AI-SPM asks "is this storage account public and does it contain grounding data for a customer-facing chatbot?" That contextual link between AI artifacts and the resources around them is the entire point.

In Defender for Cloud, AI-SPM is not a separate SKU. It ships inside the paid Defender CSPM plan (billed per billable resource per month; the free Foundational CSPM tier does not include it) and covers four pillars:

  1. Discovery — building an AI Bill of Materials (AI BOM) from code to cloud.
  2. Vulnerability assessment — of container images and AI library dependencies.
  3. Attack path analysis — graph-based reasoning about exploitable routes to AI assets.
  4. Security recommendations — prioritized, risk-based guidance across identity, data, and network exposure.

Microsoft's 2025-era roadmap has extended this further with AI agent discovery (in preview) for Microsoft Foundry agents, and runtime threat detection for AI workloads — such as prompt-injection alerts surfaced through Defender XDR — which complements the posture side. Posture tells you what could be exploited; runtime detection tells you when someone is trying.

Discovery: the AI Bill of Materials across three clouds

Discovery is the foundation. Defender for Cloud continuously and agentlessly inventories AI workloads across:

The multicloud piece works through Defender for Cloud's existing agentless connectors. Once you onboard an AWS account or GCP project with the Defender CSPM plan enabled, the connector snapshots configuration metadata and feeds it into the same cloud security graph used for attack path analysis. One operational gotcha worth knowing: if your AWS connector was configured with least-privilege access before AI-SPM support shipped, you must reconfigure the connector permissions — the AI discovery APIs require additional IAM permissions that the older role definition doesn't include. You do this from Environment Settings → select the AWS connector → Configure access in the Azure portal.

The output is the AI BOM: a code-to-cloud inventory of application components, data sources, and AI artifacts. Crucially, discovery is not limited to what is deployed. Defender for Cloud's DevOps security features scan source repositories for Infrastructure-as-Code definitions that provision AI services, and container registries for images containing AI frameworks. That means a Terraform template that would create a publicly reachable Azure AI Services endpoint is flagged before it is ever applied — shift-left for AI infrastructure.

In the Defender portal you can browse this inventory through Cloud Security Explorer and the attack path view, filtering for AI-specific resources (the graph labels resources such as "AI workload," "AI data store," and "contains sensitive data" so you can query across them).

Risk detection in GenAI pipelines

Once workloads are inventoried, Defender for Cloud assesses them against three broad risk categories that map neatly onto how GenAI systems actually fail.

Data exposure

GenAI pipelines concentrate sensitive data in exactly two places: grounding data (RAG indexes, vector stores, the blobs and data lakes a model retrieves from) and fine-tuning datasets. Microsoft's attack path documentation explicitly calls out both as high-value targets. Defender for Cloud combines AI discovery with its data-aware security posture capabilities (leveraging Purview sensitivity labels and data classification) to flag cases where an AI endpoint can reach a data store containing PII, credentials, or confidential IP — especially when that endpoint is internet-facing or over-privileged.

The classic pattern it catches: an Azure OpenAI deployment with a public endpoint, authenticated only by an API key stored in an app setting, wired to a storage account full of unencrypted customer support transcripts. Each resource looks mediocre in isolation; the combination is a breach.

Misconfigurations

Misconfiguration checks cover both deployed resources and IaC. Current AI-specific IaC checks include:

These look like the same storage/network/identity hygiene rules you already know, applied to AI resources — which is exactly right. Most real-world GenAI incidents are not exotic model attacks; they are an endpoint deployed with --public-network-access Enabled and a hard-coded key in a repo. Beyond IaC, the recommendation engine assesses running workloads for internet exposure, weak authentication, and excessive identity permissions, with risk-based prioritization so an internet-facing, key-authenticated endpoint outranks a private one.

Vulnerable dependencies

The AI supply chain is a Python supply chain: TensorFlow, PyTorch, LangChain, transformers, and a long tail of CUDA-adjacent native libraries. Defender for Cloud scans container images and code repositories for these dependencies and maps findings to CVEs via Microsoft threat intelligence. This matters more than it sounds — LangChain and its ecosystem have had a string of serious CVEs (template-injection and SSRF classes), and ML-serving containers are often rebuilt infrequently because "the model works." AI-SPM surfaces which of your discovered AI workloads are running on vulnerable bases so patching becomes a prioritized queue rather than a guessing game.

Attack path analysis

Individual findings are noise; attack paths are signal. Defender for Cloud's attack path analysis uses the cloud security graph — a continuously updated model of resources, identities, network reachability, vulnerabilities, and data sensitivity across Azure, AWS, and GCP — to compute routes an external attacker could take to reach a critical asset. AI assets are now first-class targets in that graph.

A representative AI attack path looks like: internet-exposed container app → running a LangChain-based service with a known CVE → service principal with Storage Blob Data Reader on a grounding-data account → that account contains sensitive data used by an Azure OpenAI deployment. The path is assigned a risk level by a context-aware engine that weighs exploitability, exposure, lateral movement potential, and the business criticality of the target.

Prerequisites to know: attack path analysis requires the Defender CSPM plan with agentless scanning enabled, and viewing container-related paths requires either the agentless container posture extension in Defender CSPM or Defender for Containers with the relevant agents. Roles needed to view paths include Security Reader, Security Admin, Reader, Contributor, or Owner.

The practical value is triage. Instead of 400 recommendations, you get a short list of "this path is exploitable today and ends at your fine-tuning data — fix these two edges and the path collapses." Each path lists the specific recommendations (e.g., disable public network access, rotate to managed identity, patch the image) that sever it.

Practical hardening recommendations

Tooling finds problems; you still have to fix them. Here is the hardening order I'd recommend, derived from how attack paths are actually scored:

  1. Kill public exposure on AI endpoints first. Enable private endpoints and disable public network access on Azure OpenAI, AI Foundry hubs, and ML workspaces. For Bedrock and Vertex AI, enforce VPC-only access patterns. Internet-reachable + AI data store adjacency is the single highest-risk combination in the graph.
  2. Move from API keys to managed identities. Disable local authentication on AI services and use Entra-based, identity-first auth with least-privilege role assignments. Keys leak into logs, repos, and prompts; managed identities don't.
  3. Scope the identity blast radius. The service identity behind an inference app should read only the specific containers or indexes it grounds from — not the whole data lake. Attack path analysis will show you exactly which over-privileged edges to cut.
  4. Classify and encrypt grounding/fine-tuning data. Turn on Defender CSPM's data-aware posture features and Purview classification so the graph knows which AI-reachable stores hold sensitive data; that classification is what elevates a finding from "medium" to "critical."
  5. Shift IaC checks into CI. Run Defender for Cloud's DevOps security scanning on your repos so the four AI IaC checks fail the build, not the audit. Remediation in a pull request costs minutes; remediation after deployment costs an incident review.
  6. Patch the AI supply chain on a cadence. Treat LangChain, PyTorch, TensorFlow, and friends like internet-facing software (they are). Rebuild inference images on a schedule and gate on CVE severities Defender surfaces.
  7. Don't forget runtime. Posture is necessary but not sufficient — pair AI-SPM with Defender's threat protection for AI workloads (prompt-injection and data-leak alerts in Defender XDR) and Azure AI Content Safety prompt shields for defense in depth.

Conclusion

AI-SPM in Defender for Cloud is, at its core, the same posture-management discipline you already practice — inventory, configuration hygiene, vulnerability management, attack-path-driven prioritization — pointed at a stack that changes weekly and concentrates your most sensitive data behind your newest, least-understood endpoints. The multicloud AI BOM gives you the inventory nobody else in the org has; attack path analysis tells you which of the hundreds of findings actually matter. Enable Defender CSPM with agentless scanning on your Azure subscriptions and your AWS/GCP connectors, start with the internet-exposed endpoints, and work the attack paths from the top of the risk list down. The models may be novel; the way they get breached mostly isn't.

Further reading