AI workloads deployed in the cloud are a new attack surface that sits at the intersection of traditional cloud exploitation and AI-specific weaknesses. Every major provider now offers managed AI services, including Amazon SageMaker and Bedrock, Azure OpenAI Service and AI Foundry, and Google Vertex AI, and organizations are shipping LLM-powered applications faster than their security teams can threat model them. This guide covers why AI workloads are a cloud attack surface, the main attack paths and how they reach the cloud, the real incidents, how to build detection, and how to practice the attacks and defenses hands-on.
Why AI workloads are a cloud attack surface
Many organizations treat an AI deployment as an application-layer concern and leave the cloud infrastructure that underpins it out of the threat model. That gap is the opportunity. The model is only one component: behind it sit storage buckets holding model artifacts, an execution role with IAM permissions, retrieval sources, and the cloud APIs the application can call. We have spent considerable time building and testing AI-integrated cloud environments, and the pattern is consistent, the AI application becomes the front door to the cloud account behind it, and the failure modes are cloud access failures, not model failures.
The main attack paths
Attacks on AI workloads map to a small set of paths. Each one is a way to turn access to the AI application into access to the cloud account, its data, or its models. These families line up with our AI attack taxonomy and the OWASP Top 10 for LLM Applications.
| Attack | How it reaches the cloud | Cloud impact | OWASP |
|---|---|---|---|
| Indirect prompt injection | Attacker-controlled content the app retrieves (email, ticket, document, web page) carries instructions the model runs with the app's permissions | Credential theft, data exfiltration, actions taken as the application | LLM01 |
| Model and weight exfiltration | Over-permissive service accounts, compromised endpoints, or CI/CD pipelines read model artifacts from storage | Theft of proprietary models and the training data they encode | LLM02 |
| Agent tool abuse | A compromised agent calls cloud APIs and tools with its execution role's IAM permissions | Pivot from application compromise to cloud account access | LLM06 |
| Retrieval (RAG) poisoning | Seeding attacker content into a knowledge base the app later retrieves | The model treats attacker text as truth during a normal user request | LLM04, LLM08 |
| Guardrail bypass | Encoding, obfuscation, or indirect framing evades the safety layer | Restricted actions and disclosures the guardrail was meant to block | LLM01 |
| Model supply-chain compromise | A poisoned base model or training set carries a backdoor through fine-tuning into production | Attacker-triggered behavior in the deployed model | LLM03, LLM04 |
Indirect prompt injection: the SSRF of AI systems
Direct prompt injection gets the headlines, but indirect prompt injection is the path that reaches the cloud. When an LLM-powered application processes external content such as emails, documents, web pages, or database records, an attacker who controls any of that content can plant instructions the model runs in the context of the application's permissions. Picture a cloud-hosted assistant that reads a team chat and can call internal APIs: an attacker who can post to a monitored channel injects a prompt that tells the model to return the keys it authenticates with, and the model, unable to separate instruction from data, complies. In the cloud this is more severe than traditional server-side request forgery, because the agent often holds broader permissions than any single microservice, including database reads, the ability to invoke functions, and access to internal APIs. You can run this exact chain in our hands-on labs Breach the Perimeter via Prompt Injection and Exploit Indirect Prompt Injection for Azure Access, where a prompt injected into an AI assistant yields cloud credentials.
Model and weight exfiltration
Fine-tuned models are intellectual property: months of compute and proprietary training data encode a competitive advantage. In the cloud those models sit in storage, such as S3, Azure Blob Storage, or Google Cloud Storage, protected by IAM policies that are often more permissive than they should be. The exfiltration chain starts with the cloud-native techniques practitioners already know, over-permissive service accounts, misconfigured bucket policies, or a compromised CI/CD pipeline with access to model artifacts. What makes AI workloads different is value density: one model file can carry the distilled knowledge of millions of proprietary data points. SageMaker execution roles with s3:GetObject scoped far beyond the model bucket are a frequent finding, and the same pattern appears in Azure ML workspaces where a managed identity has over-permissive access to the associated storage account.
LLM agents as pivot points
Autonomous agents with tool-calling can execute code, query databases, call APIs, and interact with cloud services from natural-language instructions, which makes them a powerful living-off-the-land capability once compromised. An agent inherits whatever permissions its execution context provides, so if its function or container carries a broad IAM role, which is a common configuration, compromising the agent through prompt injection grants all of those permissions, reached through natural language instead of raw API calls. Detection is hard because the agent's actions look identical to legitimate operations: the same API calls, the same access patterns, the same services. Anomaly rules that look for unusual API usage miss an attack run through a legitimately authorized agent that was instructed to do something it should not.
Retrieval poisoning, guardrail bypass, and the model supply chain
These attack classes are not unique to any one provider: they are general weaknesses of how AI systems are built, and the managed service is just where a given class shows up. Retrieval poisoning is the clearest example. Any system that answers from a knowledge base can be poisoned by seeding attacker-controlled content into a source it later retrieves, whether that is an Amazon Bedrock Knowledge Base, Azure AI Search behind Azure OpenAI, Vertex AI Search, or a self-hosted vector store such as pgvector or Pinecone. The weakness lives in the ingestion and retrieval design, not the vendor. Guardrail bypass is similar: the major providers ship a safety layer, including Bedrock Guardrails and Azure AI Content Safety, and each can be evaded with encoding, obfuscation, or indirect framing that the filter misses but the model still acts on. Guardrails are probabilistic mitigations, not boundaries, and their defaults are weaker than a hardened configuration. The training and fine-tuning pipeline is a supply chain of its own and is provider-agnostic too: organizations pull base models from public registries, fine-tune with proprietary data, and deploy to endpoints with little integrity verification, so a backdoor in a compromised base model or a poisoned training set can carry through fine-tuning into production, where a specific input triggers it. Researchers have shown concrete privilege and pipeline weaknesses on managed platforms, including Google Cloud Vertex AI.
What this looks like in the real world
These paths are not theoretical, and the disclosed cases increasingly involve cloud-hosted, agentic systems. EchoLeak (CVE-2025-32711, CVSS 9.3) was a zero-click indirect prompt injection in Microsoft 365 Copilot that could exfiltrate data from a user's context with no interaction. ForcedLeak (CVSS 9.4) used an instruction planted in a Web-to-Lead field to make Salesforce Agentforce leak CRM data, a clean example of an agent with cloud permissions turned against its owner, reported and patched by Salesforce. Slack AI was abused to pull data from private channels through indirect injection, cataloged by MITRE ATLAS as case AML.CS0035. Each maps to the OWASP categories this post covers: prompt injection (LLM01), sensitive information disclosure (LLM02), and excessive agency (LLM06).
Building detection for AI-era cloud threats
Effective detection correlates signals across three layers: the AI application (prompt logs, model inputs and outputs), the cloud infrastructure (CloudTrail, Azure Activity Logs), and the data layer (storage access patterns and database queries). Many organizations have visibility into only one or two of these, which is exactly where cross-layer attack paths go undetected. The detection value lives at the boundaries between the layers: an agent that suddenly accesses storage buckets it has never touched, inference requests that spike from an unexpected source, or model output that matches a data-exfiltration pattern. The teams that build this correlation now, while AI deployment is still accelerating, will be far ahead of those retrofitting security after the first major AI-assisted cloud breach.
How we practice this in realistic environments
The techniques above, indirect prompt injection, model exfiltration, and agent abuse, need to be practiced in environments that replicate real cloud-hosted AI, not sanitized challenges with artificial constraints. Our prompt-injection labs, Breach the Perimeter via Prompt Injection and Exploit Indirect Prompt Injection for Azure Access, run the attack from an injected prompt through to cloud credentials, and the PromptStorm cyber range puts the full chain together. To go end to end, from initial access through an AI application to cloud account compromise and the blue-team view alongside it, the AI Systems Attack and Defense bootcamp works through prompt injection, RAG and embedding poisoning, tool and agent abuse, and MCP and CI/CD agent paths, and leads to the AISRTP certification. The shift tends to reframe how practitioners think about AI security, because watching an agent exfiltrate credentials from a real cloud environment makes clear that the failure was a cloud access failure, not a model failure. Only ever test systems you own or are explicitly authorized to assess.
Frequently asked questions
What is an AI workload attack in the cloud?
An AI workload attack reaches a cloud account through the AI application in front of it. The most common path is indirect prompt injection: attacker-controlled content the model reads carries instructions it runs with the application's cloud permissions, which are often far broader than any single service needs.
How does prompt injection lead to cloud credential theft?
An LLM-powered application processes external content and cannot reliably separate instruction from data. An attacker who controls that content can instruct the model to read and return the credentials or tokens the application uses, which hands the attacker the application's cloud access.
What makes LLM agents dangerous in cloud environments?
An agent executes cloud APIs with its execution role's IAM permissions. If that role is over-permissive, compromising the agent through prompt injection grants those permissions, and the activity looks like legitimate application behavior, so traditional anomaly rules miss it.
Is model exfiltration a real risk?
Yes. Fine-tuned models sit in cloud storage protected by IAM policies that are often broader than the model bucket. An attacker who compromises an endpoint, a service account, or a CI/CD pipeline can enumerate and download the model artifacts, which encode proprietary training data.
How do you detect attacks on AI workloads?
By correlating signals across three layers: the AI application (prompt and model input and output logs), the cloud infrastructure (CloudTrail, Azure Activity Logs), and the data layer (storage and database access). The attacks show up at the boundaries, such as an agent touching storage it has never used before.
How do I practice attacking and defending AI workloads?
Use live, cloud-hosted AI environments, not sanitized challenges. Our prompt-injection labs and the PromptStorm cyber range let you run the attack chains end to end, and the AISRTP bootcamp covers attack and defense across LLM-backed and agentic applications.