Skip to content
Isorun Docs

Network Filtering

Every sandbox has its own egress policy. By default the policy is “unrestricted” — the VM can reach any host on the public internet. For agent code that runs untrusted scripts or that you only want to talk to specific upstreams, pass allow= and/or deny= at create time.

Allow-list (deny by default)

The most common pattern: deny everything, then allow only the hosts you need.

from isorun import Sandbox


with Sandbox(
    "python",
    deny=["0.0.0.0/0"],                      # block everything
    allow=["api.openai.com", "pypi.org"],    # ...except these
) as sb:
    sb.exec("pip install openai")            # works
    sb.exec("curl https://api.openai.com/v1/models")  # works
    out = sb.exec("curl -m 2 https://example.com")
    assert out.exit_code != 0                # blocked

Deny-list (allow by default)

For policies where you trust most of the internet but want to block specific upstreams:

with Sandbox(
    "python",
    deny=["169.254.169.254", "metadata.google.internal"],
) as sb:
    sb.exec("curl https://example.com")      # works
    out = sb.exec("curl -m 2 http://169.254.169.254/")  # blocked
    assert out.exit_code != 0

Rule shape

Rules are matched against the destination of every outbound TCP connection from the sandbox’s TAP device.

  • CIDR ranges: 0.0.0.0/0, 10.0.0.0/8, 192.168.1.0/24
  • IP literals: 1.2.3.4
  • Hostnames: api.openai.com — matched literally against the destination’s reverse DNS / SNI
  • Wildcards: *.openai.com matches api.openai.com, cdn.openai.com, etc. Doesn’t match openai.com itself — list it separately.

The order of evaluation: deny rules first, then allow. A connection is permitted iff it matches an allow rule and does not match any deny rule.

How it works

The runner installs per-VM iptables rules on the TAP device that forward all outbound packets through nfqueue. A userspace egress enforcer reads each packet, looks up its destination against the sandbox’s policy, and either accepts or drops it. SNI inspection catches HTTPS hostnames before TLS completes; DNS responses are sniffed to keep hostname → IP mappings current.

This means the policy is enforced on the host, outside the sandbox’s network stack. The agent code can’t disable it from inside the VM by modifying iptables, ip routes, or /etc/hosts — those changes only affect the guest’s view, not the host’s enforcement.

Combine with named profiles

If your allow list is one of the common patterns (Anthropic, OpenAI, HuggingFace, etc.), use a Network Profile instead — it’s the same machinery with a friendlier name.

Per-endpoint filtering

For finer-grained control (allow POST /v1/chat/completions but deny DELETE /v1/admin/...), use Endpoint Rules together with credential injection.