The XM Cyber threat research team identified eight distinct attack vectors in AWS Bedrock environments. None of these exploits rely on zero-days or novel techniques. They all hinge on a single point of failure: overprivileged identities with access to AI workload components.
This isn't theoretical. If you're running AI applications on Bedrock, your attack surface now includes logs, knowledge bases, agents, flows, guardrails, and prompts. Each component becomes a pivot point when permissions aren't scoped correctly.
Identified Attack Vectors
XM Cyber mapped attack paths through AWS Bedrock by examining how an attacker with initial access could escalate privileges and move laterally. The research identified eight vectors:
- Log manipulation
- Knowledge base compromise
- Agent hijacking
- Flow injection
- Guardrail degradation
- Prompt poisoning
- Two additional vectors targeting the connectivity between Bedrock components
These aren't vulnerabilities in Bedrock itself. They're architecture problems that arise when you grant broad IAM permissions to identities interacting with AI workloads.
Attack Sequence
While XM Cyber's research doesn't document a specific incident, the attack pattern follows a predictable sequence:
Initial access: An attacker compromises a service account, EC2 instance role, or developer credential with some level of Bedrock access.
Reconnaissance: The attacker enumerates permissions using bedrock:List* and bedrock:Get* API calls to map available resources.
Lateral movement: Using overprivileged write permissions, the attacker modifies logs to hide activity, poisons prompts to manipulate AI outputs, or injects malicious flows.
Data access: Through compromised knowledge bases or agents, the attacker retrieves sensitive data the AI application was designed to process.
Persistence: The attacker maintains access by creating new agents, modifying guardrails, or embedding backdoors in flows.
The entire chain depends on permissions that shouldn't exist in the first place.
Failed Controls
The core failure is excessive IAM permissions. Specifically:
Lack of least privilege enforcement: Identities had bedrock:* or broad wildcard permissions instead of scoped access to specific resources.
No resource-based policies: Knowledge bases, agents, and flows lacked resource policies that restrict which identities can modify them.
Insufficient logging and monitoring: Teams weren't alerting on sensitive Bedrock API calls like UpdateAgent, ModifyKnowledgeBase, or PutGuardrail.
Weak boundary controls: No service control policies (SCPs) or permission boundaries limited what Bedrock-related actions were possible, even for privileged roles.
Missing data classification: Teams didn't map which knowledge bases contained sensitive data, so they couldn't apply stricter controls to high-risk resources.
Compliance Standards
NIST 800-53 Rev 5, AC-6 (Least Privilege): "Employ the principle of least privilege, allowing only authorized accesses for users which are necessary to accomplish assigned organizational tasks."
For Bedrock, this means your CI/CD pipeline that deploys agents needs bedrock:CreateAgent and bedrock:UpdateAgent on specific agent ARNs. It doesn't need bedrock:DeleteKnowledgeBase or access to production knowledge bases.
ISO 27001, Control 8.2 (Privileged Access Rights): Organizations must restrict and control the allocation and use of privileged access rights. In practice, this means maintaining an inventory of which roles can modify AI components and reviewing those permissions quarterly.
SOC 2 Type II, CC6.3 (Logical Access Controls): The entity implements logical access security measures to protect against threats from sources outside its system boundaries. This directly applies to ensuring external attackers can't pivot through overprivileged Bedrock identities.
NIST Cybersecurity Framework v2.0, PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties. You need different IAM roles for deploying agents, querying knowledge bases, and modifying guardrails.
Actionable Steps
Audit your current Bedrock IAM policies. Run aws iam get-policy-version for every policy that includes bedrock:* actions. Look for wildcards in the Action and Resource fields. If you find "Action": "bedrock:*", you have work to do.
Implement resource-specific permissions. Replace broad grants with targeted policies:
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeAgent"
],
"Resource": "arn:aws:bedrock:us-east-1:123456789012:agent/AGENT_ID"
}
Set up CloudTrail monitoring. Create EventBridge rules that alert on UpdateAgent, ModifyKnowledgeBase, PutGuardrail, and DeleteAgent API calls. These should trigger in real-time, not get buried in daily log reviews.
Use permission boundaries. Apply permission boundaries to roles that need any Bedrock access. This creates a maximum permission set that can't be exceeded, even if someone attaches additional policies.
Map your AI data flows. Document which knowledge bases contain PII, financial data, or other sensitive information. Apply stricter IAM controls and enable S3 bucket encryption for the underlying data stores.
Separate deployment from runtime permissions. Your deployment pipeline needs bedrock:CreateAgent and bedrock:UpdateAgent. Your application runtime only needs bedrock:InvokeAgent. Use different IAM roles.
Enable AWS Config rules. Set up rules to detect when Bedrock resources are created or modified. Configure automatic remediation to revert unauthorized changes.
Review third-party integrations. If you've granted external services access to Bedrock, audit what permissions they actually need. Most integrations request far more access than they use.
The attack vectors XM Cyber identified aren't exotic. They're the predictable result of treating AI workloads like any other cloud service and granting permissions without thinking through the attack paths. Your Bedrock environment is only as secure as your least privileged identity.
