Most cloud security programs were not built for generative AI workloads. The IAM policies, network segmentation rules, and misconfiguration checks that worked for a three-tier web application in 2021 leave serious gaps when the workload is an LLM inference endpoint sitting next to a labeled PII dataset in S3. The attack surface changed. Most security tooling did not. For a foundation on how AI security intersects with cloud environments, see What Is AI Security?
A GenAI risk in a cloud environment is any misconfiguration, excessive permission, or exposed asset that enables an attacker to read, tamper with, or abuse a generative AI workload’s training data, model artifacts, inference endpoints, or retrieval databases.
GenAI workloads introduce four asset classes that traditional CSPM tooling does not model: training datasets stored in S3, Azure Blob Storage, or GCP Cloud Storage (frequently overexposed during experimentation phases); model artifacts in pickle-based formats (.pkl, .pt) that execute arbitrary code on deserialization; inference endpoints on SageMaker, Vertex AI, or self-hosted FastAPI servers that default to broad access; and vector databases powering RAG pipelines that inherit the network exposure of the databases they run on.
The 2024 Verizon Data Breach Investigations Report identified misconfigured cloud storage as a contributing factor in 15% of all cloud-related breach incidents analyzed that year. When the exposed bucket contains labeled training data rather than generic application logs, the exposure is not just a compliance failure. It is a data poisoning entry point documented in MITRE ATLAS technique AML.T0020 (Poison Training Data), where an attacker with write access injects adversarial examples that alter model behavior at inference time without triggering any runtime alert.
Four misconfiguration classes account for the majority of GenAI-specific cloud risk. Each maps to a specific CIS or NIST control that most ML teams have not applied to their AI workloads.
Teams frequently attach the AWS managed policy AmazonSageMakerFullAccess during development and never scope it down. That policy grants overly broad permissions, including s3:* on all S3 buckets, iam:PassRole for any role, and ecr:* on all ECR repositories. This violates CIS AWS Foundations Benchmark v3.0 control 1.16, which requires least-privilege IAM policies for service roles. Almost no ML team applies this control to SageMaker execution roles.
An EC2 training instance without HttpTokens: required allows any process on the instance to retrieve the instance profile credentials via 169.254.169.254. CISA’s cloud security technical reference architecture lists IMDSv2 enforcement as a required control for any compute workload handling sensitive data.
A model artifact in a public S3 bucket is a supply chain risk for every team loading that artifact. A malicious pickle payload replacing the legitimate weight file turns every inference server pulling from that bucket into a remote code execution target on the next reload.
The default SageMaker endpoint configuration does not restrict callers by VPC. Without a resource-based policy explicitly denying calls from outside the account, the endpoint accepts requests from any authenticated AWS principal globally.
One common attack chain begins when a development team stores labeled fine-tuning data in an S3 bucket with BlockPublicAcls: false, attaches AmazonSageMakerFullAccess to the training job role, and does not enforce IMDSv2 on the training instance.
Step 1: An attacker discovers the exposed bucket using public S3 enumeration, documented in MITRE ATLAS technique AML.T0037 (Search for Victim’s Publicly Available Research).
Step 2: If the bucket has write access via a misconfigured policy, the attacker injects adversarially labeled examples into the training dataset before the next run. This alters model behavior at inference time without triggering a runtime alert.
Step 3: If IMDSv2 is not enforced, a compromised process on the training instance sends a GET request to 169.254.169.254/latest/meta-data/iam/security-credentials/ and retrieves the execution role credentials.
Step 4: With those credentials and s3:* from AmazonSageMakerFullAccess, permissions from AmazonSageMakerFullAccess, the attacker can read every S3 bucket in the account, including production data stores, without interacting with the inference endpoint.
This chain often goes undetected by standard CSPM because no single finding is rated critical. The S3 bucket exposure is high, the IMDSv2 gap is medium, and the overprivileged role is high. No individual alert surfaces the full path from public bucket to account-wide S3 read. Only attack path analysis that correlates all three findings simultaneously exposes the true risk.
CVE-2024-34359 affected the Hugging Face safetensors library prior to version 0.4.3. Under specific loading conditions, the library allowed arbitrary code execution during model deserialization, despite safetensors being designed as a safer alternative to pickle-based formats.
The cloud-specific risk: a model weight file stored in an S3 bucket with public read access and loaded by a SageMaker endpoint running an overprivileged execution role creates a path from a storage misconfiguration to code execution inside the inference environment. The attacker does not need access to the running inference server directly. They only need write access to the bucket storing the model artifact.
Any SageMaker endpoint or self-hosted inference server that pulled safetensors model files from a shared S3 bucket before the library updated to 0.4.3 was vulnerable to this path. Patching the library is the immediate fix. The structural fix is enforcing S3 Object Lock with governance mode on model artifact storage buckets so that no principal with s3:PutObject can overwrite a locked artifact without the additional s3:BypassGovernanceRetention permission, which should be granted to zero service accounts. For a broader framework on managing CVE remediation timelines across cloud workloads, see A Guide to Vulnerability Management.
Standard CSPM coverage misses three GenAI-specific detection requirements.
1. IAM policy evaluation in data context
The scanner must evaluate IAM policies on SageMaker execution roles, Vertex AI service accounts, and Azure ML compute cluster managed identities against least privilege, with awareness of which storage buckets those roles can access. A role with iam:PassRole and read access to a PII training bucket is a critical finding. Without modeling the relationship between role permissions and data sensitivity, CSPM generates high-severity alerts that look identical to dozens of other role findings, with no connection to sensitive assets.
2. Data classification–aware misconfiguration detection
The scanner must classify bucket contents by data type—PII, PHI, financial records, proprietary model weights—and surface misconfiguration findings in that context. A public bucket containing log files is a medium-severity issue. The same misconfiguration on a bucket containing 50,000 labeled medical images used for fine-tuning is critical, with compliance implications under HIPAA Security Rule section 164.312(a)(2)(iv).
3. ML endpoint exposure analysis
The scanner must evaluate SageMaker endpoint resource-based policies, Vertex AI model IAM bindings, and Azure ML endpoint authentication configurations. An endpoint that accepts unauthenticated requests, or requests from outside the owning account’s VPC, is effectively internet-exposed even without a public URL. This check does not exist in CIS AWS Foundations Benchmark v3.0 because the benchmark predates widespread SageMaker endpoint deployment.
Reviews of GenAI deployments across AWS, Azure, and GCP environments consistently show a gap between intended configurations and what is actually running. This gap is often wider for ML workloads than for other workload classes.
A practical starting point for GenAI security reviews is the IAM execution role attached to the training job rather than the storage bucket. Bucket misconfigurations are visible and frequently flagged, while role misconfigurations are often missed by CSPM tools and carry a larger blast radius.
Recommended sequence before any GenAI workload moves to production:
AmazonSageMakerFullAccess with a scoped policy granting s3:GetObject and s3:ListBucket on the exact bucket ARN and prefix for that training job only. Remove iam:PassRole unless the job explicitly requires it.HttpTokens: required on all EC2 training instances at launch. Apply an AWS Organizations SCP denying ec2:RunInstances where MetadataHttpTokens is not set to required. This prevents any team from launching a training instance without IMDSv2 enforcement.aws:SourceVpc with the specific VPC ID.s3:BypassGovernanceRetention, which should be granted to zero service accounts.For reference on MITRE ATLAS techniques, attack path terminology, and NIST AI RMF controls referenced in these steps, see the Orca Security Glossary.
Orca Security detects GenAI-specific cloud risks by reading workload configurations, IAM policy documents, and storage bucket metadata directly from cloud provider APIs and block storage snapshots using agentless SideScanning™, without requiring an agent on the training instance or inference endpoint.
Orca Security’s attack path analysis correlates SageMaker execution role permissions with the sensitivity classification of the S3 buckets those roles can access. The result is a single prioritized finding showing the full chain from overprivileged role to sensitive training data, rather than two separate medium and high severity alerts with no visible connection.
Orca Security flags IMDSv2 enforcement status on EC2 instances running GPU workloads, and includes the instance profile’s effective permissions in the finding context. The full credential theft path, from missing HttpTokens: required to account-wide S3 read via the stolen execution role, appears in a single view. Inference endpoint exposure is detected by evaluating SageMaker endpoint resource-based policies against Orca Security’s internet exposure model. An endpoint with no aws:SourceVpc condition is classified as internet-exposed regardless of whether it has a public DNS entry.For further reading on cloud-native security practices and AI security frameworks, visit the Orca Security Cloud Security Learning Hub. Teams running GenAI workloads on AWS, Azure, or GCP can see the full attack path map for their environment at Orca Security or Get a Demo.
What are the main GenAI risk categories in cloud environments?
GenAI cloud risks fall into four categories: training data poisoning via misconfigured storage buckets, model artifact tampering through exposed model weight files, unauthenticated inference endpoint access, and overprivileged ML service roles enabling lateral movement from a compromised training job to production data stores.
How do attackers poison training data in cloud-hosted AI workloads?
Attackers use MITRE ATLAS technique AML.T0020 (Poison Training Data). If a training dataset stored in S3 or GCS has write permissions granted to overly broad principals, an attacker injects adversarially labeled examples before the next training run, altering model behavior at inference time without triggering any runtime alert.
Why is IMDSv2 enforcement critical for SageMaker training instances?
Without HttpTokens: required, any process on the EC2 training instance retrieves the instance profile credentials via a GET request to 169.254.169.254. If the execution role has s3:* permissions, those credentials give an attacker read access to every S3 bucket in the account.
What IAM permissions should a SageMaker execution role have?
The execution role should be scoped to s3:GetObject and s3:ListBucket on the specific bucket ARN and prefix for that training job. AmazonSageMakerFullAccess, which grants s3:* and iam:PassRole to any role, should never be attached to a production training job.
How does attack path analysis detect GenAI risks that standard CSPM misses?
Standard CSPM scores each misconfiguration independently. Attack path analysis correlates an overprivileged ML service role, the sensitivity of the storage buckets that role can access, and the network exposure of the inference endpoint into a single prioritized chain. Findings rated medium and high in isolation frequently rate critical when the full chain is visible.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。