What breaks when sandboxed AI code interpreters can still reach S3?

Why sandbox containment fails when the interpreter can still use S3

A sandbox is only a containment boundary if the runtime cannot repurpose its allowed capabilities into an external communication path. When the code interpreter can reach S3, the storage service is no longer just a file endpoint, it can become a bidirectional channel for commands, responses, and state exchange. The issue is boundary design, not simple internet access.

That distinction matters because many teams assume “no outbound network” equals isolation. In practice, a sandbox can still leak data, receive instructions, or coordinate execution through a permitted cloud service if that service is reachable from inside the runtime and can be read back from outside the sandbox.

How S3 becomes a covert channel inside a sandbox

S3 can function as an intermediary when the interpreter can write objects, list prefixes, or fetch content that an external controller can also observe or modify. That creates a hidden message path that bypasses the intended control boundary, even if the sandbox blocks direct sockets, shells, or general internet egress.

For practitioners, the key question is not whether S3 is “safe” in isolation, but whether the sandboxed workload can use it to carry commands, results, or coordination signals. If the answer is yes, the sandbox has inherited the trust of the service integration and lost part of its containment value.

• Write access can exfiltrate results in object names, metadata, or file contents.
• Read access can import instructions, prompts, or payload fragments from objects the attacker controls.
• List and poll patterns can provide synchronization without needing a direct network socket.

What control failure actually matters

The real failure is uncontrolled service reachability inside the runtime boundary. If a sandboxed interpreter can talk to a permitted cloud service with enough fidelity to exchange meaningful data, then the service becomes part of the attack surface and the isolation model must account for that path explicitly.

This is especially dangerous when the service is already trusted by the platform or treated as “normal” application plumbing. A cloud permission that looks narrow at the infrastructure layer may still be broad enough to support covert command and control, data staging, or post-exploitation coordination.

Risk and Threat Considerations

Allowing sandboxed code to reach S3 creates a hidden exfiltration and control channel, so the risk is not just breakout, it is redefinition of the sandbox boundary. Once the interpreter can both consume and produce S3 objects, an attacker can use that path to move data or instructions without triggering controls that only watch for direct network access.

Failure mechanism: The sandbox permits a reachable service that supports bidirectional state exchange, and the runtime can encode commands or responses into object contents, keys, metadata, or polling behavior.

Impact: Containment erodes, sensitive data can leave through an approved service path, and malicious coordination can persist even when traditional egress controls appear to be working.

Practitioner Guidance

What to verify: Confirm whether the interpreter can only read a fixed object set, or whether it can create, overwrite, list, or poll S3 content. If the sandbox can influence object state, treat that permission as a communication primitive rather than a passive dependency.

Decision rule: If a service call can carry both instructions and results, do not count it as sandbox-safe just because the destination is an approved cloud service. Reduce the reachable API surface, separate read-only from write-capable paths, and treat object-level interaction as part of the containment design.

Practitioner takeaway: A sandbox is only strong when its allowed services are non-expressive enough to prevent covert coordination; once S3 can move messages, the boundary has already been crossed conceptually even if the network is still “restricted.”

Related resources from NHI Mgmt Group

• How should security teams govern S3 access for sandboxed AI code interpreters?
• What breaks when sandboxed code interpreters can still access execution-role credentials?
• What breaks when AI-generated code still depends on copied AWS credentials?
• What breaks when an AI agent can still write to production during a code freeze?