On this page

Network Allowlist

By default, every new MIOSA sandbox runs in audit-only mode: every outbound call is recorded, none are blocked. After your sandbox has been running for a while, MIOSA shows you the list of hosts it actually contacted - and you can flip to enforce mode in one click, with that list as the allowlist.

The two modes

ModeWhat it doesDefault?
Audit-onlyLogs every outbound request. Nothing is blocked.✅ yes - every new sandbox starts here
EnforceApplies the allowlist. Requests to unlisted hosts are blocked.opt-in

The “watch then enforce” flow

Day 0 - Sandbox is created

No setup. Audit-only is on by default. Your sandbox makes outbound calls exactly like it did before MIOSA Egress existed. Every call is logged silently.

Day 0-7 - Use your sandbox normally

Build, deploy, run your agent - whatever. MIOSA collects audit data.

Day 7+ - Visit the Network tab

The Network tab shows you:

HOSTS CONTACTED IN THE LAST 7 DAYS                  REQUESTS

api.openai.com                                        1,247
*.anthropic.com                                          83
github.com                                               412
pypi.org                                                  29
files.pythonhosted.org                                   161
api.github.com                                          1,053

Click “Lock Down”. A confirmation modal appears showing the checkboxes for each host. You uncheck anything you don’t want. Click Confirm.

Mode flips to enforce. The proxy now blocks anything not on the list.

After lockdown - New hosts go to Pending

If your sandbox tries to reach a host that isn’t on the allowlist, the request is blocked AND the host appears in the Pending Requests section of the Network tab. One click → Allow or Block.

You’re never stuck - denied requests are visible, attributable, and one click away from resolution.

SDK - Network controls

Pattern matching

KindExampleMatches
Exact hostapi.openai.comonly this hostname
Wildcard*.openai.comany subdomain of openai.com
CIDR (IP only)10.0.0.0/8any IP in this range, only when the request target is an IP literal (not a hostname)

Precedence at request time:

  1. Exact match wins over wildcard
  2. Wildcard wins over CIDR
  3. Explicit deny rules always win over allow

Per-resource vs tenant-wide rules

You can attach allowlist rules at two levels:

  • Per-resource - applies to just one sandbox or computer
  • Tenant-wide - applies to every resource in your tenant unless a resource has its own override

This means you can have a tenant default of “only allow our internal API + npm” and per-sandbox additions on top.

When to use warn-mode rules

You can mark a rule as warn_only:

sandbox.network.allow("api.experimental.example.com", warn_only=True)

In enforce mode, a warn_only allow rule still lets the request through but flags it in the audit log. Useful for trial-running a new third-party integration before committing to it.

Rolling back

If lockdown breaks something:

sandbox.network.observe()

You’re back to audit-only. Allowlist rules are preserved (so you can re-lockdown later) but they’re no longer enforcing.

Real-world example - Python data pipeline locked to its upstream services

A Python sandbox that fetches data from a REST API, processes it, and writes results to an S3-compatible endpoint. Locked down to exactly those three hosts.

Troubleshooting

pip install fails after lockdown - “Could not find a version that satisfies the requirement”. Three domains are needed: pypi.org, files.pythonhosted.org, and pythonhosted.org. Allow all three before locking down.

npm install fails after lockdown. Allow registry.npmjs.org. Some packages also fetch from *.github.com during postinstall scripts - check the Pending queue for exact hosts.

My sandbox is in enforce mode but I see unexpected hosts in the audit log. Audit-only log entries always appear even in enforce mode (blocked calls still get logged with action=reject). Filter by action=reject to see what’s being blocked.

I want the same policy on every new sandbox without configuring each one. Apply rules at the tenant level using client.network.allow(...) and client.network.lockdown() - these become the default for all resources in the tenant unless overridden per sandbox.

After observe(), my rules are gone when I call lockdown() again. Rules are never deleted by observe(). If they appear missing, check sandbox.network.get_policy().allow_rules - they’ll be listed there. The only way rules disappear is if you called sandbox.network.clear_rules() explicitly.

For more issues, see the Security troubleshooting hub.

Frequently asked

Will lockdown block npm install or pip install? Only if you don’t allow pypi.org, files.pythonhosted.org, registry.npmjs.org, etc. The 7-day audit data will have already shown you these - they’re on the suggested list.

My agent suddenly stopped working after I locked down. Open the Network tab → Pending Requests. You’ll see exactly what got blocked. One-click allow, or revert with observe().

Can I share allowlists across sandboxes? Yes - apply them at the tenant or workspace scope, or copy a “policy template” from another resource (Phase 5).

Does lockdown affect inbound (preview) traffic? No. Lockdown is for outbound only. Preview URLs into your sandbox keep working exactly as before.

Was this helpful?