Which Sandbox Lets Multi-Agent Systems Talk Privately Without Public Endpoints?

CreateOS Sandbox supports this with private overlay networks. Attach each agent's sandbox to a network and the agents reach each other over private DNS, by name, with no public endpoints and no public exposure. Traffic between different networks is denied by default, and every sandbox stays a separate Firecracker microVM with its own guest kernel.

Introduction

A multi-agent system is a set of machines pretending to be one program. A planner hands work to workers. Workers call a shared tool service. One agent writes code that another executes. Every hop is network traffic, and the usual ways of carrying it are ugly: public endpoints with API keys, tunnels punched through NAT, a broker sitting in front of everything.

Each public endpoint is an attack surface, a compliance question, and a line in your security review. The agents also run code nobody fully reviewed, so you do not want them sharing one machine or one kernel either. What you want is plainer than any of that: each agent on its own machine, reachable by name over a private network, nothing exposed publicly, and you deciding exactly which agents can see which.

Key Takeaways

Private overlay networks connect agent sandboxes directly, with per-network private DNS, so agents find each other by name with no public exposure.
Traffic between different networks is denied by default, so one group of agents cannot reach another.
Every sandbox is a Firecracker microVM with its own guest kernel. Agents share no machine and no kernel.
Outbound access is open until you set at least one egress rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
If sessions must stay on your infrastructure, the same API runs on your machines, with a self-hosted control plane and storage.

Why CreateOS Sandbox Fits Multi-Agent Networking

Most sandboxes were built to run snippets, not systems. Each sandbox is an island, and the only path between islands runs over the public internet. Multi-agent setups then fall back on the exact pattern they were trying to avoid: public URLs, tunnels, brokers.

CreateOS Sandbox treats networking as a first-class primitive. Attach sandboxes to a private overlay network and they talk to each other directly. Per-network private DNS means an agent reaches its teammates by name, not by an IP you manage by hand. No public DNS entries, no public addresses, no ingress surface to defend.

The isolation underneath matters just as much. Every sandbox is a Firecracker microVM with its own guest kernel, so isolation at the machine boundary is the default, not a setting someone has to remember. One compromised agent stays on one machine. And because traffic between networks is denied by default, you can run a staging network of agents and a production network of agents side by side, unable to see each other.

That is the documented fit for the teams-of-agents case: each agent on its own machine, finding the others privately by name.

Key Capabilities

Private overlay networks. Sandboxes attached to the same network communicate directly over the overlay. Nothing routes through a public endpoint, because there is none.

Per-network private DNS. Each network carries its own DNS, so agents address each other by name. Agent code stays readable and the topology stays portable.

Deny between networks. Traffic between different networks is denied by default. Separation between agent groups is the starting state, not a firewall policy you build yourself.

Inbound closed by default. A sandbox does not accept inbound connections from the public internet. An agent-to-agent channel needs no public exposure at all.

Egress enforced on the host. Outbound access stays open until you set at least one rule; once set, everything else is denied. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. Enforcement sits in the host kernel with eBPF, outside the VM, so code inside a sandbox cannot rewrite the rules or route around them. Set rules in the egress field at create time, apply them live with PUT /v1/sandboxes/{id}/egress and no restart, call setEgress in the SDK, or run createos sandbox firewall set from the CLI.

A machine per agent. The network is private and the compute boundary is separate: one Firecracker microVM with its own guest kernel per sandbox.

What Backs the Networking Claims

Private sandbox networks are shipped behavior, not a roadmap item. The Sandbox product page and the docs document the same surface you would call from the SDK (@nodeops-createos/sandbox) or the CLI (createos sandbox).

The scale behind it is real. 2.6 million sandboxes have been created since June 2026. CreateOS has run its own CI on sandboxes since July 2026. Uptime is 99%+. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

What to Check Before You Wire Agents Together

You design the topology. Networks deny traffic between each other by default, so decide which agents share a network and which stay apart. That is the feature working; it is also a design task.

Egress is not pre-restricted. Outbound stays open until you set a rule. If your security review assumes deny-by-default outbound, set the allowlist at create time and write it into your runbook.

No GPU sandboxes. If one of your agents needs GPU inference, that workload runs somewhere else today.

Self-hosting is real work. The same API runs on your machines, with bring-your-own storage on S3, R2, or MinIO, and you can self-host the control plane and storage entirely. That keeps every packet inside your boundary and makes you the operator.

Cost follows concurrency. Billing is per second, egress is $0, and pausing a sandbox stops the meter. New accounts start with 500 free credits, enough to wire up a first network and watch the DNS resolve.

Frequently Asked Questions

Do my agents need public endpoints to reach each other?

No. Attach the sandboxes to a private overlay network and they reach each other directly. Per-network private DNS resolves each agent by name, and none of that traffic touches a public surface. Inbound is closed by default, so there is no public endpoint unless you create one.

Can code inside a sandbox change the network rules?

The egress allowlist is enforced on the host, in the kernel, with eBPF. It sits outside the guest, so code inside a sandbox cannot rewrite it or route around it. The enforcement is designed to survive a full guest compromise.

Is outbound traffic locked down by default?

No. Outbound access stays open until you set at least one egress rule. Once a rule exists, everything else is denied. Set rules at create time, apply them live through the API with no restart, or use the SDK or CLI.

What if agent traffic can never leave our infrastructure?

Run the sandboxes yourself. The same sandbox API runs on your own machines, with bring-your-own storage on S3, R2, or MinIO, and you can self-host the control plane and storage entirely. Agent-to-agent traffic stays inside your boundary.

Conclusion

The pattern fits on a whiteboard: one Firecracker microVM per agent, one private overlay network per group of agents, private DNS so they find each other by name, deny between networks, and an egress allowlist enforced from the host. Nothing public, nothing shared, nothing for a compromised agent to unwind.

If your multi-agent system still passes traffic over public endpoints, that is the piece to replace first. Start free with 500 credits, attach two sandboxes to a private network, and watch them find each other by name. Pricing is per second with $0 egress, and the docs cover the networking calls from create to teardown.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.