Threat Research Center Threat Research Malware Malware Cracks in the Bedrock: Escaping the AWS AgentCore Sandbox 13 min read Related Products Cortex Cortex Cloud Unit 42 AI Security Assessment Unit 42 Cloud Security Assessment Unit 42 Incident Response By: Ori Hadad Published: April 7, 2026 Categories: Malware Threat Research Tags: Agentcore Agentcore runtime AWS DNS tunneling GenAI Sandbox Share Executive Summary When researching the boundaries of cloud services, two of the main aspects that come to mind are network and identity. In this two-part series, we present our research into the boundaries and resilience of Amazon Bedrock AgentCore. In this first part, we explore how AgentCore’s Code Interpreter sandbox network isolation mode could be bypassed in a way that allows sending and receiving of data from external endpoints via DNS tunneling. In the second part, we explore the identity side, and how an attacker can leverage weaknesses in default identities and permissions to compromise other AgentCore agents within an AWS account and exfiltrate sensitive data from other services. To support the growing adoption of AI agents, AWS announced global availability of Amazon Bedrock AgentCore in late 2025. AgentCore is a framework that allows organizations to build, deploy and manage AI agents. It protects one of its most useful resources, Code Interpreters, that allows AI agents to dynamically execute code by isolating it from external network access using sandbox mode. Our discovery showed that this isolation is incomplete. We outline the steps we took to identify the sandbox bypass. We also identified a critical security regression where the AgentCore Runtime utilized a microVM Metadata Service (MMDS) that lacks session token enforcement. Prior to our disclosure and AWS's fixes, this configuration could have allowed an attacker to exploit standard web vulnerabilities, such as server-side request forgery ( SSRF ), to directly extract sensitive credentials, putting the entire environment at risk. We responsibly disclosed all findings to the AWS Security team. Following their review, AWS introduced the necessary internal remediations and outlined several important mitigation strategies for customers. Users cannot patch the managed environment directly, but can leverage the platform-level controls AWS provides. As reliance on these services grows, understanding their internal mechanics is crucial for maintaining security. Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services: Cortex AI-SPM Cortex Cloud Identity Security The Unit 42 AI Security Assessment The Unit 42 Cloud Security Assessment If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team . Related Unit 42 Topics Cloud , DNS Tunneling , Sandbox , Investigation Overview: Scope, Methodology and Key Findings Our investigation focused on the Code Interpreter service provided by AgentCore , which offers an isolated sandbox compute environment for AI agents to execute their code. The sandbox mode promises an easy way to implement restrictions on network access, which serves as an important containment layer for untrusted code. This restriction is critical to the security model of AgentCore. Originally, AWS described sandbox mode as providing “complete isolation with no external access.” Our research revealed that the restrictions of sandbox mode were not as complete as originally described. We analyzed the robustness of this architecture, to determine the efficacy of the sandbox isolation boundaries and the scope of access available from within the sandbox. After performing environmental reconnaissance, we observed the existence of external network connectivity, which directly conflicted with the stated "no external network access" policy of the sandbox mode. We tested the network permeability by mapping the boundaries of the DNS resolution capability through incremental testing and discovered a channel for data exfiltration: DNS tunneling . Watching our DNS server logs, we saw the query arrive instantly, establishing a covert bi-directional channel out of the sandbox. We had successfully turned a "secure, offline" environment into a potential privileged data exfiltration pipeline. After sharing our findings with AWS, they updated their developer guide to state that the sandbox mode provides limited external network access, increasing transparency for users. Technical Analysis We set out to test whether AgentCore’s network isolation contained hidden egress paths that are necessary for internal AWS operations. We first studied the system’s architecture to select core components for deep analysis. Following this, we performed internal reconnaissance and metadata inspection to map potential vulnerabilities. These steps ultimately allowed us to validate our hypothesis by successfully demonstrating DNS tunneling. In the following sections, we detail the step-by-step methodology we used to execute this exploit. AgentCore Architecture and Isolation Our research focused on two aspects of AgentCore’s services: the Code Interpreter tool and the AgentCore Runtime. AgentCore Code Interpreter is one of several built-in tools for AI agents, designed specifically to execute code, often generated dynamically by large language models (LLMs). The service supports three network configurations: Public mode : Provides external internet access for fetching data or libraries. Sandbox mode : A strictly isolated environment with no external network connectivity. Virtual Private Cloud (VPC) mode: Provides the ability to connect the Code Interpreter to a customer-controlled VPC. We chose to examine the sandbox mode, as this configuration is considered to be entirely isolated from external networks. This means that if the Code Interpreter configured with sandbox mode is compromised, it still should not be possible to exfiltrate data or to use the interpreter as part of a command and control (C2) channel. Figure 1 shows the Sandbox mode description. Figure 1. AgentCore Code Interpreter documentation, prior to AWS's update. AgentCore Runtime is a managed environment that executes the core logic of a deployed AI agent. Each interaction with an AI agent goes through an instance of AgentCore Runtime, making it a central pillar of the agent architecture. To fully understand the risks of escaping the sandbox mode or abusing the Runtime environment, we first needed to understand how their underlying metadata is managed. Both services operate on ephemeral microVMs, which are lightweight, hardened virtualization units created per session to ensure distinct isolation between tasks. A critical aspect of this architecture is how these microVMs maintain context. They use a microVM Metadata Service (MMDS), which is structurally similar to the well-known EC2 Instance Metadata Service ( IMDS ). Just as IMDS provides credentials and metadata to an EC2 instance, MMDS serves as the internal metadata server for the microVM. With a clear understanding of the architecture and metadata management in place, we can now walk through the chronological phases of our investigation. Phase 1: Internal Reconnaissance Our analysis commenced with a baseline scenario: executing arbitrary code within the Code Interpreter. This is the intended functionality of the service, as users and AI agents are designed to execute dynamic scripts in this environment. Upon establishing this context, we began our environmental reconnaissance by investigating the microVM architecture and MMDS accessibility. In modern AWS EC2 environments, accessing metadata usually defaults to IMDSv2 (although IMDSv1 is not actually disabled by default), which mandates a session token (HTTP PUT request) to mitigate SSRF attacks. However, we observed that the microVM’s MMDS endpoint was configured to accept standard HTTP GET requests without requiring a session token, as Figure 2 shows. Figure 2. MMDS response containing the executing role credentials. Not requiring a session token posed serious implications for the runtime environment. AgentCore Runtime hosts the AI agent's application logic and is not designed for arbitrary user code execution. However, if an AI agent contains a standard web vulnerability like SSRF, the absence of token enforcement leads to the same risks that are found in legacy EC2 IMDSv1 configurations. A simple SSRF vector could allow an external actor to retrieve the AI agent's identity and access management (IAM) role credentials directly, posing a significant security risk for the entire environment. In the Code Interpreter environment, where arbitrary code execution is an intended feature, this same configuration primarily simplifies the retrieval of credentials and does not function as a vulnerability in itself, regardless of whether v1 or v2 MMDS protocols are used. With credential access confirmed locally, our investigation shifted to the integrity of the network boundaries. Under the sandbox mode's design specifications, the absence of an outbound network route effectively neutralizes the risk of data exfiltration, effectively trapping the compromised credentials within the microVM. Phase 2: The Clue in the Metadata We extended our metadata analysis to identify additional configuration parameters that are exposed within the MMDS hierarchy. A systematic traversal of the latest/meta-data/tags/instance/ path revealed two undocumented endpoints: http[:]//169.254.169[.]254/latest/meta-data/tags/instance/aws_presigned-log-url http[:]//169.254.169[.]254/latest/meta-data/tags/instance/aws_presigned-log-kms-key Querying these endpoints returned a pre-signed URL for an S3 bucket and a corresponding Key Management Service (KMS) Key ID. These resources appeared to belong to an internal AWS account, likely used by the backend infrastructure for log aggregation. While the URLs themselves were a secondary