TL;DR: Sonrai Security’s research shows that global S3 access in sandboxed Amazon Bedrock AgentCore code interpreters can be repurposed as a bidirectional command-and-control channel, even though DNS-based exfiltration was already mitigated. The finding matters because network isolation assumptions break when approved cloud services become communication paths.
NHIMG editorial — based on content published by Sonrai Security: Global S3: Another C2 Channel for AgentCore Code Interpreters
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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 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.
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?
👉 Read Sonrai Security's analysis of global S3 access as an AgentCore C2 channel →
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Global S3 access in AgentCore code interpreters creates C2 risk