Egress allowlist
Default-deny outbound — the engine can only reach domains you permit.
By default, a project's engine can reach nothing on the network. You grant access one domain at a time. This bounds the blast radius of any connector or Root Function: even a malicious or buggy one can't exfiltrate to an arbitrary host.
Policy in the cloud, enforcement in the engine
The split is deliberate:
- The cloud owns the policy. You manage the allowlist in the Console
(
/v1/projects/{id}/egress); it's stored per project and injected into the engine asTR_OUTBOUND_ALLOWLISTat spawn. - The engine enforces it. The gateway only sees inbound client→engine traffic — it never sees the engine's outbound calls, so it can't enforce there. The engine checks every outbound request against the allowlist itself.
Semantics
TR_OUTBOUND_ALLOWLIST | Behaviour |
|---|---|
| Set (one or more domains) | Default-deny. Only listed domains (and their subdomains) are reachable. |
| Unset | Allow-all. Used for local/desktop dev parity. |
Enforcement points include the Root Function fetch
(refused before any request to a non-allowlisted host) and the external MCP
server install path (an HTTP MCP server whose host isn't allowlisted won't
mount).
egress blocked: host 'evil.example' is not in this project's TR_OUTBOUND_ALLOWLISTConnectors manage egress for you
When you install a function connector (e.g. Resend), the Console automatically
adds the domain it needs (api.resend.com) to the allowlist — so the common
path is handled, and you only touch egress directly for custom integrations.