> ## Documentation Index
> Fetch the complete documentation index at: https://vetta.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Networking
> Outbound access from the sandbox, and the coming egress pinning.
A [computer](/docs/computer/index) has general **outbound network access** — the agent can install packages, call APIs, and fetch data without extra configuration. Inbound access is opt-in and governed.
## Outbound access
Outbound connectivity is available by default. Commands run through the [shell](/docs/computer/shell) and requests made by tools reach the network as you'd expect.
### What is blocked, precisely
Outbound from the sandbox is filtered on the egress path, and the filter is **not** a general private-address block. Stated exactly, so you can plan against it rather than around it:
| Destination | From `bash` and tools | From the [browser](/docs/computer/browser) |
| ---------------------------------------------------------- | ----------------------------------------- | ------------------------------------- |
| Cloud metadata (`169.254.0.0/16`, incl. `169.254.169.254`) | **Blocked** | **Blocked** |
| `10.0.0.0/8`, `172.16.0.0/12` | **Blocked** | **Blocked** |
| `192.168.0.0/16` | **Not reliably blocked** | **Blocked** |
| The sandbox's own loopback (`127.0.0.1`) | Reachable — it is the agent's own machine | **Blocked** |
| Public internet | Open | Only what `allowed_domains` permits |
**Shell egress is not filtered by host.** Cloud-metadata endpoints (`169.254.169.254`) and the `10.0.0.0/8` and `172.16.0.0/12` ranges are unreachable from a sandbox, and so is almost every `192.168.0.0/16` address — but that is the network's own routing, not a guarantee we enforce, and it is **not complete**: at least one `192.168.x.x` host answers. Do not treat "RFC1918 is blocked" as a security boundary for `bash`, and do not run a service an agent must not reach on a network the sandbox shares.
The one control that *is* a boundary is `allow_outbound: false` at [create](/docs/computer/sandbox#create) time — a complete, verified kill-switch for all outbound traffic, immutable for the life of the computer. There is no per-host or per-domain shell allow-list in Phase 1.
The [browser](/docs/computer/browser) is different: its private/loopback/metadata block is enforced by us, on every action, and does hold.
## Exposing a port
**Not available.** There is no port-preview surface today: `POST /v1/computers/{id}/expose` is
unrouted and answers `404 not_found` (`no route for POST /v1/computers/{id}/expose`), and neither
`vetta computer expose` nor `vetta computer unexpose` is a command. A sandbox reaches out; nothing
reaches in. This section returns when the route does.
## Egress pinning (coming soon)
**Coming soon.** All sandbox HTTPS egress will be **pinned through Vetta's egress proxy**, so the [vault](/docs/identity/vault) can **substitute secrets at the network boundary**. The sandbox, the model, the transcript, and your logs only ever see opaque placeholders; the real value is swapped in at egress, outside the sandbox. Today, vault injection is live on the [MCP connector](/docs/capabilities/tools#mcp-connector) path — credentials are added as headers on Vetta's side of the connection, never entering the sandbox.
This closes the loop with the [shell](/docs/computer/shell#fields)'s per-call `env`: rather than injecting real secrets into the sandbox environment, egress pinning lets an agent reference a credential by placeholder and have it resolved on the way out. See the [vault](/docs/identity/vault) for the injection model.
Concurrency caps, max runtime, and the full metering model.