Amazon Bedrock Agents Security Risks

Custom Workflow Agents aws.amazon.com Humble Providers
AI RISK QUADRANT POSITION DEFENSE CONTROLS (4) ATTACK SURFACE (4.92) EXPOSED GIANTS FORTIFIED LEADERS HUMBLE PROVIDERS TIGHT OPERATORS
AIRQ Score
3.65
Critical
Attack Surface
4.92
Medium
Blast Radius
4.63
Medium
Defense Controls
4
High
About The Agent

Amazon Bedrock Agents is a managed AI agent orchestration service within AWS that provisions per-session execution environments, connects to customer-defined tool integrations via Action Groups, and delegates reasoning to configurable foundation models. Deployed as a fully cloud-hosted service under the AWS shared responsibility model, the primary risk surface centers on the absence of default input and output guardrails combined with autonomous tool invocation that fires without per-action human approval.

About the AI Risk Quadrant

Humble Providers placement reflects moderate blast radius capped by IAM-scoped Lambda execution and absence of direct host access, paired with an attack surface near the quadrant threshold driven by trifecta-complete status. Defense controls score low because only execution isolation is active by default while all guardrail components require explicit activation. Operators should prioritize guardrail enablement to shift the defense posture before the attack surface pushes into the adjacent quadrant.

1 Key Risks

The most critical security risks an operator inherits when deploying this agent in its documented default configuration. Amazon Bedrock Agents presents a trifecta-complete risk posture on default configuration where all guardrail components require explicit activation while execution isolation is the only defense layer active without operator intervention.

Key Input Risks
Agents ingest untrusted natural-language prompts via the InvokeAgent API and external documents from Knowledge Bases backed by S3 and web crawl sources. No default prompt-injection detection is active; Guardrails require explicit opt-in activation per agent. [10]
Key Execution Risks
Reasoning is delegated to a configurable foundation model with no runtime constraints on chain-of-thought manipulation or goal decomposition. AgentCore Runtime provides per-session microVM isolation for the execution environment but the reasoning layer itself has no documented integrity controls. [8]
Key Action Risks
Action Groups invoke Lambda functions autonomously based on LLM reasoning without per-action operator approval on default configuration. User confirmation is available but disabled by default, allowing all defined tools to fire without human review. [10]
Key Output Risks
Agent responses and tool outputs flow to the caller without default DLP, PII redaction, or URL sanitization. Output Guardrails are available but require the same explicit configuration and agent association as input Guardrails. [9]
Key Monitoring Risks
No built-in anomaly detection or automated SIEM forwarding is active by default; CloudTrail logs API-level invocations but agent-internal reasoning traces and tool call payloads require opt-in CloudWatch Logs configuration. [8]

2 AIRQ Scores

The four headline scores quantify how exposed the agent is, how damaging a successful attack would be, and how much the agent’s own controls reduce that risk. The composite AIRQ score reflects moderate defense-adjusted capability constrained by a near-threshold attack surface and limited default safeguards.

AIRQ Metrics

Amazon Bedrock Agents lands in the Humble Providers quadrant with Attack Surface 4.92 (borderline, within 0.10 of the threshold), Blast Radius 4.63, and Defense Controls 4.

Attack Surface and Blast Radius are scored out of 10, Defense Controls out of 15, and the composite AIRQ score out of 15.

Metric Score Comments
AIRQ Score 3.65 Moderate composite indicating limited capability per unit of risk driven by low defense multiplier on default configuration.
Blast Radius 4.63 / 10 Moderate blast ceiling bounded by IAM-scoped Lambda execution and absence of direct infrastructure access on default deployment.
Attack Surface 4.92 / 10 Near-threshold score driven by trifecta-complete status with evidence-backed penalties on six of ten attack surfaces.
Defense Controls 4 / 15 Only microVM isolation via AgentCore Runtime scores above zero on default config; all guardrail and monitoring components require explicit operator activation.

3 Attack Surface

Attack surfaces are the entry points and interaction patterns through which adversarial input can reach the agent’s reasoning loop and steer its behavior. The agent's reasoning loop ingests untrusted user prompts, external documents from Knowledge Bases, and inter-agent messages as first-class input on default configuration.

Attack Surface Metrics

Higher scores indicate surfaces where attacker-controlled bytes reach the reasoning loop with fewer mitigations or where demonstrated exploitation exists.

Each row maps an attack surface to its adjusted score and a one-line analyst comment citing the evidence basis for the score.

Surface Score Comments
User Input 3 / 4 Agents accept unfiltered natural-language prompts via InvokeAgent API with no default injection detection; vendor documents indirect prompt injection as a known vector. [10]
External Data 3 / 4 Knowledge Bases ingest documents from S3 and web crawl sources without default content sanitization; vendor acknowledges external data as an injection surface. [10]
Memory 2 / 4 Session memory is enabled by default with optional persistent memory; independent research demonstrated memory-based persistence of injected instructions across sessions. [5][6]
Reasoning 3 / 4 Foundation model reasoning is model-agnostic with no chain-of-thought verification or goal-boundary enforcement; orchestration delegates goal decomposition entirely to the LLM. [10]
Planning 2 / 4 Multi-step plan execution follows configurable orchestration patterns with planning scope bounded by the Action Groups defined for the agent. [11]
Tool Execution 2 / 4 Action Groups invoke Lambda functions with IAM-scoped permissions; execution boundary is the Lambda runtime rather than a dedicated agent sandbox. [8]
Orchestration 2 / 4 Single-agent orchestration uses a fixed prompt template with configurable system instructions; prompt structure is documented and operator-extensible. [11]
Inter-Agent 3 / 4 Multi-Agent Collaboration enables supervisor-to-collaborator delegation with message passing; independent research demonstrated injection traversing multi-agent hierarchies. [4][12]
Output Processing 2 / 4 Agent responses pass through to the caller without default output filtering; tool output is re-ingested into the reasoning loop without sanitization. [10]
Configuration 2.5 / 4 S3 ownership bypass vulnerability in AgentCore Starter Toolkit allowed remote code injection during build with CVSS 5.8; patched in v0.1.13. [1][2][3]

The Lethal Trifecta is triggered when an agent processes untrusted content, accesses private data, and communicates externally in the same session — the three conditions that turn an isolated prompt injection into full-chain exfiltration. Amazon Bedrock Agents ingests untrusted prompts and external documents into its reasoning loop, accesses customer enterprise data through Knowledge Bases and Action Groups, and transmits bytes externally through Lambda-backed tool invocations that perform outbound HTTP requests.

Lethal Trifecta · Complete (3 of 3)

Amazon Bedrock Agents exhibits all three of these conditions in its documented default configuration:

  • Untrusted input — User prompts via the Bedrock API and retrieved documents from Knowledge Base data sources pull untrusted bytes into the reasoning loop without default filtering. [10]
  • Sensitive data — Knowledge Bases access enterprise documents in S3 and Action Groups invoke Lambda functions scoped to customer databases and internal APIs. [8]
  • External egress — Action Groups backed by Lambda functions perform outbound HTTP requests and interact with external services outside the operator trust boundary. [10]

4 Blast Radius

The blast radius is what an attacker who controls the agent can reach — which systems they touch, which credentials they read, and which actions they take without operator approval. Compromise reach is constrained by IAM role boundaries on Lambda-backed Action Groups and the absence of direct host or infrastructure access on default deployment. [7]

Blast Radius Metrics

Higher blast scores indicate broader reach from a compromised agent session into customer infrastructure and downstream systems.

Each row maps a blast factor to its score and a one-line comment describing the scope boundary on default deployment.

Factor Score Comments
Code execution 2 / 4 CodeInterpreter sandbox available in supported regions; Action Group Lambda functions run with IAM-scoped permissions rather than unrestricted shell access. [8]
File system access 2 / 4 No direct host filesystem access; file operations are mediated through S3 via Knowledge Bases or Lambda functions with explicit bucket permissions. [8]
Network access 2 / 4 Outbound network access is available through Lambda-backed Action Groups; scope is bounded by security groups and IAM policies on the execution role. [8]
Credential access 2 / 4 The agent execution role (an IAM principal) provides access to all resources its attached policy permits; credentials are shared across all associated Action Groups. [8]
Autonomous action 2 / 4 Invoked Lambda functions can perform any operation their IAM role permits including writes and API calls; user confirmation is available but disabled by default. [10]
Deployment access 1 / 4 No default access to infrastructure-as-code or production deployment systems; deployment reach requires explicit operator configuration of targeting Action Groups. [8]

5 Defense Controls

Defense controls are what the agent’s own architecture does to detect, contain, and report attacks before they reach the operator’s systems. Only execution isolation is active by default; all input guardrails, output guardrails, and monitoring components require explicit operator activation and configuration.

Defense Controls Metrics

Higher defense scores indicate stronger vendor-implemented safeguards active on default configuration without operator intervention.

Each component is scored based on what the vendor implements by default versus what requires operator activation or configuration.

Component Score Comments
Input Guardrails 0 / 3 No default input filtering or prompt-injection detection; Guardrails for Amazon Bedrock requires explicit creation and per-agent association with encoding-attack coverage at Standard tier. [9][13]
Execution Isolation 2 / 3 AgentCore Runtime provides per-session microVM isolation with memory sanitization on termination as the vendor-documented isolation tier for agent workloads. [8][14]
Action Controls 1 / 3 User confirmation for tool invocation is available but disabled by default; all defined Action Groups are accessible without per-tool approval gates. [10]
Output Guardrails 0 / 3 No default output filtering, DLP, or PII redaction; output Guardrails require the same explicit opt-in configuration as input Guardrails. [9]
Monitoring 1 / 3 CloudTrail captures API-level events by default; reasoning traces and tool payloads require opt-in CloudWatch Logs with no built-in anomaly detection. [8]

6 Hardening Tips

Concrete actions an operator can take to reduce the risks reported above, grouped by which defense control each tip strengthens. Operators should prioritize Guardrails activation for input and output filtering followed by enabling user confirmation on high-risk Action Groups to break the trifecta posture.

Input Guardrails

Input guardrails intercept adversarial content before it reaches the reasoning loop.

Input Guardrails
  • Policy Require all production agents to have an associated Bedrock Guardrail with prompt attack detection enabled before deployment approval.
  • Configuration Enable the Guardrails prompt attack filter at maximum sensitivity with denied-topic definitions covering sensitive operational boundaries.
  • Engineering Implement pre-processing Lambda hooks that tag and sanitize external document content before Knowledge Base ingestion.

Execution Isolation

Execution isolation contains what a compromised agent can do on the host.

Execution Isolation
  • Policy Mandate AgentCore Runtime deployment for all agents processing untrusted input to ensure per-session microVM isolation.
  • Configuration Configure VPC endpoints for private Bedrock API routing and attach restrictive security groups to limit outbound connectivity to approved endpoints.
  • Engineering Deploy custom Lambda layers that instrument all Action Group invocations with request-level telemetry and payload size limits.

Action Controls

Action controls govern which tools and actions the agent can invoke autonomously.

Action Controls
  • Policy Require user confirmation enabled for all Action Groups that perform write operations or access sensitive customer data.
  • Configuration Restrict Action Group IAM roles to minimum-privilege policies scoped to specific resource ARNs rather than wildcarded permissions.
  • Engineering Build approval workflow integrations using return-control Action Groups that route high-risk tool invocations through human review.

Output Guardrails

Output guardrails inspect what the agent sends to other systems and users.

Output Guardrails
  • Policy Require output Guardrails with PII redaction and sensitive-information filters active on every agent processing customer data.
  • Configuration Configure Guardrail word filters and managed word lists to block exfiltration of internal identifiers and credential-shaped strings.
  • Engineering Implement a post-processing Lambda hook with custom regex-based DLP patterns that detect credential shapes and internal URLs beyond built-in word filters.

Monitoring

Monitoring captures what the agent did and surfaces anomalies for review.

Monitoring
  • Policy Enable CloudWatch Logs for all Bedrock Agent invocations with trace-level detail capturing reasoning steps and tool payloads.
  • Configuration Configure CloudWatch Alarms on anomalous invocation patterns including unusual tool call frequency and elevated token consumption.
  • Engineering Forward Bedrock Agent CloudTrail events and CloudWatch Logs to a centralized SIEM with correlation rules for injection indicators.

7 References

The evidence base behind every score and finding in the profile, grouped by source type so the reader can verify any claim. Numbers in brackets throughout the report (e.g. [7, 13]) refer to entries below, listed in citation order.

Selected Vulnerabilities

  1. CVE-2026-4269 S3 ownership bypass in Bedrock AgentCore Starter Toolkit allows remote code injection during build; leads to RCE in the AgentCore Runtime (CVSS 5.8; patched v0.1.13).
  2. GHSA-xfhr-q72q-jcrj GitHub Security Advisory detailing the S3 ownership verification gap in AgentCore Starter Toolkit with complete remediation steps and affected version matrix.
  3. AWS Security Bulletin 2026-008 Vendor-issued security bulletin confirming CVE-2026-4269 with remediation guidance to upgrade the AgentCore Starter Toolkit to v0.1.13 or later.

Selected Research

  1. When an Attacker Meets a Group of Agents Palo Alto Networks Unit 42 red-team research demonstrating prompt injection traversing Amazon Bedrock multi-agent hierarchies to extract system prompts and invoke tools with attacker-supplied inputs.
  2. When AI Remembers Too Much Unit 42 proof-of-concept demonstrating indirect prompt injection that persistently poisons Amazon Bedrock Agent long-term memory; enables delayed cross-session data exfiltration to a remote endpoint.
  3. Unit 42 Bedrock Agent Memory Injection PoC AI Incident Database entry documenting the Unit 42 persistent memory injection demonstration against Amazon Bedrock Agents with full attack chain timeline and impact assessment.

Vendor Documentation

  1. Amazon Bedrock Security and Compliance Primary vendor security page documenting encryption posture; PrivateLink connectivity; compliance scope including SOC and ISO certifications; and the shared responsibility model for Bedrock.
  2. AgentCore Runtime Security Best Practices Vendor documentation of microVM session isolation; IAM least-privilege patterns; credential management; network security controls; and the shared responsibility boundary for AgentCore.
  3. Amazon Bedrock Guardrails Vendor documentation of configurable content filters covering prompt attack detection; PII redaction; denied topics; and the dual-layer input and output evaluation pipeline.
  4. Securing Bedrock Agents Against Indirect Prompt Injections AWS blog documenting defense strategies including guardrails placement; user confirmation patterns; plan-verify-execute orchestration; and input tagging for prompt attack filtering.
  5. Prompt Injection Security Vendor documentation establishing shared responsibility for prompt injection and listing agent-level mitigations including pre-processing prompts and system prompt separation.

Other Sources

  1. Bedrock Multi-Agent Attack Analysis Third-party analysis mapping the Unit 42 multi-agent findings to MITRE ATLAS techniques and OWASP LLM Top 10 categories with mitigation prioritization guidance.
  2. Encoding-Based Attack Protection with Guardrails AWS Security Blog documenting how the Standard tier Guardrails detect and block encoding-based prompt injection bypass attempts across multiple obfuscation techniques.
  3. AgentCore Runtime Session Isolation Vendor documentation of per-session microVM provisioning with complete execution environment separation; memory sanitization on termination; and session-to-user lifecycle management guidance.