Workload networking
Deployed workloads—agents, functions, serverless container services, and MCP servers—operate inside isolated, multi-tenant private project networks.
Network isolation architecture
All workload containers inherit strict default network policies governing inbound traffic and outbound connectivity.
Outbound network rules
Outbound connections initiated by workload code are filtered at the network edge:
| Destination / Range | Rule | Description |
|---|---|---|
| Public Internet | ALLOWED | Outbound HTTP/HTTPS to public domains and public IP addresses. |
| Platform Services | ALLOWED | Pub/Sub, VectorDB, the secrets API and the Secret Store, inference, and the tool-sandbox service — each admitted individually, one service and one port at a time, never as a whole address range. |
| Same-project MCP servers | ALLOWED | TCP 8080, direct to MCP servers running in your own project. |
| The project's MemoryStore | ALLOWED | TCP 6379, direct to the MemoryStore in your own project. |
| Any other workload in the project | BLOCKED on its private internal address | Reach it through its published API Gateway endpoint instead — see below. |
172.27.255.0/24 on TCP 443 | ALLOWED | Crusoe Cloud object storage, which does not sit on a public address. Overridable per deployment with CAI_OBJECT_STORE_CIDR. |
10.0.0.0/8 | BLOCKED | Private network range (RFC 1918). The platform's own internal addresses — workloads and platform services alike — live here. |
172.16.0.0/12 | BLOCKED | Private network range (RFC 1918), apart from the object-storage range above. |
192.168.0.0/16 | BLOCKED | Private network range (RFC 1918). |
169.254.0.0/16 | BLOCKED | Link-local, including the cloud provider instance metadata endpoint at 169.254.169.254. |
Calling another workload in your project
Only two same-project peers are dialable directly, workload to workload: MCP servers on 8080 and MemoryStore on 6379. Everything else goes through the target's published API Gateway endpoint, which is the one path that carries authentication.
The private internal address of another agent or function does not work. That address falls inside the catch-all's except 10.0.0.0/8, and the internal router that serves those addresses is deliberately left out of the allowlist — it picks a destination from the Host header, so admitting it would let one project forge a header and reach another project's private service. The symptom of getting this wrong is a connection that hangs until it times out, with no policy error anywhere: the network policy drops packets silently.
Subtracting the private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local (169.254.0.0/16) from the public-internet rule prevents Server-Side Request Forgery, so model-generated code or tool calls cannot probe internal infrastructure or extract cloud metadata credentials. The subtraction is kept deliberately broad; the object-storage range is added back as its own rule on 443 only, rather than by narrowing 172.16.0.0/12.
On a deployment missing that add-back rule, object storage fails in a confusing way: DNS resolves fine, and then the client — or an object-store trigger's poller — times out.
Inbound network rules
Workloads accept inbound connections only from:
- API Gateway Edge: Inbound traffic arriving through published API Gateway endpoints.
- Same-Project Workloads: internal addresses of the form
http://<service>.<project-internal-name>:8080— the service name, a dot, then the project's internal name, which is shown on the Projects page.
Workloads in separate projects cannot establish direct network connections.
Being reachable is not the same as being allowed to dial out. A workload accepting traffic at that address does not mean another workload in the project may open the connection: outbound, only MCP servers (8080) and MemoryStore (6379) are directly dialable. See the outbound rules above.
Where tool code actually runs
An agent's own network policy is not the policy its tools run under. With TOOL_SANDBOX on — the default — each tool body executes in a single-use sandbox outside your project, built from the agent's image but with the agent's environment stripped: no model key, no MemoryStore address, no VectorDB URL, no credentials.
That sandbox's network policy allows DNS plus the public internet, with 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 excepted. So a tool can call a public API, and it can reach no platform service, no MemoryStore, no VectorDB, no MCP server and no other workload. (An install can turn this off with the toolCalls.allowInternetEgress setting, in which case tool sandboxes fall back to DNS-only as well.)
Model-generated code — anything run through /v1/execute rather than a user tool function — is stricter still: DNS only, nothing else.
Anything that must reach a real service belongs in an MCP server, which has its own credentials and its own network. The platform injects MCP_SERVERS into the agent, and the agent reaches the server over MCP.
Connecting to external databases and services
To connect a workload to an external service:
- Public Endpoint Integration: Ensure external database or API endpoints are exposed on public hostnames protected by TLS and strong authentication.
- Secrets Injection: Store database credentials, tokens, or connection strings in Secrets Manager and bind them to workload environment variables.
- Internal Platform Storage: Use managed platform storage services (MemoryStore or VectorDB) for zero-latency, fully managed data storage.