DNS Exfiltration Risks in AI Agent Sandboxes

DNS exfiltration risk matters when sandboxed code can resolve attacker-controlled domains or use DNS as an outbound data channel, so teams should evaluate DNS policy, logging, package-fetch paths, and incident evidence before trusting an AI agent sandbox with sensitive workflows.

Why DNS Matters In Sandbox Threat Models

AI agent sandboxes are built for useful autonomy. A coding agent may run tests, install packages, call APIs, launch a browser, inspect files, and produce artifacts without a human approving every command. That flexibility is exactly why network behavior needs its own review, separate from CPU, memory, file system, and process isolation.

DNS often gets less attention than HTTP egress because it looks like infrastructure plumbing. Applications need name resolution to reach APIs, registries, web pages, and update endpoints. But DNS is still outbound communication. A sandbox that can resolve arbitrary domains can reveal information through query names, contact attacker-controlled infrastructure, or create a blind spot if DNS traffic is not logged with the same care as web requests.

This is not a theoretical category invented for AI agents. MITRE ATT&CK documents DNS as an application-layer protocol that adversaries can use for command-and-control communication, and it separately documents exfiltration over alternate protocols when data leaves over a channel that is not the main application protocol. For sandbox evaluators, the lesson is straightforward: do not treat DNS as harmless just because it is not an HTTP POST.

For AI agents, the risk usually comes from a chain of small permissions rather than one obvious mistake:

Sandbox capability	Why teams allow it	DNS-related question
Package installation	Let agents install missing dependencies	Which registries and resolver paths are allowed?
Web access	Let browser agents gather public context	Can code resolve any domain or only approved domains?
API calls	Let agents integrate with app backends	Are internal domains and metadata endpoints blocked?
Build tools	Let coding agents run realistic tests	Can post-install scripts trigger unexpected lookups?
Long-running sessions	Let agents continue multi-step tasks	Are DNS logs retained across the full session lifecycle?

The goal is not to ban every network call. Many agent workloads need controlled network access. The goal is to know which paths exist, which paths are blocked, and what evidence you would have if a task behaved unexpectedly.

Where DNS Resolution Appears In Agent Workflows

Security reviews often ask whether a sandbox has internet access. That question is too broad. A better review starts by mapping every place where code, tools, package managers, or browsers may trigger name resolution.

Common DNS paths include:

• Direct code requests from Python, JavaScript, shell scripts, SDKs, and test suites.
• Browser automation that loads pages, subresources, fonts, images, analytics scripts, and redirects.
• Package managers such as npm, pip, uv, pnpm, apt, cargo, or language-specific plugin installers.
• Build tools that fetch binaries, templates, browser drivers, model files, or test fixtures.
• Agent tools that call third-party APIs or webhook endpoints.
• Background jobs that continue running after the visible agent step has returned.

That mapping should include both intended and incidental traffic. A developer may only ask an agent to run a unit test, but the test command may install a package, the package manager may resolve a registry domain, and a lifecycle script may contact a separate host. A browser task may be scoped to one public site, while embedded resources resolve many additional domains.

For a sandbox provider, the strongest answer is not just “network access is available” or “network access is isolated.” The useful answer explains the resolution path:

• Does sandbox DNS use a provider-controlled resolver, customer-controlled resolver, VPC resolver, or public resolver?
• Can the customer restrict domains, IP ranges, ports, or protocols?
• Are DNS requests logged per sandbox, per session, per command, or only at an aggregate network layer?
• Are denied lookups logged, or only allowed lookups?
• Can customers separate package-fetch DNS from runtime DNS?

If those details are unavailable, treat them as open evaluation items, not as proof that the sandbox is unsafe. The practical risk depends on the sensitivity of the workload, the secrets available inside the sandbox, the outbound policy, and the quality of forensic evidence.

How To Evaluate Outbound Policy

Outbound policy is the control surface that decides whether DNS becomes routine plumbing or an unreviewed escape path. A mature policy should answer three questions: what is allowed, why it is allowed, and how exceptions are approved.

Start with the default posture. A sandbox used for untrusted AI-generated code should not inherit the same broad network access as a developer laptop. If the default is open egress, ask whether the product supports narrowing that access for higher-risk workloads. If the default is restricted egress, ask how developers enable the exact domains needed for a task.

Then separate DNS policy from HTTP policy. Some systems enforce HTTP allowlists but leave name resolution broad. That can create a mismatch: a request to an unapproved host may fail at the HTTP layer, yet the DNS query still leaves the environment and may still carry metadata in the queried name. A stricter design evaluates resolution and connection attempts together.

For security reviews, use a policy matrix like this:

Evaluation area	What to ask	Stronger evidence
Default egress	Is outbound network access open, denied, or scoped by template?	Written default policy plus a sandbox-level test result
DNS resolver path	Which resolver handles sandbox DNS?	Architecture diagram or configuration proof
Domain allowlists	Can teams allow only approved registries and APIs?	Config example and deny-log example
IP and private network blocks	Are internal ranges and metadata services blocked by default?	Documented deny rules and test evidence
Protocol controls	Are DNS, HTTP, HTTPS, and raw sockets controlled separately?	Policy model, not only marketing wording
Exception workflow	Who can add domains or relax policy?	Role-based approval and audit record

For most teams, the first practical target is not a perfect zero-egress environment. It is a documented minimal-egress profile: approved package registries, approved API domains, no access to internal networks unless explicitly routed, and logs for both allowed and denied attempts.

Package Fetches And Dependency-Driven DNS

Package installation is one of the easiest ways to underestimate sandbox egress. Agent-generated code often fails on missing dependencies, and the fastest developer experience is to let the agent install what it needs. That convenience creates a second supply-chain problem: package names, registry redirects, install scripts, and binary downloads can trigger DNS and network activity that the original prompt never mentioned.

OWASP’s LLM application guidance calls out risks around excessive agency and supply-chain exposure. In agent sandboxes, those risks meet in package installation. A model may be allowed to choose commands. A command may invoke a package manager. The package manager may fetch code from a registry. The fetched package may run installation hooks. Each step may create DNS lookups and outbound connections.

Defensive evaluation should focus on governance, not exploit mechanics:

• Prefer pinned dependency files for repeatable agent tasks.
• Use approved registries or pull-through caches for common ecosystems.
• Log package name, version, registry URL, resolved domains, and artifact hashes where practical.
• Separate package-install permission from general runtime internet access.
• Require approval before installing packages outside an allowlist for sensitive workspaces.
• Consider prebuilt sandbox templates for common stacks so agents do not need broad network access during every run.

The important distinction is that “package fetch” is not one control. It includes DNS resolution, registry authentication, artifact download, install-time code execution, and cache behavior. A good sandbox review asks about the entire path.

Secrets And Data Exposure Assumptions

DNS exfiltration only matters if there is something meaningful to leak. That makes secret placement and data scoping part of the DNS review.

AI agent sandboxes should be treated like untrusted build workers unless proven otherwise. Do not place long-lived production credentials, broad cloud tokens, customer data, or internal source code into a sandbox just because the sandbox is isolated from the host. Isolation reduces blast radius, but it does not make every command safe.

Use these assumptions when designing higher-risk workflows:

• Any file readable by agent-executed code could be included in logs, outputs, network requests, or error messages.
• Any environment variable visible to a process could be copied by that process.
• Any outbound channel allowed to the sandbox deserves the same data-loss review, including DNS.
• Any prompt-injected instruction in a browser or document workflow may try to influence tool use.
• Any long-running session increases the value of lifecycle logs and token expiration.

Practical controls include short-lived credentials, least-privilege API keys, scoped service accounts, per-task secrets, redacted logs, and explicit separation between public-data research tasks and sensitive-code execution tasks.

Logs, Audit Trails, And Incident Evidence

DNS controls are only useful if teams can verify them. When a sandbox task is suspicious, security teams need evidence quickly: what ran, what resolved, what connected, what files changed, and which outputs were returned.

At minimum, ask whether the platform can reconstruct these events for a specific sandbox session:

• Sandbox creation time, template, resource configuration, and owner.
• Commands executed by the agent or user.
• Files read, written, uploaded, or downloaded when the product exposes file operations.
• Package installs and registry fetches.
• DNS queries, including timestamp, queried name, outcome, and sandbox/session identifier.
• Outbound connection attempts, including destination host, IP, port, protocol, allow/deny outcome, and volume where available.
• Tool calls, browser navigation events, and background processes.
• Secret injection events without exposing secret values in logs.
• Session termination, pause, resume, snapshot, and cleanup events.

Do not only ask for successful-traffic logs. Denied events are often more useful for evaluating whether policy worked. If a sandbox tries to resolve an unapproved domain and the policy blocks it, that denied lookup is the evidence that separates a functioning control from a silent failure.

Retention also matters. A seven-day log window may be enough for debugging but weak for incident response. Teams with regulated or customer-sensitive workloads should align sandbox telemetry retention with their broader security logging policy.

Novita Agent Sandbox Evaluation Notes

Novita Agent Sandbox is designed for AI agent workflows that need isolated code execution, browser automation, computer-use style tasks, long-running sessions, and evaluation or reinforcement-learning workloads. The Novita Agent Sandbox overview is the right starting point for current product behavior, and the Agent Sandbox product page describes the broader platform fit.

When evaluating Novita or any other sandbox provider for DNS-sensitive workloads, separate two kinds of statements:

• Product fit: whether the sandbox supports the agent workflow you need, such as code execution, browser automation, or long-running tasks.
• Security control evidence: whether the exact DNS, egress, package-fetch, secret, and log controls meet your internal policy.

That separation prevents overclaiming. A sandbox can be a strong fit for agent execution and still require a specific customer review for DNS policy, resolver path, allowlists, audit retention, and incident workflows. Security teams should ask for current documentation or product confirmation for those control details before approving sensitive workloads.

For teams already using Novita AI models, the platform fit is that model APIs and agent execution infrastructure can be evaluated together. That can reduce operational sprawl, but it does not remove the need for a threat model. Treat the sandbox as a controlled execution environment, define what network access each agent class needs, and validate that the control evidence matches the risk of the data placed inside.

Security Review Checklist

Use this checklist before approving AI agent sandbox workloads that may touch sensitive code, credentials, customer data, or internal systems.

Review question	Why it matters
What can the sandbox resolve by default?	DNS can be an outbound signal even when HTTP is blocked.
Can DNS be restricted by domain, template, workspace, or VPC policy?	Sensitive workflows need narrower defaults than public research tasks.
Are DNS queries logged per sandbox session?	Incident response needs attribution, not only aggregate resolver metrics.
Are denied DNS and connection attempts logged?	Denied events prove that policy blocked unexpected behavior.
Are package registries allowlisted or proxied?	Package managers can trigger dependency-driven DNS and downloads.
Can package installs be separated from runtime network access?	Build-time and run-time risk are different.
Are internal IP ranges and metadata endpoints blocked?	Agents should not discover or contact infrastructure control planes by accident.
How are secrets injected, scoped, rotated, and redacted?	DNS review is incomplete if long-lived secrets are available to sandboxed code.
Are browser subresources visible in logs?	Browser agents may resolve more domains than the top-level URL.
What evidence is available after pause, resume, snapshot, or cleanup?	Long-running sessions need lifecycle-aware telemetry.
Who can relax egress policy?	Exception changes should be auditable.
How are suspicious sessions preserved?	Cleanup should not erase the only useful incident evidence.

If several answers are unknown, keep the workload out of the sandbox until the provider or internal platform team can document the control path. If the workload only handles public data and uses no secrets, the same gaps may be acceptable during early prototyping, but they should still be tracked before production use.

Conclusion

For production agent sandboxes, review DNS as part of egress, not as a footnote. The minimum defensible setup is a scoped outbound policy, explicit package-fetch governance, short-lived secrets, per-session DNS and connection logs, and a tested incident workflow for preserving evidence.

Use broader network access for low-risk prototypes only when the data is non-sensitive and the agent has no meaningful secrets. For sensitive codebases, customer data, internal APIs, or regulated workflows, require a minimal-egress profile and current provider evidence before granting agents autonomous execution.

FAQ

Is DNS Exfiltration Relevant If The Sandbox Blocks HTTP?

Yes. HTTP controls and DNS controls are different layers. A sandbox may block outbound web requests while still allowing DNS queries. Security teams should verify both resolution policy and connection policy.

Should AI Agent Sandboxes Have No Internet Access?

Not always. Many useful agent tasks need package registries, public documentation, APIs, or browser access. The safer goal is minimal, explainable egress: allow what the task needs, deny what it does not, and log both allowed and denied activity.

Are Package Installs The Same As General Network Access?

No. Package installs deserve a separate policy because they involve registries, dependency resolution, artifact downloads, and sometimes install-time scripts. A team may allow package fetches through an approved cache while denying arbitrary runtime egress.

What Logs Matter Most For DNS Risk?

The most useful logs connect a DNS query to a specific sandbox, command, time, user or agent workflow, and policy decision. Denied lookup logs are especially important because they show whether the control actually worked.

Can A Sandbox Provider Guarantee No Data Exfiltration?

Be careful with absolute guarantees. A provider can offer isolation, network controls, logging, and configuration options, but the final risk depends on workload design, secrets, data placement, outbound policy, and operational monitoring.

Recommended Articles

• How Agent Sandboxes Power Secure, Scalable AI Innovation
• Building a Coding Agent with Novita’s Agent Sandbox
• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library