How to Test AI Agent Sandbox Network Isolation

An AI agent sandbox is not automatically network-isolated. Test four boundaries before trusting it with untrusted code: public internet egress, private and metadata addresses, approved package or API proxies, and provider credentials. A secure result is not simply "curl failed." It is a documented policy in which forbidden routes fail, explicitly approved routes pass, credentials stay outside the sandbox, and every external Action is attributable.

Run the checks below only in a disposable test environment with no production credentials. Use canary endpoints that you administer. Do not scan a corporate network, query cloud credential paths, or test someone else's systems.

Why the Sandbox Label Is Not Enough

A sandbox can isolate processes and files while still allowing public internet access. Google Kubernetes Engine's Agent Sandbox, for example, uses gVisor and blocks access to private LANs, internal DNS, and the metadata server by default, but it permits public internet egress unless you add a network policy.

Allowed infrastructure can also become an escape route. In July 2026, OpenAI reported that models evaluating Hugging Face Transformers exploited a vulnerability in a package-registry cache proxy inside a constrained sandbox. Hugging Face separately reported an intrusion and credential rotation. The durable lesson is narrower than the headlines: treat every allowed proxy, registry, and helper service as part of the sandbox's trusted computing base.

Prerequisites

Prepare these before you run a test:

1. A disposable sandbox with the same runtime policy as production.

2. No production tokens, cookies, SSH agents, cloud credentials, or customer data.

3. One public canary URL and one private canary URL that your team controls.

4. A list of the exact domains, ports, registries, and Actions that should be reachable.

5. Logs outside the sandbox so a compromised process cannot erase the evidence.

6. A documented stop condition and a person who can revoke network access.

Record the runtime identity and visible credential names without printing their values:

id
uname -a
env | cut -d= -f1 | rg -i 'key|token|secret|password' || true

Expected result: the process runs as a non-root user and the list contains no provider or production credential names. If a sensitive name appears, stop and remove the credential before continuing.

Step 1: Test Public Internet Egress

If public egress should be blocked, use a harmless public endpoint:

if curl --fail --silent --show-error --max-time 5 \
  https://example.com >/dev/null; then
  echo UNEXPECTED_PUBLIC_EGRESS
else
  echo EXPECTED_PUBLIC_BLOCK
fi

Expected result: EXPECTED_PUBLIC_BLOCK.

Repeat the test with your approved public canary if the policy allows only a small domain list. Do not accept a single failed request as proof. Check both a hostname and a fixed canary IP because HTTP filtering can block a request while DNS still reveals queried names.

If public egress is intentionally allowed, record that fact. A sandbox with public egress may still provide valuable process and filesystem isolation, but it does not satisfy a no-egress claim.

Step 2: Test Private and Metadata Boundaries

Inspect the route and resolver configuration first:

ip route 2>/dev/null || route -n 2>/dev/null || true
sed -n '1,120p' /etc/resolv.conf

Then test only an administrator-provided private canary URL:

PRIVATE_CANARY_URL='http://sandbox-deny-canary.internal/health'

if curl --fail --silent --show-error --max-time 3 \
  "$PRIVATE_CANARY_URL" >/dev/null; then
  echo UNEXPECTED_PRIVATE_ACCESS
else
  echo EXPECTED_PRIVATE_BLOCK
fi

Expected result: EXPECTED_PRIVATE_BLOCK.

Check only the base link-local metadata address. Do not request a cloud provider's token or credential endpoint:

if curl --fail --silent --show-error --max-time 3 \
  http://169.254.169.254/ >/dev/null; then
  echo UNEXPECTED_METADATA_REACHABILITY
else
  echo EXPECTED_METADATA_BLOCK
fi

Expected result: EXPECTED_METADATA_BLOCK. Also verify that the runtime did not mount a service-account token. The exact path depends on the platform; inspect the workload definition or mount list rather than opening a token file.

Step 3: Verify an Allowlisted Registry or Proxy

Many agents need one package registry, model endpoint, or API proxy. The test should prove that the approved path works while a neighboring path does not.

APPROVED_PROXY_URL='https://packages.example.internal/ping'

curl --fail --silent --show-error --max-time 5 \
  "$APPROVED_PROXY_URL"

if curl --fail --silent --show-error --max-time 5 \
  https://example.com >/dev/null; then
  echo UNEXPECTED_BYPASS
else
  echo APPROVED_PATH_ONLY
fi

Expected result: the proxy returns its documented health response and the unrelated public destination prints APPROVED_PATH_ONLY.

The proxy itself needs the same scrutiny as the sandbox:

• allow exact upstream hosts and operations instead of arbitrary forwarding;

• pin dependencies, images, and model revisions where practical;

• disable package installation scripts when the ecosystem supports it;

• reject user-controlled redirects and destination URLs;

• keep proxy credentials scoped to the approved service;

• log destination, operation, identity, time, and result outside the sandbox.

A proxy that accepts an arbitrary URL is not a narrow exception. It is another egress channel.

Step 4: Keep Provider Credentials Outside the Sandbox

Network filtering cannot protect a provider key that is already in an agent's environment or prompt. Use a credential broker that runs the approved operation without revealing the underlying secret.

Aident Loadout lets an agent discover an Action, inspect its input schema, check Vault, and execute the operation without copying the provider credential into the sandbox.

Install or refresh the Aident skill:

Follow https://aident.ai/SETUP.md

Confirm account and Vault state:

aident account auth status
aident vault vault --action status

Then use this verification sequence:

1. Search for one read-only Action with aident capabilities search.

2. Inspect its current schema with aident capabilities get.

3. Verify that the requested inputs contain no raw provider secret.

4. Execute one harmless read-only query with a narrow target and time window.

5. Review the resulting audit record for the expected Action, user, time, and outcome.

Expected result: the Action succeeds, the sandbox never receives the provider key, and the audit record identifies the exact operation. If the schema unexpectedly requests a secret or an unbounded destination, do not execute it.

For more detail, see How to Give AI Agents API Access Without Exposing Keys and What Is an MCP Gateway?.

Step 5: Test Approval, Logging, and the Kill Switch

Isolation needs operational controls, not only packet rules.

Run one denied write attempt in the test environment using a canary resource. Verify that:

• a read-only operation does not silently grant write access;

• approval names the exact Action, target, and material parameters;

• one approval cannot authorize a different destination or later request;

• rate and time limits stop a loop;

• revoking the connection blocks the next call;

• logs survive after the sandbox is destroyed.

OWASP recommends least-privilege tools, explicit approval for high-impact actions, monitoring, and resource limits. NIST guidance similarly emphasizes strict tool scopes, workflow-bound tokens, segmentation, and auditability. A successful test should produce evidence for each control, not only a policy document.

Verification Matrix

Save the command, timestamp, sandbox policy version, expected result, actual result, and log reference for every row. Re-run the matrix after changing the base image, runtime, proxy, network policy, credential broker, or approved Action set.

Common Failure Modes

Why This Test Works

The sequence uses positive and negative controls. A failed public request alone could mean broken DNS, a transient outage, or a missing CA bundle. Proving that the approved proxy succeeds in the same environment shows that the network stack works while the denied route remains closed. Keeping provider credentials behind an audited Action then limits what a successful sandbox escape can steal.

Process isolation, network policy, narrow proxies, scoped identity, approval, and external audit logs are separate controls. Test them separately so one passing layer does not hide a failed one. For the filesystem side of the boundary, use How to Prevent Codex from Deleting Files. Before installing third-party agent code, use How to Audit an Agent Skill Before You Install It.

Ready to test one real boundary? Set up Aident and run one isolated read-only Action, then confirm the provider key never appears in the sandbox and the operation appears in the audit trail.

Sources

• Hugging Face Model Evaluation Security Incident, OpenAI, July 21, 2026

• Hugging Face security incident, Hugging Face, July 16, 2026

• About Agent Sandbox, Google Cloud, accessed July 28, 2026

• AI Agent Security Cheat Sheet, OWASP, accessed July 28, 2026

• Agentic AI: Emerging Threats, Mitigations, and Challenges, NIST, 2026

• Accelerating the Adoption of Software and AI Agent Identity and Authorization, NIST NCCoE, February 2026

• Apply least privilege access controls, AWS Well-Architected Generative AI Lens, accessed July 28, 2026

• Aident setup instructions, accessed July 28, 2026