# What is an egress proxy?

An egress proxy is a server that every outbound connection from a machine must pass through, where rules are applied and traffic is logged.

**On Runtime the egress proxy runs on the host, outside each microVM, and a
sandbox has no network card to bypass it with.** Programs that honour
`HTTP_PROXY` and programs that open raw sockets meet the same rules, root
included ([security](/docs/security#network-access)). The same proxy is what
lets a sandbox use an API key it never holds.

## Why it matters for AI agents

Rules that live inside the machine can be undone by whatever runs there. An
agent with `sudo` can rewrite `iptables`, unset a proxy variable, or start a
program that ignores it. A proxy placed outside the machine is out of reach:
the only way out is through it, so its allow list, its limits and its log are
the truth about what left.

A proxy that terminates HTTPS for chosen hosts can also add a credential to a
request on its way out. The code inside sends a placeholder and the real value
is attached beyond the sandbox's reach.

## Where the proxy sits on Runtime

| Question                            | On Runtime                                                                                                      |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Where it runs                       | On the host, outside the Firecracker microVM                                                                    |
| How traffic reaches it              | The sandbox has no network card; TCP leaves it, plus QUIC and NTP on paid sandboxes, and DNS is answered inside |
| Programs that ignore proxy settings | Their TCP connections go to the same proxy on their own                                                         |
| Docker containers in the sandbox    | Get `HTTP_PROXY` and `HTTPS_PROXY` set to `http://172.17.0.1:10800`                                             |
| What it enforces                    | Per-sandbox allow, deny and connect rules; private addresses always refused                                     |
| Limits                              | Concurrent connections, bandwidth and bytes per day, per sandbox                                                |
| Runtime's relays in the sandbox     | Ports 10800, 10802 and 10853, never reachable from outside                                                      |

Rule changes apply at once, to connections already open too
([the network](/docs/sandbox-environment#the-network)).

## Attach a key on the way out

Store the key once with the hosts it may go to. With `header`, the proxy sets
that header on every HTTPS request to those hosts, so code needs no placeholder
at all:

```ts check
import { Runtime } from "withruntime";

const runtime = new Runtime();
await runtime.secrets.set("GITHUB_TOKEN", {
  value: process.env.GITHUB_TOKEN ?? "",
  hosts: ["api.github.com"],
  header: "Authorization",
  format: "token {value}",
});
```

```bash no-run
printf %s "$OPENAI_API_KEY" | runtime secrets set OPENAI_API_KEY --host api.openai.com
```

To do this the proxy opens the HTTPS connection to those hosts itself and
checks the real server's certificate. Sandboxes already trust Runtime's
certificate for them through `SSL_CERT_FILE`, `REQUESTS_CA_BUNDLE` and
`NODE_EXTRA_CA_CERTS`. Plain HTTP never carries a secret, and request bodies
are never rewritten ([secrets](/docs/security#secrets-sandboxes-never-see)).

## Related

- [What is egress control?](/glossary/egress-control)
- [What is prompt injection?](/glossary/prompt-injection)
- [How to turn off a sandbox's internet](/how-to/turn-off-sandbox-internet)
- [Run Docker in a sandbox](/how-to/run-docker-in-a-sandbox)

Facts on this page were checked on 25 September 2026.