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.

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.

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.

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 concern, their existence provided a critical clue about the network architecture and its connectivity. The provision of an S3 pre-signed URL implies a functional requirement for the microVM to transmit data to Amazon S3. Since standard S3 endpoints (such as bucket.s3.region.amazonaws[.]com) are resolved via DNS resolution, the environment might theoretically have a mechanism to resolve and route traffic to external DNS servers and to these S3 endpoints.

This observation presents an architectural conflict with the originally stated "no external network access" policy of the sandbox mode. The necessity to support S3 traffic suggests that the isolation is not absolute, but rather conditionally permeable. Such behavior implies the presence of an allow-list or a transparent proxy designed to facilitate specific AWS service interactions.

This observation directed our analysis to the foundation of the network stack: DNS.

Phase 3: The Great Escape

To validate our hypothesis of the network’s permeability, we executed a series of targeted tests within the Code Interpreter. Our objective was to map the boundaries of the DNS resolution capability through incremental testing.

Test 1: Internal Service Resolution (Control)

We began by querying a standard AWS service endpoint. Given that the endpoint is likely used for log aggregation, we anticipated that this query would succeed:

As expected, the environment successfully resolved the internal AWS endpoint.

Test 2: External Domain Resolution

Next, we attempted to resolve an external public domain completely unrelated to AWS infrastructure. In a strictly isolated sandbox environment, DNS queries are typically restricted. The code below shows how we attempted to resolve google[.]com from within the sandbox.

The query resolved successfully, confirming that although the sandbox blocks direct TCP/UDP data traffic to these IP addresses, it might permit recursive DNS queries to arbitrary public domains.

Proof of Concept: Exploiting the DNS Egress Vector

This sandbox design reveals a channel for data exfiltration: DNS tunneling. Even in environments where direct internet access is severed, the ability to resolve arbitrary domain names allows for bidirectional communication via the DNS protocol itself.

To demonstrate the feasibility of the egress vector, we configured an authoritative nameserver for a domain under our control: dnshook[.]site. We then designed a proof-of-concept (PoC) payload to validate the communication path.

The PoC is executed according to the following logic:

1. Identify sensitive information: my-secret.
2. Append the data as a subdomain to the controlled domain: my-secret.dnshook[.]site.
3. Trigger a DNS resolution request from within the Code Interpreter.
4. The sandbox's recursive resolver forwards the query to our authoritative nameserver, where the "subdomain" – the leaked data – is logged.

Figure 3 details the PoC script.

Upon execution, our authoritative nameserver immediately received the query, confirming that the data had successfully traversed the sandbox boundary, as shown in Figure 4.

Finally, as shown in Figure 5, performing a Whois lookup on the incoming IP address confirmed the traffic originated directly from AWS infrastructure, validating that the Code Interpreter environment was the source of the transmission.

Video 1 shows the PoC in action.

Video 1. Escaping the sandbox PoC.

The Impact

Watching our DNS server logs, we saw the query arrive instantly, establishing a covert channel out of the sandbox.

Crucially, this vector is not limited to data exfiltration; it establishes a bidirectional communication channel capable of both outbound and inbound traffic.

1. Exfiltration (outbound): An attacker can encode sensitive data – such as environment variables, source code, or the IAM credentials retrieved in Phase 1 – into Base64 subdomains and tunnel them out.
2. C2 (inbound): The code inside the sandbox can receive instructions or payloads from the attacker's server in the form of DNS response. This effectively enables a full C2 loop over DNS.

To summarize so far, this capability is particularly dangerous in the context of identity. Because users trust the "sandbox" guarantee, they often attach highly privileged IAM roles to these interpreters – permissions they would never grant to a public mode Code Interpreter.

Phase 4: Beyond the Sandbox

Following the confirmation of DNS egress and credential accessibility, the analysis returned to the metadata anomalies identified in Phase 2. As previously noted, the MMDS traversal revealed two undocumented endpoints:

• http[:]//169.254.169[.]254/.../instance/aws_presigned-log-url
• http[:]//169.254.169[.]254/.../instance/aws_presigned-log-kms-key

Upon closer inspection, these endpoints represent a distinct finding. We confirmed that code executing within the Code Interpreter (or AgentCore Runtime) can query these paths to retrieve a valid S3 pre-signed URL and a corresponding KMS Key ID. The returned URL targets an internal, AWS-controlled S3 bucket, as displayed in Figure 6.

Scoped S3 ObjectWrite

The combination of the pre-signed URL and the KMS Key ID provides the necessary components to construct a valid HTTP PUT request that could be sent to the target bucket.

It is important to note that this write access appears to be scoped, and not arbitrary. The pre-signed URL restricts uploads to a specific object key path. This restriction prevents writing to arbitrary paths and limits the impact radius. AWS confirmed that AWS’s own service code uses this pre-signed URL to upload service-related logging information to a specific location owned by the service.

Infrastructure Leak

Interacting with these endpoints revealed internal infrastructure details. When sending a malformed request (by breaking the signature) to the pre-signed URL, the server responds with a SignatureDoesNotMatch error.

This server error message includes the AWSAccessKeyID of the signing identity, as Figure 7 shows.

After extracting this Key ID, we used the AWS Security Token Service (STS) command-line interface to show information about the Key ID:

The response revealed the owning account:

This confirmed that we were interacting with account 209...9, which appears to be an internal AWS environment that is hidden behind the service abstraction, separate from our own environments.

Mitigation and Collaboration With AWS

After we shared our findings, AWS clarified that the AgentCore Code Interpreter offers three network modes: Sandbox, Public network, and VPC. AWS recommends VPC Mode for customers requiring complete network isolation. To specifically mitigate DNS-based exfiltration, customers using VPC Mode can implement Amazon Route 53 Resolver DNS Firewall. AgentCore has since updated its developer guide to explicitly clarify sandbox mode’s capabilities, noting that “the code interpreter can access Amazon S3 for data operations and perform DNS resolution.”

In response to our research regarding the S3 pre-signed URLs and metadata exposure, AWS confirmed that this represents expected behavior. The access keys and account IDs are part of the backend infrastructure, do not belong to customer accounts, and the pre-signed URLs are narrowly scoped to their intended logging function.

AWS also informed us that they have made a number of improvements to the behavior of MMDS in AgentCore. Specifically, as of Feb. 14, 2026, any AWS account in which customers had not previously utilized Runtime, Browser or Code Interpreter microVMs will launch new runtimes and tools with MMDSv2 only. Even for accounts that had been using these capabilities prior to that date, all newly deployed agents will launch with MMDSv2 only.

The Browser and Code Interpreter tools now have both MMDSv1 and v2 available by default.

We appreciate the transparent collaboration with the AWS Security team in assessing these findings.

Disclosure Timeline

• Nov. 17, 2025 – We responsibly reported to the AWS Security team.
• Nov. 18, 2025 – AWS Security team responded that they are investigating.
• Dec. 14, 2025 – AWS Security team reached out for more details.
• Jan. 28, 2026 – AWS Security team provided clarifications regarding our findings and commitment for internal remediations.
• Feb. 14, 2026 – AWS set MMDSv2 as the default for new agents, provided an API for disabling v1 on older agents, and made v2 available in AgentCore tools.

Conclusion

Our research into AWS AgentCore reveals that despite the "sandbox" label, the underlying mechanisms of cloud, network and identity still apply – and their integrity can still be broken. Developers must adopt a shared responsibility mindset when utilizing sandbox environments. It is critical to maintain the principle of least privilege for agent permissions, and to view a sandbox environment as a boundary, rather than an absolute security guarantee.

The discovery of internal S3 write access and the leakage of backend Account IDs highlight that the abstraction layer between the tenant and the cloud provider offers less isolation than anticipated. Our research shows that cloud providers sometimes use customer-facing features to enable capabilities like log collection, and accept the risk inherent in this setup.

By chaining together DNS Tunneling and the legacy MMDSv1 configuration, we demonstrated a complete attack:

1. Break out: Escaping the network sandbox using DNS recursion.
2. Break in: Accessing the AI agent’s identity via an unprotected metadata service.
3. Exfiltrate: Tunneling sensitive IAM credentials to an external attacker.

The impact of this attack defeats the primary purpose of an isolated environment. It allows an attacker to bypass network controls, exfiltrate credentials and execute remote commands without triggering standard network alarms. A successful exploit allows attackers to establish a persistent bidirectional C2 channel, turning a trusted AI agent into an internal threat vector.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

Organizations are better equipped to close the AI security gap through the deployment of Cortex AI-SPM, which helps to provide comprehensive visibility and posture management for AI agents across AWS and Azure environments. Cortex AI-SPM is designed to mitigate critical risks, including over-privileged AI agent access, misconfigurations and unauthorized data exposure. Cortex AI-SPM helps enable security teams to enforce compliance with NIST and OWASP standards, monitor for real-time behavioral anomalies, and secure the entire AI lifecycle within a unified cloud security context.

Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) and Identity Threat Detection and Response (ITDR). It provides clients with the necessary capabilities to improve their identity-related security requirements by providing visibility into identities, and their permissions, within cloud and container environments. This helps accurately detect misconfigurations and unwanted access to sensitive data. It also allows real-time analysis surrounding usage and access patterns.

The Unit 42 AI Security Assessment can help empower safe AI use and development.

The Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 000 800 050 45107
• South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

• What is Amazon Bedrock AgentCore? – AWS documentation
• Understanding Credentials Management in Amazon Bedrock AgentCore – AWS documentation
• What Is DNS Tunneling? – Palo Alto Networks
• When an Attacker Meets a Group of Agents: Navigating Amazon Bedrock's Multi-Agent Applications – Unit 42
• AWS IMDSv1 Vulnerability Exposed: Insights from TotalCloud – Qualys