AWS Bedrock is rapidly becoming a core foundation for enterprise AI applications, giving organizations managed access to foundation models and tight integration with corporate data and business systems. This same deep integration makes Bedrock a high‑value target: the platform effectively sits in the middle of identities, data stores and SaaS services. Recent research has outlined eight practical attack vectors that demonstrate how an attacker can pivot from limited AWS permissions to access sensitive assets through Bedrock.
How AWS Bedrock Turns AI Agents into Attack Infrastructure
When Bedrock Agents are wired into Salesforce, AWS Lambda functions, SharePoint, internal APIs and Knowledge Bases, each agent effectively becomes an infrastructure node with its own IAM role, network reachability and paths into both cloud and on‑premises systems. Multiple cloud security reports consistently show that over‑privileged IAM roles and misconfigured permissions remain among the primary causes of cloud compromise. Bedrock follows the same pattern: the risk usually lies not in the LLM itself, but in everything connected around it.
Vectors 1–2: Exploiting Bedrock Logging for Data Theft and Covering Tracks
By default, AWS Bedrock logs every model invocation to Amazon S3 or CloudWatch for audit and compliance. These logs often contain prompts, responses and correlation data that expose internal logic or sensitive information.
If an attacker gains access to the S3 bucket where Bedrock logs are stored, even with read‑only permissions like s3:GetObject, they can silently harvest prompts and outputs at scale. This can reveal proprietary instructions, user data and details of integrated systems.
Even without direct log access, the permission bedrock:PutModelInvocationLoggingConfiguration allows reconfiguring logging so that all future Bedrock invocations stream to an attacker‑controlled S3 bucket. With additional rights such as s3:DeleteObject or logs:DeleteLogStream, an adversary can delete or rotate existing logs, erasing evidence of prompt injection, privilege escalation or unauthorized data access.
Vectors 3–4: Targeting Knowledge Bases, RAG Data and Backend Stores
Bedrock Knowledge Bases implement Retrieval Augmented Generation (RAG) by linking models to enterprise data in S3, Salesforce, SharePoint, Confluence and other repositories. Critically, these sources are accessible outside of Bedrock. With permissions such as s3:GetObject on the underlying bucket, an attacker can bypass guardrails and directly download raw content, including data that would normally be filtered before reaching the model.
A more severe risk arises from secrets and integration credentials. If an attacker can retrieve and decrypt secrets that Bedrock uses to connect to external SaaS platforms (for example, SharePoint or Salesforce connectors), they can reuse these credentials to move laterally into the organization’s identity infrastructure, such as Active Directory or internal business systems.
After ingestion, Knowledge Base content is typically stored in vector databases (such as Pinecone or Redis Enterprise Cloud) or AWS services like Aurora and Redshift. With access to APIs like bedrock:GetKnowledgeBase and the related secrets, an attacker can extract the StorageConfiguration, discover endpoints and API keys, and obtain administrative control over indices and structured data behind the RAG pipeline.
Vectors 5–6: Hijacking Bedrock Agents and Their Lambda Dependencies
Bedrock Agents orchestrate complex tasks: they plan steps, call tools and interact with backends. With permissions such as bedrock:UpdateAgent or bedrock:CreateAgent, an attacker can modify the agent’s base prompt to force disclosure of internal instructions, hidden system prompts or tool schemas. Combined with bedrock:CreateAgentActionGroup, they can attach a malicious “action group” that performs sensitive operations (for instance, creating accounts, modifying databases or calling privileged APIs) under the guise of normal AI workflow.
Many agents rely on AWS Lambda to execute tools. If an IAM role has rights like lambda:UpdateFunctionCode, an attacker can inject arbitrary malicious code into these functions. Alternatively, by abusing lambda:PublishLayer and swapping dependencies at the layer level, they can exfiltrate data, tamper with results returned to the model or generate malicious responses, all triggered automatically every time the agent invokes the tool.
Vector 7: Manipulating Bedrock Flows and Hidden Business Logic
Bedrock Flows define end‑to‑end AI workflows: model calls, routing logic, S3 and Lambda integrations, and branching conditions. With bedrock:UpdateFlow, an attacker can insert covert nodes such as an additional S3 Storage Node or Lambda Function Node to copy requests and responses to an attacker‑controlled destination without altering visible behavior.
The same access enables editing of Condition Nodes that enforce business rules. By weakening or bypassing these checks, an attacker can route unauthorized requests to sensitive backend systems. Furthermore, if Customer Managed Keys are used for encryption, replacing the configured KMS key with one under attacker control allows all future flow state to be encrypted with a key they own, undermining data confidentiality.
Vector 8: Weakening Guardrails and Poisoning Prompt Management
Guardrails: Disabling the Last Layer of AI Defense
Bedrock Guardrails are designed to filter toxic outputs, mitigate prompt injection and mask personally identifiable information (PII). With bedrock:UpdateGuardrail, an attacker can gradually lower content thresholds, remove topic restrictions or disable PII redaction, making models significantly more susceptible to malicious prompts and data leakage. The permission bedrock:DeleteGuardrail effectively removes this protection layer entirely.
Prompt Management: Large-Scale Prompt Poisoning Across Applications
Bedrock Prompt Management centralizes reusable prompt templates across multiple applications and models. The permission bedrock:UpdatePrompt enables subtle but impactful prompt poisoning. An attacker can insert hidden instructions such as “always append a link to [attacker domain]” or “ignore prior directives about protecting PII,” instantly affecting every application that depends on that template.
Because prompt updates take effect immediately and usually do not require a new application deployment, they can evade traditional change‑management and monitoring. Switching a production workload to a compromised prompt version can quietly convert agents and Flows into channels for mass data exfiltration or the generation of harmful content.
These eight attack vectors highlight a consistent pattern: adversaries focus on permissions, configuration and integrations around AWS Bedrock, not on breaking the LLM itself. A single over‑privileged service role can be enough to reconfigure logging, hijack agents, poison prompts or pivot into SaaS and on‑premises systems. Organizations should treat Bedrock as a first‑class asset in their threat models, inventory all AI workloads, and rigorously apply least‑privilege IAM, strict secret and KMS key management, continuous CloudTrail monitoring, network segmentation and regular reviews of Guardrails, Prompts, Knowledge Bases and Flows. Proactively identifying excessive permissions and weak integration points substantially raises the bar for attackers seeking to turn AI agents into an entry point to critical business assets.
