Commissioned, Curated and Published by Russ. Researched and written with AI.
What’s New This Week
Security researchers disclosed DNS exfiltration capabilities in Amazon Bedrock AgentCore Code Interpreter in September 2025, with public reporting emerging in March 2026. Amazon’s response – classifying it as intended functionality rather than a vulnerability – is the detail that matters most for teams building on managed agent platforms.
Changelog
| Date | Summary |
|---|---|
| 22 Mar 2026 | Initial publication. |
Amazon Bedrock AgentCore Code Interpreter launched in August 2025 with a clear pitch: securely execute code in isolated sandbox environments so that agentic workloads cannot access external systems. That’s not marketing language. That’s the security guarantee the product is sold on.
Security researchers disclosed in September 2025 that the guarantee has a gap. Despite “no network access” configuration, DNS queries are permitted. Kinnaird McQuade, chief security architect at BeyondTrust, said the DNS allowance “can allow threat actors to establish command-and-control channels and data exfiltration over DNS in certain scenarios, bypassing the expected network isolation controls.”
DNS-based exfiltration is not a novel technique. Attackers encode data in subdomain queries – secretdata.attacker.com – and the authoritative nameserver logs every request. No TCP connection. No HTTP. Nothing that most “no network access” policies were written to block. The attack class is decades old and well-documented. Any sandbox that blocks TCP/UDP but passes DNS through is not air-gapped in any meaningful sense.
Amazon’s response: this is intended functionality. Customers who want complete network isolation should use VPC mode, not sandbox mode.
That response is technically accurate and strategically convenient. VPC mode probably does provide the isolation you want. But the framing matters.
When a product is described as a secure, isolated sandbox, and then permits a well-known exfiltration channel, the problem is not that the product is broken – it’s that the documentation failed to make the distinction legible. “Sandbox mode doesn’t block DNS” is a significant caveat. If it appeared prominently in the docs, teams could make an informed choice. If it didn’t, they made assumptions based on the product’s stated purpose. Calling the gap “intended” after responsible disclosure is a way of closing the conversation without acknowledging the trust problem.
The broader lesson for teams building on managed agent infrastructure: the sandbox is not your security boundary. It’s a convenience feature. Treat it that way.
Every “no network access” claim from a managed platform deserves verification before you trust it with sensitive workloads or credentials. That means actually testing DNS egress, not reading the feature description. It means understanding what “isolation” means in each specific configuration, not assuming it means what you think it means. It means recognising that vendors and customers have different risk appetites, and the vendor’s definition of acceptable may not match yours.
The same research batch identified separate vulnerabilities in LangSmith and SGLang enabling data exfiltration and remote code execution. Different products, different mechanisms, same pattern: the agentic infrastructure layer is under-scrutinised from a security standpoint, and the people building on it are often trusting claims they haven’t verified.
Don’t trust the sandbox. Verify the isolation. The tools are there to test it. Use them before something else does.