Global S3 access in AgentCore code interpreters creates C2 risk

At a glance

What this is: This research shows that sandboxed AgentCore code interpreters can use global S3 access as a command-and-control path, not just a data access feature.

Why it matters: IAM and NHI teams need to treat interpreter execution roles, bucket scope, and endpoint policy as security boundaries, not implementation details.

👉 Read Sonrai Security's analysis of global S3 access as an AgentCore C2 channel

Context

A sandboxed code interpreter is only isolated if its approved service access cannot be turned into an outbound communication path. In this case, the core governance gap is not code execution itself, but the assumption that allowing S3 access is harmless when the interpreter can still read, write, and exchange commands through cloud storage.

For IAM and NHI practitioners, this is a non-human identity problem as much as a network problem. The interpreter’s execution role, bucket permissions, and any pre-signed URL workflow determine whether an agentic workload can be used for command relay, data exfiltration, or post-exploitation control.

The starting position described in the research is not unusual. Many teams focus on whether a sandbox blocks the public internet, while overlooking how allowed AWS services can still provide the attacker with a practical control channel.

Key questions

Q: How should security teams govern S3 access for sandboxed AI code interpreters?

A: Security teams should treat S3 as part of the interpreter’s attack surface, not just as storage. Restrict access to specific buckets and object prefixes, require endpoint policies, and use VPC mode where possible. If the workload can exchange commands and output through S3, it has enough reach to become an attacker-controlled channel.

Q: What is the difference between sandbox mode and true network isolation for AI workloads?

A: Sandbox mode limits some external traffic, but true network isolation requires control over every allowed outbound path. If a workload can still reach S3, pre-signed URLs, or other permitted services, an attacker may still use those paths for exfiltration or command relay. Isolation is about reducing usable channels, not just blocking the public internet.

Q: When does cloud service access become a command-and-control risk?

A: Cloud service access becomes C2 risk when an attacker can use legitimate reads and writes to pass instructions, receive output, or maintain session state. That happens when permissions are broad enough to support bidirectional exchange, especially with storage services, URL-based access, or reusable object paths. The question is whether the access can be turned into communication.

Q: Why do non-human identities create special governance problems in agentic systems?

A: Non-human identities can act at machine speed, with permissions that are often broader and less reviewed than human access. In agentic systems, that means a single execution role, token, or URL can be converted into repeated control. The governance problem is not whether the identity is automated, but whether its blast radius is tightly bounded.

Technical breakdown

How S3 becomes a bidirectional channel in a sandbox

The key technical issue is that a sandbox does not automatically equal isolation. If a code interpreter can make allowed S3 requests, an attacker can use object reads and writes as a message bus between the interpreter and an external controller. That can be done with public buckets, cross-account buckets, or pre-signed URLs that let the interpreter fetch commands and return output. The result is not a conventional socket-based shell, but the security effect is similar: the interpreter can receive instructions, execute them, and exfiltrate responses through a service the platform already permits.

Practical implication: Treat every allowed cloud service as a potential transport path and scope it as tightly as possible.

Why execution roles and pre-signed URLs change the blast radius

The interpreter’s execution role defines what authenticated S3 actions it can perform, but it is not the only risk boundary. Pre-signed URLs can extend access beyond the base role and create time-limited write or read capability that an attacker can reuse inside the sandbox. That matters because the attacker does not need broad AWS account access if they can reach one bucket, one object path, or one URL flow. In NHI terms, the relevant question is not whether the identity is human or machine. It is whether the credential or token grants enough reach to support command relay or persistence.

Practical implication: Review pre-signed URL lifetimes, object scope, and bucket policies as part of agent identity governance.

VPC mode and gateway endpoints reduce exposed paths

VPC mode changes the network control plane by keeping traffic inside a more governable boundary, while gateway endpoints let teams restrict which S3 buckets a workload can reach. Endpoint policies add another layer by limiting object operations to approved destinations and actions. This does not eliminate all risk, because a malicious interpreter can still misuse legitimate access, but it sharply reduces the chance that broad S3 connectivity becomes an attacker-controlled channel. The architectural lesson is straightforward: network mode, endpoint policy, and identity policy must be designed together, not reviewed separately.

Practical implication: Use VPC mode plus restrictive endpoint policies when interpreter workloads need S3 at all.

Threat narrative

Attacker objective: The attacker wants durable remote control over the sandboxed interpreter without needing direct internet connectivity.

1. Entry occurs when attacker code is injected into a workflow that uses a sandboxed AgentCore code interpreter.
2. Escalation happens when the interpreter’s allowed S3 access is turned into a command relay using bucket reads, writes, or pre-signed URLs.
3. Impact is achieved when the attacker runs commands through the interpreter and retrieves results through S3, creating a reverse-shell-style C2 channel.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Global S3 access becomes a trust boundary failure when the workload itself is the identity. In agentic systems, the interpreter is not just software running code. It is a non-human identity with permissions, network reach, and potential access to sensitive data. If teams treat approved service access as inherently safe, they miss the attacker’s real opportunity, which is to reuse legitimate access as a covert transport layer. The practitioner conclusion is simple: identity scope must be designed with abuse cases in mind.

Ephemeral execution does not eliminate persistent risk when access paths remain broad. Sandboxing can reduce exposure, but it does not neutralise the blast radius of a permissive execution role or a bucket policy that is broader than necessary. The field should treat this as a cloud NHI governance issue, not a narrow interpreter bug. Security teams need to assume that any allowed service can become an exfiltration or C2 channel if it accepts both inbound and outbound object operations.

Identity blast radius is the right concept for interpreter security. The memorable mistake is assuming that a sandboxed workload has a small footprint simply because it cannot reach the public internet. In reality, the blast radius is defined by what it can still touch inside the cloud control plane, including storage, tokens, and object paths. The practitioner takeaway is to measure not just access, but the ability to turn access into communication.

Service allowlists are necessary, but not sufficient, for AI workload governance. Allowlisting S3 without endpoint restrictions creates a false sense of control because the service remains usable as a relay. The better model is layered containment, where identity policy, endpoint policy, and network mode all constrain the same workload. Security architects should re-evaluate any design that assumes a single allowlisted service is automatically low risk.

This pattern validates the need for Zero Standing Privilege in agentic environments. If a code interpreter only needs occasional S3 access, it should not retain standing reach to broad buckets or reusable URLs. Ephemeral, task-scoped access narrows the window in which an attacker can turn a tool into a channel. The field should move from broad service permissioning to tightly governed, short-lived access.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to AI Agents: The New Attack Surface report.
• 52% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• For deeper context, review the Ultimate Guide to NHIs for lifecycle controls, privilege scope, and governance patterns.

What this signals

Identity blast radius: this incident pattern shows why AI workload governance has to measure reachable actions, not just declared permissions. With 67% of organisations still relying heavily on static credentials, according to the 2026 Infrastructure Identity Survey, teams should expect broad service access to remain the default unless they redesign it.

A workload that can write to storage can often be repurposed into a control path, which is why S3 policy design now belongs in agent governance reviews. Security programmes should connect cloud network design to identity reviews, not treat them as separate workstreams.

The next planning question is whether a given agentic workload needs storage access at all, and if so, whether the access can be narrowed to a single purpose and short time window. That is the practical line between enablement and exposure.

For practitioners

• Scope interpreter S3 access to specific buckets Use bucket-level and object-level restrictions so the workload cannot read or write outside the minimum required S3 paths. Prefer endpoint policies that deny all other S3 destinations.
• Prefer VPC mode for interpreter workloads Place code interpreters in VPC mode when they need cloud service access, then control outbound traffic with gateway endpoints and explicit policy checks.
• Review pre-signed URL usage as NHI exposure Limit pre-signed URL lifetime, constrain object keys, and treat every URL as a temporary non-human credential that can be abused inside the sandbox.
• Log and alert on abnormal S3 object patterns Watch for command-like object names, rapid read-write exchanges, and repeated access to the same session prefix because those patterns often signal relay behaviour rather than normal storage use.

Key takeaways

• Sandboxed code interpreters still need identity and network governance because permitted cloud services can become attacker communication channels.
• The risk is not theoretical. Legitimate S3 access can support command relay, response capture, and reverse-shell-style control when permissions are broad enough.
• Teams should scope bucket access, prefer VPC mode, and treat pre-signed URLs as temporary non-human credentials that require strict oversight.

Key terms

• Command And Control Channel: A command and control channel is a communication path an attacker uses to send instructions to compromised systems and receive results back. In cloud and AI workloads, that path can be built through legitimate services such as storage, APIs, or object exchange rather than direct network sockets.
• Sandboxed Code Interpreter: A sandboxed code interpreter is a runtime that executes code in a constrained environment intended to limit external network exposure. The security challenge is that any allowed service access, such as storage or API connectivity, can still be abused if permissions are broad or reusable.
• Identity Blast Radius: Identity blast radius is the amount of damage or reach a credential, token, or execution role can create if it is misused. For non-human identities, the blast radius depends on what the workload can access, what it can write, and whether those permissions can be turned into communication.
• Pre-Signed URL: A pre-signed URL is a temporary credential embedded in a link that grants limited access to an object or operation. In non-human identity governance, it should be treated as a short-lived machine credential because it can extend access into a sandbox and be abused for relay or exfiltration.

Deepen your knowledge

S3 access governance for AI code interpreters is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to align agent workloads, cloud storage, and least privilege, it is worth exploring.

This post draws on content published by Sonrai Security: Global S3: Another C2 Channel for AgentCore Code Interpreters. Read the original.