Topic starter
15/05/2026 8:23 pm
TL;DR: Global S3 access in sandboxed Amazon Bedrock AgentCore code interpreters can be turned into a bidirectional command-and-control channel, even after DNS-based exfiltration was mitigated, according to Sonrai Security. The finding shows that network isolation breaks when approved cloud services become communication paths, so governance must shift to endpoint scope and bucket-level control.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “Global S3: Another C2 Channel for AgentCore Code Interpreters”.
Key questions
Q: What breaks when sandboxed AI code interpreters can still reach S3?
A: The sandbox stops being a containment boundary if an allowed service can carry commands and responses.
Q: Why do allowed cloud services create command-and-control risk in AI runtimes?
A: Because an attacker does not need raw network egress if the runtime can exchange data through an approved service.
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.
Practitioner guidance
- Constrain interpreter egress to approved S3 buckets Use VPC mode and gateway endpoints so sandboxed interpreters can reach only specific S3 buckets and object paths that support the workflow.
- Scope presigned URLs to single-purpose object operations Issue presigned URLs only for the exact object key and method required, and avoid handing interpreters reusable URLs that can relay arbitrary commands or responses.
- Review execution roles for cross-account bucket reachability Test whether the interpreter can read or write to external buckets, including cross-organization targets, and remove any access that is not explicitly required.
Bottom line: Sandboxed code interpreters can still create covert communication paths when an approved cloud service is globally reachable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/05/2026 8:24 pm
Approved cloud services become the new egress perimeter when sandboxing is applied to AI code interpreters. The security model is no longer about whether the public internet is blocked, but whether a permitted service can carry attacker-controlled traffic. That is why S3 access must be governed as a communication path, not just as storage. Practitioners should treat every allow-listed endpoint as part of the interpreter’s attack surface.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between sandboxing and endpoint-scoped authorisation?
A: Sandboxing limits where traffic can go in broad terms, while endpoint-scoped authorisation defines which buckets, objects, and methods are actually allowed. For AI runtimes, both are needed, because a sandbox without tight service scope can still expose a usable communication path.
👉 Read our full editorial: Global S3 access in AgentCore code interpreters creates C2 risk