How to Secure AI Agent Sandboxes: Egress, Secrets, and Endpoints

An AI agent can execute the right code and still have too much access. A repository task may need a package mirror and one artifact bucket. It rarely needs your production database, the Kubernetes API, or every other customer’s workspace. Before putting code-executing agents into production, define those boundaries and test them from inside the actual runtime.

TL;DR

• Start with an explicit list of destinations, operations, and credentials each task needs.
• Test network controls from the sandbox; a policy file alone does not prove enforcement.
• Keep infrastructure control credentials outside agent-controlled processes.
• Repeat acceptance tests after restart, restore, and configuration changes.

What should an agent be allowed to reach?

Write an access contract for one real task. For example, a code-review agent checks out a repository, installs approved dependencies, runs tests, and uploads a report. Give each step a named destination and a limited operation. This makes exceptions visible before they become permanent privileges.

Resource	Required access	Acceptance check
Repository	Read a named repository	Checkout succeeds; an unrelated repository is inaccessible
Dependency mirror	Download approved packages	Approved install works; an unapproved destination is blocked
Artifact storage	Write under this task’s prefix	Upload works; another tenant’s prefix is denied
Production systems	No access for this task	Connections fail from the executing process
Sandbox control API	Orchestrator only	Agent cannot obtain or use its credential

Include DNS, package redirects, Git submodules, telemetry, and callback URLs in the review. A task that works only after unrestricted internet access is enabled has an unresolved dependency. Identify it rather than keeping the exception as the final configuration.

How do you verify egress controls actually work?

Kubernetes NetworkPolicy requires a network implementation that enforces it. Policies are additive: another matching policy can allow traffic that you expected to block. Standard NetworkPolicy also does not express HTTP paths or domain-name allowlists. These details matter when a requirement such as “only our package registry” is translated into infrastructure configuration. See the Kubernetes NetworkPolicy documentation.

Use a disposable test sandbox with the same image, identity, labels, network path, and policy configuration as production. Attempt an allowed request and a disallowed request to destinations you control. Record the destination, protocol, expected result, observed result, and timestamp. A timeout is useful evidence only when you have also shown that the destination was reachable from the control environment.

Test direct IP access as well as normal DNS resolution. Where IPv6, proxies, or service meshes are enabled, test those paths too. Include cloud metadata and cluster-management endpoints in the denied-destination review. Network rules are one layer; host configuration, workload identity, and runtime isolation need their own controls.

If your policy depends on an egress gateway, test what happens when that gateway is unavailable. The intended result is a failed task with a clear error, rather than an unnoticed route around the restriction. Keep probes limited to infrastructure you own or have permission to test.

Where should agent credentials live?

Separate the credential that creates and deletes sandboxes from credentials used by code inside them. The orchestrator may need broad lifecycle permissions. The task usually needs a much narrower token for a specific service and a short period.

For a report-writing task, prefer a credential scoped to its artifact prefix, with an expiry that covers the expected run. Test both the allowed operation and an operation outside that scope. A token that expires successfully but can read every customer’s artifacts is still too broad.

Kubernetes Secrets require careful configuration: base64 encoding is not encryption, and access through RBAC must be restricted. Avoid placing credentials in source repositories, container images, or logs. Follow the Secrets good practices, including encryption at rest and limited read permissions.

Inspect the task’s output, environment dumps, crash reports, and retained workspace using synthetic credentials. Check that secret redaction covers both success and failure paths. Revoking access must also work while a task is still running; validate what the application does when its next authenticated request fails.

Disable automatic service-account token mounting when the workload does not need Kubernetes API access. When it does, grant only the necessary operations and resources. The Kubernetes security checklist covers this along with workload and credential controls.

What changes when the sandbox exposes a public endpoint?

An agent may start a web preview, debugger, or TCP service. Treat every exposed port as a separate access decision. Confirm who can reach it, how callers authenticate, when access expires, and what happens after the task is deleted.

Run the same checks with an authenticated caller, an unauthenticated caller, and a caller belonging to a different test tenant. A hard-to-guess URL is insufficient evidence of authorization. Check websocket or other long-lived connections if the application uses them, including whether revocation closes existing access or only blocks new sessions.

Nirvana’s Agent Sandboxes documentation describes dedicated customer infrastructure, optional persistent workspaces, and HTTP/TCP gateway access. Sandbox control credentials are distinct from general cloud API credentials. Work with the Nirvana team to confirm the network and endpoint controls for your deployment; sandbox setup requires the team.

What evidence should you require before production?

Keep one acceptance record per runtime configuration. Record image and policy versions, credential scopes, test identities, and the observed results. Include a working legitimate task alongside the denial tests so the configuration is both useful and constrained.

Repeat the checks after a sandbox restart and after restoring a persistent workspace. Old configuration files, cached credentials, and generated scripts can survive with the workspace. Recovery should preserve useful work without silently restoring privileges that were removed.

Assign an owner to each failed check and decide which failures block launch. Unauthorized cross-tenant access, reachable control credentials, and exposed unauthenticated administrative services should be resolved before production use. Keep performance measurements separate from security acceptance: a fast successful task proves neither isolation nor correct authorization.

Frequently asked questions

Does a private network make untrusted code safe?

It reduces some exposure, but reachable internal services may still be sensitive. Verify identities, permitted destinations, runtime boundaries, and access to other tenants.

Can a persistent workspace contain secrets?

It can retain any files the workload writes. Use synthetic secrets to test persistence and cleanup, then design credential delivery and revocation around the result.

Should every agent have internet access?

Only when its task requires it. Define the destinations and operations first, then choose controls that can enforce that contract.

Building a production agent? Explore Nirvana and bring your access requirements to the team. For the broader deployment decision, read our code interpreter build-or-buy guide.

Technical references reviewed 14 October 2026. The checks above are a proposed acceptance procedure, not reported benchmark or security-test results.

---

About Nirvana Labs

Nirvana Labs is a high-performance storage cloud purpose built for blockchain, AI and databases i.e. the most demanding, real-time, stateful workloads. Accelerated Block Storage (ABS) offers 20K baseline IOPS included, no over provisioning. Nirvana Kubernetes Service (NKS) with Karpenter auto-scaling, high clock-speed compute and private networking. Backed by Jump Trading, Crucible, etc with 50+ customers live in production today.

Learn more about Nirvana Labs.

Nirvana Cloud · Pricing · Blog · Docs · Changelog · LinkedIn · Twitter · Telegram · YouTube