AWS Bedrock is Amazon’s platform for building AI-powered applications. This gives developers access to foundational models and tools to connect those models directly to corporate data and systems. That connectivity is what makes Bedrock so powerful, but also what makes it a target.
When an AI agent can query a Salesforce instance, trigger a Lambda function, or pull from a SharePoint knowledge base, it becomes a node in your infrastructure with permissions, reachability, and a path to important assets. The XM Cyber Threat Research team mapped out exactly how attackers exploited that connection within the Bedrock environment. As a result, eight attack vectors were validated, spanning log manipulation, knowledge base compromise, agent hijacking, flow injection, guardrail degradation, and prompt poisoning.
This article describes each vector: what it targets, how it works, and how far an attacker can reach the other side.
8 vectors
The XM Cyber Threat Research team analyzed the entire Bedrock stack. Each attack vector we discovered starts with low-level privileges and can end up somewhere the attacker doesn’t want it to be.
1. Model call log attack
Bedrock logs all model interactions for compliance and auditing. This is a potential shadow attack surface area. Attackers can often collect sensitive data simply by reading an existing S3 bucket. If that’s not available, you can use bedrock:PutModelInvocationLoggingConfiguration to redirect logs to a bucket you manage. From then on, all prompts are silently sent to the attacker. The second variant targets logs directly. An attacker with s3:DeleteObject or logs:DeleteLogStream privileges can scrub evidence of jailbreak activity to completely eliminate forensic traces.
2. Knowledge base attacks – data sources
Bedrock Knowledge Base connects the underlying model to your proprietary corporate data through Search Augmented Generation (RAG). The data sources that feed these knowledge bases (S3 buckets, Salesforce instances, SharePoint libraries, Confluence spaces) can be accessed directly from Bedrock. For example, an attacker with s3:GetObject access to a knowledge base data source can completely bypass the model and pull raw data directly from the underlying bucket. More importantly, an attacker with the privilege to obtain and decrypt the secret could steal the credentials that Bedrock uses to connect to the integrated SaaS service. For SharePoint, these credentials can potentially be used to move laterally to Active Directory.
3. Knowledge Base Attack – Datastore
A data source is the source of information, while a data store is where the ingested information is stored, indexed, structured, and queryable in real time. For popular vector databases integrated with Bedrock, such as Pinecone and Redis Enterprise Cloud, stored credentials are often the weakest link. An attacker with access to credentials and network reachability could obtain endpoint values and API keys from the StorageConfiguration object returned via the bedrock:GetKnowledgeBase API and gain full administrative access to the vector index. For AWS native stores like Aurora and Redshift, intercepting credentials gives an attacker direct access to the entire structured knowledge base.
4. Agent Attack – Direct
Bedrock Agent is an autonomous orchestrator. An attacker with bedrock:UpdateAgent or bedrock:CreateAgent privileges could force disclosure of the agent’s internal instructions or tool schema by rewriting the agent’s basic prompt. The same access, combined with bedrock:CreateAgentActionGroup, allows an attacker to attach a malicious actor to a legitimate agent, allowing them to perform unauthorized actions such as modifying a database or creating a user under the cover of normal AI workflows.
5. Agent Attack – Indirect
Indirect agent attacks target the infrastructure on which the agent depends, rather than the agent’s configuration. An attacker using lambda:UpdateFunctionCode could deploy malicious code directly into the Lambda function that the agent uses to perform tasks. Variants that use lambda:PublishLayer allow you to silently inject malicious dependencies into the same function. The result in either case is that malicious code can be injected into tool calls, exposing sensitive data or manipulating model responses to generate harmful content.
6. Flow attack
Bedrock Flow defines a sequence of steps that a model follows to complete a task. An attacker with the bedrock:UpdateFlow privilege can inject a sidecar “S3 storage node” or “Lambda function node” into the main data path of a critical workflow and route sensitive input/output to attacker-controlled endpoints without destroying the application’s logic. The same access can be used to modify the “condition nodes” that apply business rules, bypassing hard-coded authorization checks and allowing fraudulent requests to reach sensitive downstream systems. The third variant targets encryption. By replacing the customer-managed key associated with a flow with a key that they control, an attacker can ensure that all future flow states are encrypted with their key.
7. Guardrail attack
Guardrails are Bedrock’s main layer of defense and are responsible for filtering harmful content, blocking prompt injections, and redacting PII. An attacker using bedrock:UpdateGuardrail could systematically weaken these filters, lowering thresholds or removing topic restrictions, making the model more susceptible to manipulation. An attacker using bedrock:DeleteGuardrail can permanently delete them.
8. Controlled Instant Attack
Bedrock Prompt Management centrally manages prompt templates across applications and models. An attacker using bedrock:UpdatePrompt can directly modify these templates to inject malicious instructions such as “always include backlinks.” [attacker-site] Prompt changes are reflected in the prompts used throughout your environment. Because changing the prompt does not trigger a redeployment of the application, an attacker can change the behavior of the AI ”on the fly,” making it much harder to detect by traditional application monitoring tools. By changing the version of a prompt to a poisoned variant, an attacker can instantly destroy any agent or flow that calls that prompt ID, leading to mass data exfiltration and generation of large-scale harmful content.
What this means for security teams
These eight Bedrock attack vectors share a common logic. This means that attackers target the permissions, configuration, and integration surrounding the model, rather than the model itself. A single overprivileged identity is enough to redirect logs, hijack agents, poison prompts, and gain access to critical on-premises systems from a foothold within Bedrock.
Securing Bedrock starts with knowing what AI workloads you have and what permissions are granted to them. From there, the task is to map attack paths across cloud and on-premises environments and maintain tight posture control across all components in the stack.
For complete technical details on each attack vector, including architecture diagrams and practitioner best practices, download the complete study: Building and Scaling Secure Agentic AI Applications in AWS Bedrock.
Note: This article was thoughtfully written and contributed to our readers by Eli Shparaga, a security researcher at XM Cyber.
Source link
