Network Allowlist

By default, every new MIOSA sandbox is configured in audit-only mode: outbound calls are not blocked. Audit-only mode logs every outbound request, so you can see which hosts your sandbox calls before you lock down.

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. Outbound calls are logged, and the hosts they reach build your allowlist.

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.

Reuse a policy across sandboxes

Export a locked policy and apply it to a new sandbox:

# Export the policy from a locked sandbox
policy = sandbox.network.get_policy()

# Apply it to a new sandbox
new_sandbox = client.sandboxes.create(template_id="python-ds")
for rule in policy.allow_rules:
    new_sandbox.network.allow(rule.host, methods=rule.methods)
for rule in policy.deny_rules:
    new_sandbox.network.deny(rule.host)
new_sandbox.network.lockdown()
print(f"Policy cloned to {new_sandbox.id}.")

For the same policy on every new sandbox, apply rules at the tenant level with client.network.allow(...) and client.network.lockdown(); they become the default for all resources unless a sandbox overrides them.

Full script

End-to-end: observe, review, lock down, and check the pending queue.

#!/usr/bin/env python3
"""lockdown_workflow.py  -  audit-only to enforce in one pass"""

import os, time
from miosa import Miosa

client = Miosa(api_key=os.environ["MIOSA_API_KEY"])
sandbox = client.sandboxes.create(template_id="python-ds")
print(f"Sandbox {sandbox.id}  -  mode: {sandbox.network.get_policy().mode}")

# 1. Observe (use 7d in production)
time.sleep(10)

# 2. Review observed hosts
suggestions = sandbox.network.suggestions(since="1h")
for h in suggestions:
    print(f"  {h.host}  ({h.request_count} requests)")

# 3. Lock down with the observed hosts as the allowlist
for h in suggestions:
    sandbox.network.allow(h.host)
sandbox.network.lockdown()
print(f"Locked. Mode: {sandbox.network.get_policy().mode}")

# 4. Check what is still being blocked
pending = sandbox.network.pending()
for p in pending:
    print(f"  {p.host}  ({p.request_count} blocked)")

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.

An agent stopped working after lockdown and I cannot tell what is blocked. Open the Network tab -> Pending Requests, or call sandbox.network.pending(). Each blocked row has a rejected_by field naming the rule that fired.

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 page helpful?