Internet access and egress

Default network behavior

• Inbound. A sandbox is not reachable from the internet. Only the ports you expose as a preview accept traffic, and only through the MIOSA proxy.
• Outbound. A new sandbox can reach the internet. It starts in audit-only mode: no outbound call is blocked. Egress audit capture is not yet enabled in the current release, so calls are not recorded yet. A Computer’s network policy defaults to unrestricted.

So by default your code can install packages, call APIs, and clone repos. Nothing is blocked until you choose to enforce an allowlist.

What a sandbox cannot reach

A sandbox cannot reach the platform’s own internal network. The only exception is the managed-database proxy range, which is what a managed Postgres, MySQL, or Redis connection uses inside the sandbox. This is a mesh-level deny, checked before the egress allowlist, so adding an internal host to an allowlist does not open it. It is enforced on both runtimes.

169.254.169.254 is not an egress destination on MIOSA. It is Firecracker’s metadata service (MMDS), the guest-side channel the host uses to hand a sandbox its identity and configuration, and it is answered inside the machine rather than on the host network. Leave it denied, as the examples below do.

Two layers of control

MIOSA gives you two ways to constrain outbound traffic. They compose.

A Computer or Sandbox resolves its egress policy as: resource override, then tenant default. The tenant default starts in audit_only mode.

Watch, then enforce

The intended path for a sandbox is to observe real traffic, then lock it down to what it actually uses. This is the same flow documented in full on the network allowlist reference:

1. Observe. Let the sandbox run normally. Every outbound host is recorded.
2. Review. Pull the hosts it contacted, ranked by frequency.
3. Enforce. Apply those hosts as the allowlist and switch the policy to enforce. Unlisted hosts are then blocked.
4. Operate. Blocked hosts land in a pending queue with one-click allow or deny. Revert to audit-only at any time without losing the allowlist.

Allowlist rules

Rules are matched in priority order: exact beats wildcard, wildcard beats CIDR, and an explicit deny always beats an allow. A rule can be scoped to a method and a path, and marked warn_only to let the request through while flagging it in the audit log.

Rules attach at two levels: per-resource (one sandbox or computer) and tenant-wide (every resource unless overridden).

Restrict a Computer at the microVM level

Computers also accept a network policy that takes effect within seconds, without a restart.

A PUT replaces the whole policy; send every rule on every call. DELETE resets it to unrestricted.

Credentials on the way out

Egress is also where MIOSA swaps placeholders for real credentials. Your workload sees an opaque miosa-tok-... value in its environment; the proxy substitutes the real secret on the outbound request, so the value never lives inside the sandbox. See Secrets and the Egress API.

Debug a blocked call

Common allowlist gaps:

• pip install needs pypi.org, files.pythonhosted.org, and pythonhosted.org.
• npm install needs registry.npmjs.org; some postinstall scripts also reach *.github.com.
• CDNs and dynamic subdomains are usually not covered by an exact rule. Use a wildcard like *.openai.com.

Every blocked row carries a rejected_by field naming the rule that fired. For the full list of fixes, see Security troubleshooting.

See also