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
| Mode | What it does | Default? |
|---|---|---|
| Audit-only | Logs every outbound request. Nothing is blocked. | ✅ yes - every new sandbox starts here |
| Enforce | Applies 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
| Kind | Example | Matches |
|---|---|---|
| Exact host | api.openai.com | only this hostname |
| Wildcard | *.openai.com | any subdomain of openai.com |
| CIDR (IP only) | 10.0.0.0/8 | any IP in this range, only when the request target is an IP literal (not a hostname) |
Precedence at request time:
- Exact match wins over wildcard
- Wildcard wins over CIDR
- Explicit
denyrules always win overallow
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.