AWS Bedrock is Amazon's platform for building AI-powered applications. It gives developers access to foundation models and the tools to connect those models directly to enterprise data and systems. That connectivity is what makes it powerful – but it’s also what makes Bedrock a target. When an AI agent can query your Salesforce instance, trigger a Lambda function, or pull from a SharePoint knowledge base, it becomes a node in your infrastructure - with permissions, with reachability, and with paths that lead to critical assets. The XM Cyber threat research team mapped exactly how attackers could exploit that connectivity inside Bedrock environments. The result: eight validated attack vectors spanning log manipulation, knowledge base compromise, agent hijacking, flow injection, guardrail degradation, and prompt poisoning. In this article, we’ll walk through each vector - what it targets, how it works, and what an attacker can reach on the other side. The XM Cyber threat research team analyzed the full Bedrock stack. Each attack vector we found starts with a low-level permission...and potentially ends somewhere you do not want an attacker to be. Bedrock logs every model interaction for compliance and auditing. This is a potential shadow attack surface. An attacker can often just read the existing S3 bucket to harvest sensitive data. If that is unavailable, they may use bedrock:PutModelInvocationLoggingConfiguration to redirect logs to a bucket they control. From then on, every prompt flows silently to the attacker. A second variant targets the logs directly. An attacker with s3:DeleteObject or logs:DeleteLogStream permissions can scrub evidence of jailbreaking activity, eliminating the forensic trail entirely. Bedrock Knowledge Bases connect foundation models to proprietary enterprise data via Retrieval Augmented Generation (RAG). The data sources feeding those Knowledge Bases - S3 buckets, Salesforce instances, SharePoint libraries, Confluence spaces - are direc