Background and context
New research from BeyondTrust points to a familiar security lesson showing up in a newer place: a sandbox is only as safe as the channels it still leaves open. According to the company’s disclosure, AI code-execution environments tied to Amazon Bedrock AgentCore Code Interpreter, LangSmith, and SGLang can be abused through outbound DNS requests to leak sensitive data and, in some setups, support command execution patterns that resemble an interactive shell BeyondTrust, The Hacker News.
The core issue is not exotic. DNS has long been used as a covert channel because many restricted environments block web traffic but still allow name resolution. What makes this disclosure notable is where that channel appears: AI agent runtimes and code interpreters that may have access to prompts, uploaded files, retrieved documents, temporary artifacts, environment variables, and API tokens. In other words, the very systems marketed as controlled execution spaces may still have enough egress to leak the data they were trusted to process.
This also fits a wider pattern in AI security research. Over the past two years, defenders have become more concerned with prompt injection, tool abuse, unsafe plugin execution, and weak trust boundaries between model context and external tools. OWASP’s guidance for LLM applications has repeatedly highlighted prompt injection, sensitive information disclosure, and insecure output handling as leading risks OWASP. DNS-based exfiltration adds another layer: even if direct HTTP access is blocked, a model-driven toolchain may still have a quiet path out.
How the attack works
At a technical level, the attack is straightforward enough for many defenders to recognize. If an attacker can get code to run inside a sandboxed AI execution environment, that code can read accessible data, encode it into small chunks, and place those chunks into DNS queries sent to an attacker-controlled domain. The attacker then reconstructs the stolen data from authoritative DNS logs or resolver telemetry. This is a classic DNS tunneling or DNS exfiltration technique adapted to AI runtimes.
For example, a malicious payload could read an environment variable containing a cloud token, split it into pieces, convert it to hex or Base32, and trigger lookups such as chunk1.secret.attacker-domain.tld, chunk2.secret.attacker-domain.tld, and so on. Each query leaks a small amount of information. Over enough requests, an attacker can recover credentials, internal prompts, or document fragments. MITRE ATT&CK already documents DNS as an exfiltration and command-and-control channel, which makes this less a brand-new primitive than a dangerous reuse of an old one in AI infrastructure MITRE ATT&CK.
The more serious claim in the report is the possibility of “interactive shells.” That does not necessarily mean a classic full-featured terminal over DNS, but it can mean a low-bandwidth back-and-forth channel where the sandbox repeatedly asks for DNS records and the attacker uses responses to steer subsequent actions. If code execution is already possible inside the environment, DNS can become a crude command channel. That is enough to browse files, stage additional payloads, run system commands, or enumerate local resources, depending on what the sandbox permits.
Why Amazon Bedrock, LangSmith, and SGLang matter
The named platforms matter because they sit at different layers of the AI stack. Amazon Bedrock AgentCore Code Interpreter represents a managed cloud execution environment. LangSmith is associated with tracing, debugging, and observability in the LangChain ecosystem. SGLang is an open-source framework for serving and orchestrating LLM workflows. If all three can be abused through the same residual egress path, the problem is broader than one vendor bug. It suggests a recurring design weakness in how AI runtimes are isolated.
For Bedrock, the concern is obvious: customers may assume a managed sandbox sharply limits outbound communication. If outbound DNS remains available, that assumption weakens. For LangSmith, the risk may involve execution or testing pipelines that expose traces, prompts, and tool outputs to code running in an environment with network reach. For SGLang, the issue may be tied to deployment defaults or framework behavior that leaves too much freedom to agent tools. In each case, the exact severity depends on what the runtime can access and whether the attacker can reliably trigger code execution.
That distinction matters. Some incidents in this category are true vulnerabilities, while others are insecure defaults or trust-model failures. If a vendor allows arbitrary code execution by design, then the security boundary becomes the sandbox and its egress controls. If those controls are incomplete, defenders should treat it as a serious exposure even if the vendor frames it as expected behavior.
Technical details defenders should understand
DNS exfiltration works best when sandboxes expose any combination of secrets, file access, and automation. In AI systems, those conditions are common. A code interpreter may receive uploaded datasets, snippets generated by the model, and credentials passed in through environment variables. It may also have access to retrieval results from internal knowledge bases. If a prompt injection or malicious file can cause the interpreter to execute code, the attacker does not need broad internet access. DNS alone may be enough.
Defenders should watch for several indicators. Long or high-entropy subdomains are a common sign, especially labels that resemble Base32, Base64, or hex. Repeated lookups to uncommon domains from AI runtime hosts are another. TXT-record abuse, bursts of NXDOMAIN responses, and repetitive small queries can also indicate tunneling behavior. CISA and other defenders have long recommended DNS logging and anomaly detection for spotting covert channels, advice that applies directly here CISA.
Another important point is that “sandboxed” does not mean “safe to give secrets.” If the environment can read a key, it can probably leak that key. The same applies to prompt context. Sensitive system prompts, customer records, source code, and internal documents should be treated as reachable data if they are placed inside an execution environment. Encryption at rest does not help once the runtime can read the plaintext, though organizations should still maintain strong privacy protection and data-handling controls around supporting services.
Impact assessment
The likely impact ranges from moderate to severe depending on deployment. The most exposed organizations are enterprises using AI agents or code interpreters against internal data, source repositories, cloud resources, or customer records. If the runtime has access to API tokens, database credentials, or cloud metadata, a DNS exfiltration channel could become the first step in a larger compromise.
Developers and research teams are also at risk. Many AI workflows are assembled quickly, with permissive defaults and broad secrets available for convenience. That makes test and staging environments attractive targets. In some cases, those environments contain more sensitive material than production because they aggregate logs, prompts, and debugging traces in one place.
For cloud customers, the severity depends on whether the exposure stays inside the sandbox or can be chained into lateral movement. If stolen credentials grant access to storage buckets, model endpoints, CI/CD systems, or observability platforms, the blast radius expands quickly. Even when the attack only leaks prompts or uploaded files, the privacy and compliance implications can be serious. Organizations handling regulated data should assume that any covert exfiltration path may trigger reporting and incident response obligations.
There is also a strategic impact. AI adoption has pushed many teams to treat agent frameworks as application glue rather than security-sensitive runtimes. This disclosure is a reminder that agent infrastructure deserves the same scrutiny as containers, build runners, and remote notebooks. If code can run, egress must be controlled. If data is sensitive, least privilege must be enforced. If tools can act autonomously, every outbound channel matters.
How to protect yourself
First, restrict DNS and all outbound network access from AI execution environments to the minimum needed. If a code interpreter does not need external resolution, block it. If it needs DNS for a small set of internal services, use allowlists and force queries through monitored internal resolvers. Treat DNS as a data channel, not a harmless utility.
Second, remove secrets from runtimes wherever possible. Do not place long-lived API keys, cloud credentials, or internal tokens into agent environments unless absolutely necessary. Prefer short-lived credentials, scoped permissions, and per-task identity. If a tool only needs read access to one bucket or one API route, grant only that.
Third, separate model context from execution context. Retrieved documents, customer records, and hidden prompts should not automatically be exposed to code-running tools. Keep the data plane narrow. The less the interpreter can read, the less it can leak.
Fourth, monitor DNS aggressively. Log queries from AI runtime hosts, alert on high-entropy subdomains, and investigate repeated lookups to rare domains. Security teams should add DNS tunneling detections to any environment running agentic tools or code interpreters.
Fifth, harden prompt and file handling. Many attacks in this class begin with prompt injection or a malicious uploaded artifact that convinces the system to run code. Validate tool invocation paths, require approval for risky actions, and limit what untrusted inputs can trigger. OWASP’s LLM guidance is a useful baseline here OWASP GenAI.
Finally, review vendor documentation and advisories for your specific stack. Managed services may offer controls for network isolation, private endpoints, or execution policies that are not enabled by default. Open-source frameworks may require you to enforce those controls yourself. Where remote staff access sensitive AI tools over public networks, using a trusted VPN service can reduce exposure in transit, but it does not replace sandbox hardening or egress filtering.
The bottom line
The BeyondTrust findings, as reported, highlight a simple but consequential problem: AI sandboxes can still leak if DNS remains open. That makes this less a niche bug than a warning about how AI systems are being deployed. The attack path is technically old, but the environments now exposed to it often hold newer and richer forms of data: prompts, embeddings, traces, internal documents, and cloud-connected tools. Organizations building with Bedrock, LangSmith, SGLang, or similar platforms should reassess any assumption that “sandboxed” automatically means isolated.
