You penetration test the cloud infrastructure around AI workloads like AWS Bedrock, Vertex AI or SageMaker by scoping the identity, network, and data plane that surrounds the managed model, not the model itself. Concretely, an AWS Bedrock penetration test maps and exercises the IAM roles that call the service, the instance and container metadata that hand out credentials, the network isolation between the AI stack and the rest of your account, the data paths into and out of the model, and the logging that would catch an attacker. The managed service is Amazon's problem. Everything you wired around it is yours, and that is where breaches happen.
The numbers back this framing. In IBM's Cost of a Data Breach 2025, 13% of organizations reported a breach of an AI model or application, and 97% of those breached organizations lacked proper AI access controls (IBM Cost of a Data Breach 2025). Access control, not prompt cleverness, is the dominant failure mode. This guide is a scoping decision aid for a team deploying AI on cloud that needs to scope an IAM and infrastructure test, and it deliberately stays at the level of a scope map and a what-to-test checklist rather than an attack walkthrough.
TL;DR
What it is (2026): an infrastructure and IAM pentest of the cloud around a managed AI service, covering execution roles, metadata, network isolation, data paths, and logging.
Top scope priority: the identity blast radius. 13% of organizations reported an AI model or application breach and 97% of those lacked AI access controls (IBM Cost of a Data Breach 2025).
Most common weak point: stale credentials. 59% of AWS IAM users had an access key older than one year (Datadog 2025 State of Cloud Security).
Policy guardrail: AWS permits customer testing of a defined service list with no prior approval and prohibits disruptive techniques (AWS Penetration Testing policy).
Not in this scope: prompt injection, jailbreaks, and model output safety. That is model and prompt red teaming, a separate engagement.
Key takeaways
The scope is the cloud, not the model. An AWS Bedrock penetration test targets the IAM roles, network paths, and data stores your application uses to reach the model. The foundation model and its hosting are provider-managed and out of scope.
Identity is the first thing to map, and usually the weakest. Compromised-credential breaches averaged US$4.67M (IBM Cost of a Data Breach 2025), and stale keys are everywhere (Datadog 2025 State of Cloud Security). Execution roles that can read every S3 bucket are the finding you should expect.
Provider policy is a hard boundary, not a suggestion. Testing has to respect the AWS, Google Cloud, and Azure penetration testing rules. Scoping this up front keeps the engagement clean.
Bedrock, SageMaker, and Vertex AI share one scope map. The service names and API surfaces differ, but IAM, metadata, network, data, and logging are the constant five surfaces to test.
The core question: what an AWS Bedrock penetration test actually covers
Managed AI services move a large chunk of the stack behind the provider boundary. With Amazon Bedrock you do not run the GPU fleet, patch the inference servers, or hold the model weights. What you do own is the identity and plumbing that connects your application to the service: the IAM execution role that calls bedrock:InvokeModel, the VPC endpoint that keeps that traffic private, the KMS key that encrypts the knowledge base, the S3 bucket that holds your retrieval documents, and the CloudTrail configuration that is supposed to record all of it.
That ownership split is the whole point of the test. An attacker who lands in your account through a leaked key, an over-permissioned CI role, or an exposed workload does not attack the model. They follow the identity and network paths you built until they can invoke the model on your bill, read the data you fed it, or quietly exfiltrate a knowledge base. A cloud penetration test of the AI stack asks one blunt question: how far can someone get, and what can they reach, once they are inside the perimeter around Bedrock, SageMaker, or Vertex AI.
The AI infrastructure scope map
Five surfaces make up the scope of an AI infrastructure pentest. They are the same five whether the managed service is Bedrock, SageMaker, or Vertex AI. Fix these on the statement of work and the rest of the engagement follows.
1. IAM roles and identity boundaries
This is where the test starts and where most of the findings live. The tester enumerates the roles that touch the AI service: the application execution role, the SageMaker notebook and training roles, the Bedrock agent role, and any CI or automation principal that deploys or invokes them. The work is to trace trust policies, look for privilege-escalation paths (a role that can pass a more privileged role, or edit its own policy), and confirm that least privilege actually holds. A SageMaker IAM attack path usually looks like a notebook role that can read training data, assume a broader role, and reach production storage. That chain is the deliverable, not a single misconfigured action.
2. Instance and container metadata
Compute that runs near the model hands out credentials through the instance metadata service. A SageMaker notebook, a training job, an ECS task, or a Lambda that orchestrates a Bedrock agent all carry a role, and that role's credentials are reachable from the workload. The test checks whether IMDSv2 is enforced, how far the execution-role credentials reach if the workload is compromised, and whether a server-side request forgery in the application layer could pull those credentials. Metadata is the classic bridge from an application bug to full cloud credentials.
3. Network isolation and egress
Managed AI services can be reached over the public internet or over private endpoints. The test verifies that Bedrock and SageMaker traffic uses VPC endpoints (PrivateLink) rather than traversing the open internet, that the AI subnets are isolated from unrelated workloads, that security groups do not expose notebooks or inference endpoints, and that egress is controlled so a compromised workload cannot ship data to an attacker-controlled destination. Egress control is what turns a data-read into a non-event.
4. Data paths and keys
AI stacks are data magnets. Retrieval-augmented generation pulls from S3 buckets and vector stores, training jobs read labeled datasets, and fine-tuning produces model artifacts that are themselves sensitive. The test follows every data path: KMS key policies and who can decrypt, bucket policies on the retrieval and artifact stores, and access control on the vector database. If you run RAG, vector store and knowledge-base access control is a first-class part of the scope, because a leaky index quietly exposes everything the model was grounded on.
5. Logging and detection
The last surface is whether anyone would notice. The test confirms that CloudTrail captures the control-plane calls, that Bedrock model invocation logging is on, that SageMaker and data-access events reach a log destination the security team actually watches, and that alerting fires on the paths the test just walked. A finding is worth more when it comes with the observation that nothing detected it.
AWS Bedrock penetration testing vs. model and prompt red teaming
The most common scoping mistake is conflating two different engagements. An AI infrastructure pentest and a model red team answer different questions, need different skills, and produce different reports.
A cloud infrastructure and IAM pentest, the subject of this guide, asks whether an attacker who reaches your cloud can pivot into or exfiltrate the AI stack. It works on roles, metadata, networks, keys, and logs. Model and prompt red teaming asks whether the model itself can be manipulated into unsafe or unauthorized behavior through prompt injection, jailbreaks, training-data poisoning, guardrail bypass, or retrieval-boundary abuse. Both matter. Many production AI deployments need both. But they are scoped, priced, and staffed separately, and a statement of work that blurs them tends to under-deliver on one side. When you request AWS Bedrock penetration testing, be explicit about which one you mean.
Staying inside cloud provider pentest policy
Testing managed services means testing on someone else's platform, so provider rules apply. On AWS, customers may run penetration tests against a defined list of services without requesting prior approval, and Amazon's policy explicitly prohibits disruptive techniques such as denial of service, DNS zone walking through Route 53, port and protocol flooding, and request flooding (AWS Penetration Testing policy). Simulated events like red-team command-and-control require a form submission first. Google Cloud and Microsoft Azure publish comparable rules of engagement.
The practical takeaway for scoping is simple. An AI infrastructure pentest lives almost entirely in your own account against your own configuration: IAM, VPC, KMS, S3, and the workloads you deployed. That is squarely inside acceptable-use policy. The scoping conversation should still confirm the target service list, exclude the prohibited techniques by name, and record the account IDs and time window, so nothing about the engagement looks like an attack on the platform itself. Getting this right is part of scoping any penetration test, and it is easy when it is decided before work starts.
Bedrock, SageMaker, and Vertex AI: what changes by platform
The scope map is constant. What varies is the API surface and the specific identity and data objects you enumerate.
Surface | Amazon Bedrock | Amazon SageMaker | Google Vertex AI |
|---|---|---|---|
Identity | Bedrock invocation and agent execution roles | Notebook, training, and endpoint execution roles | Service accounts and IAM bindings |
Compute metadata | Lambda and ECS/Fargate task roles orchestrating agents | Notebook and training-job instance roles via IMDS | Compute Engine and Vertex custom-job service accounts |
Network | VPC endpoints (PrivateLink) for Bedrock APIs | VPC-attached notebooks and endpoints | VPC Service Controls and Private Service Connect |
Data paths | Knowledge bases on S3, vector stores, KMS | Training data in S3, model artifacts, feature store | Cloud Storage buckets, BigQuery, managed datasets |
Logging | CloudTrail, model invocation logging | CloudTrail, SageMaker events | Cloud Audit Logs |
A Vertex AI cloud security assessment reads differently on paper because Google uses service accounts, VPC Service Controls, and Cloud Audit Logs where AWS uses execution roles, VPC endpoints, and CloudTrail. Under the labels, the tester is doing the same five things: mapping identity, checking metadata reach, verifying isolation, following data, and confirming detection.
What drives the cost of an AI infrastructure pentest
Cost scales with scope, and the scope of an AI infrastructure test is set by a handful of variables. Use these to size the engagement before asking for a number.
Account and environment count. One account with one AI service is a small engagement. A multi-account organization with separate dev, staging, and production estates multiplies the identity graph to trace.
Number and type of AI services. Testing Bedrock alone is narrower than testing Bedrock plus SageMaker plus a self-managed vector database plus an agent framework.
Data-store breadth. Every S3 bucket, vector index, feature store, and KMS key in the data path adds surface. RAG deployments with large retrieval corpora take longer to map.
White-box vs. black-box. A configuration-informed test with read access to IAM and Terraform is faster and deeper than a blind assessment. Most AI infrastructure tests are white-box because the goal is coverage, not stealth.
Agentic and integration complexity. AI agents that can call tools, trigger workflows, or reach other cloud services widen the blast radius and the scope.
Stingrai's penetration testing is scoped per environment, and pricing follows the variables above. See the Stingrai pricing page for current packages rather than working from a rule of thumb.
Your AI infrastructure pentest scoping checklist
Bring these answers to the scoping call and the statement of work writes itself.
List the managed AI services in scope: Bedrock, SageMaker, Vertex AI, or a mix, plus any self-managed model or vector store.
Name the accounts and the time window, and confirm they are yours to test.
Inventory the execution roles and service accounts that call the AI services, including CI and automation principals.
Map the data paths: retrieval buckets, vector stores, training data, model artifacts, and the KMS keys over them.
Confirm network topology: public vs. private endpoints, subnet isolation, and egress controls.
Decide white-box vs. black-box and arrange read access to IAM and infrastructure-as-code if white-box.
Exclude the prohibited techniques by name to stay inside provider policy.
State the deliverable: a scope map, an exploited attack-path narrative for each finding, remediation, and logging-gap notes.
Separate model red teaming into its own scope if you also need it.
Confirm the compliance context (SOC 2, ISO 27001, or similar) so the report supports the evidence you need.
What this means for teams deploying AI on cloud
The uncomfortable message from the 2025 data is that AI adoption outran AI access control. Shadow AI alone was implicated in 20% of breaches and added roughly US$670K to the average cost (IBM Cost of a Data Breach 2025). For a team standing up Bedrock, SageMaker, or Vertex AI, a few decisions pay for themselves.
Test the infrastructure before the model. The identity and data plane is where the measured breaches happened. Scope that first.
Treat execution roles as the crown jewels. Enforce least privilege, kill stale keys, and require IMDSv2 on every workload near the model.
Make the AI data path a named asset. Buckets, vector stores, and KMS keys deserve the same review as a production database.
Feed findings into your compliance evidence. A cloud infrastructure pentest of the AI stack produces the kind of evidence that supports a SOC 2 or ISO 27001 program.
Stingrai runs this as human cloud-penetration-testing work. Our specialists map the IAM and infrastructure around your managed AI services and exploit the paths that matter, then hand you a scope map, an attack-path narrative, and remediation. This is deliberately distinct from two other things people call "AI testing": it is not our autonomous web-application agent Snipe, which hunts complex web bugs like IDOR and broken authorization in application code, and it is not model or prompt red teaming. If you need adversary emulation and red teaming that carries a cloud AI objective, or a continuous PTaaS program that retests as your AI footprint grows, those are the natural next steps.
Frequently Asked Questions
How do you penetration test the cloud infrastructure around AI workloads like AWS Bedrock, Vertex AI or SageMaker?
You scope and test the identity, network, and data plane around the managed service rather than the model. That means enumerating the IAM roles and service accounts that call the AI service, checking instance and container metadata for credential reach, verifying network isolation and egress, following the data paths through S3, vector stores, and KMS, and confirming that logging would catch an intruder. The foundation model and its hosting stay out of scope because the provider owns them.
What is the difference between an AI infrastructure pentest and model or prompt red teaming?
An AI infrastructure pentest asks whether an attacker who reaches your cloud can pivot into or exfiltrate the AI stack, and it works on roles, metadata, networks, keys, and logs. Model and prompt red teaming asks whether the model can be manipulated into unsafe or unauthorized behavior through prompt injection, jailbreaks, or guardrail bypass. They are separate engagements with separate skills, and many production deployments need both.
What should the scope of an AWS Bedrock penetration test include?
Five surfaces: IAM roles and identity boundaries, instance and container metadata, network isolation and egress, data paths and keys, and logging and detection. In Bedrock terms that is the invocation and agent execution roles, the Lambda or ECS task roles that orchestrate agents, VPC endpoints, the S3 knowledge bases and vector stores with their KMS keys, and CloudTrail plus model invocation logging.
Is a SageMaker IAM attack path in scope for an infrastructure pentest?
Yes. Mapping SageMaker IAM attack paths is core scope. A typical chain is a notebook or training role that can read sensitive data, assume a broader role, and reach production storage. The test traces these privilege-escalation paths and reports the full chain, not just a single over-permissioned action.
Can you pentest AWS Bedrock without breaking AWS policy?
Yes. AWS permits customer penetration testing against a defined list of services without prior approval and prohibits disruptive techniques such as denial of service, DNS zone walking, and request flooding (AWS Penetration Testing policy). An AI infrastructure test lives in your own account against your own IAM, network, and data configuration, which is squarely inside acceptable use. Scoping simply confirms the service list, excludes the prohibited techniques, and records the accounts and time window.
How much does an AI infrastructure penetration test cost?
Cost scales with scope: how many accounts and AI services are in play, how broad the data stores are, whether the test is white-box or black-box, and how complex your agentic integrations are. A single Bedrock deployment in one account is a small engagement, while a multi-account estate with SageMaker, a vector database, and agents is larger. See the Stingrai pricing page for current packages.
Does a Vertex AI cloud security assessment differ from an AWS Bedrock one?
The vocabulary differs, the method does not. Google Cloud uses service accounts, VPC Service Controls, Private Service Connect, and Cloud Audit Logs where AWS uses execution roles, VPC endpoints, and CloudTrail. A Vertex AI cloud security assessment still maps identity, checks metadata reach, verifies network isolation, follows the data, and confirms detection.
How does an AI infrastructure pentest support SOC 2 or ISO 27001?
A cloud infrastructure pentest of your AI stack produces evidence that supports a SOC 2 or ISO 27001 program, including access-control validation, network segmentation checks, and logging coverage. Stingrai's penetration testing generates that pentest evidence for your compliance audits.
How often should we test the cloud infrastructure around our AI stack?
Test at least annually and after any material change: a new AI service, a new account, a new data store in the retrieval path, or a new agent integration. AI footprints change quickly, so a continuous testing model retests as the environment grows rather than leaving a year-long gap.
References
IBM. Cost of a Data Breach Report 2025. July 2025. https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls. Global breach-cost study; source of the 13% AI-breach and 97% missing-access-control figures and the compromised-credential and shadow-AI cost data.
Datadog. State of Cloud Security 2025. October 2025. https://www.datadoghq.com/about/latest-news/press-releases/datadogs-2025-state-of-cloud-security-report-finds-companies-adopting-data-perimeters-amid-growing-concerns-of-credential-theft/. Analysis of cloud security posture across thousands of organizations; source of the long-lived-credential findings.
Amazon Web Services. Penetration Testing. https://aws.amazon.com/security/penetration-testing/. AWS customer support policy defining permitted services for testing and prohibited techniques.
Amazon Web Services. Shared Responsibility Model. https://aws.amazon.com/compliance/shared-responsibility-model/. Defines the provider-versus-customer security boundary that sets the scope of a managed-service pentest.
CISA and NSA. Deploying AI Systems Securely. April 2024. https://www.cisa.gov/resources-tools/resources/deploying-ai-systems-securely. Joint guidance on securing the environment around deployed AI systems, including identity, network, and logging hardening.
