Private Networks: Now in Testing

March 25, 2026 enterprisenetworkssecurity

Private networks have been the most requested enterprise feature since Pilot Protocol launched. Today, they are live on our production registry and entering the testing phase. This post covers what works now, what is coming next, and an honest look at the architectural constraints we are working through.

What Shipped

The registry now supports the full network lifecycle. An admin with a token can create isolated networks, add and remove members, list network membership, and delete networks entirely. These operations are gated by a cryptographic admin token — no token, no mutation.

Here is what a session looks like from the admin CLI:

# Create a private network
pilot-admin -registry host:9000 -token $TOKEN create-network \
  -name research-lab -join-rule token -token join-secret -node 685

# Add a second agent
pilot-admin -registry host:9000 -token $TOKEN add-node \
  -network 1 -node 686 -token join-secret

# List members
pilot-admin -registry host:9000 list-members -network 1
NODE ID  ADDRESS           HOSTNAME  REAL ADDR
685      1:0001.0000.02AD            34.71.57.205:4000
686      1:0001.0000.02AE            35.209.71.94:4000

# Remove a node
pilot-admin -registry host:9000 -token $TOKEN remove-node \
  -network 1 -node 686

# Delete the network entirely
pilot-admin -registry host:9000 -token $TOKEN delete-network \
  -network 1

All operations persist to disk immediately. Deleting a network cleans up member references — no orphaned state.

Three Join Rules

Networks support three access control models:

Open — any registered node can join. Good for dev/test environments.
Token — joining requires a shared secret. The token is set at network creation time. Suitable for team-level isolation where you can distribute a token out of band.
Invite — an existing member must vouch for the new node. The strongest access control: membership spreads only through the trust graph.

What "Private Network" Actually Means

When two nodes share a non-backbone network, the system treats them as implicitly trusted. This has three concrete effects:

Auto-trust at resolve time. A private node that would normally be invisible becomes resolvable to any node in the same network. No handshake ceremony required.
SYN acceptance. Incoming connections from same-network peers bypass the trust gate. The daemon checks shared network membership and allows the connection.
Scoped listing. list-members returns only nodes in that network. No backbone enumeration. An attacker with no network membership sees nothing.

The result: agents inside a private network can discover and connect to each other. Agents outside it cannot see that the network or its members exist.

The Backbone Constraint

Here is the honest part. Today, every node is automatically enrolled in the backbone (network 0) at registration time, and nodes cannot leave backbone. This is an architectural constraint, not a policy choice.

The backbone provides three things that private networks currently depend on:

Address allocation. A node’s 32-bit node ID is assigned at registration, and the backbone address (0:0000.XXXX.XXXX) is the canonical identifier used for tunnel setup, lookup, and routing.
Tunnel establishment. When node A wants to reach node B, the tunnel layer resolves B’s endpoint via the backbone registry. NAT traversal, hole punching, and relay all operate on backbone-level identities.
Global reachability. Even within a private network, the actual UDP tunnel is established using backbone addressing. The private network provides authorization (who can connect), but the backbone provides connectivity (how to reach them).

This means a node cannot exist only on a private network today. It always has a backbone presence. For many use cases this is fine — the node is private-by-default and invisible to anyone without trust or shared network membership. But for use cases where you want zero backbone footprint (a node that the registry itself only associates with a specific network), that requires deeper architectural work.

What Is Coming

Private networks are the foundation. Here is what we are building on top of them:

Network-Scoped Registration (Phase 2)

Agents specify a target network at startup. The daemon auto-joins configured networks after registration, so deploying a fleet to a private network is a single config change — no manual add-node commands.

Backbone-Optional Nodes (Phase 3)

The long-term goal is supporting nodes that exist exclusively within a private network, with no backbone presence. This requires changes to address allocation (network-scoped IDs), tunnel setup (resolve within network context), and the registration flow. It is architecturally tractable but not trivial.

Self-Service Network Creation

Today, network creation requires the admin token. We are designing a self-service interface where authenticated nodes can create and manage their own networks, subject to quotas and policy. The admin token path remains for infrastructure operators; the self-service path is for application-level teams.

Policy Engine (Phase 3)

Tag-based access policies that control which nodes can reach which ports: “nodes tagged frontend can reach nodes tagged api on ports 80 and 443.” Policies evaluated at both resolve time and SYN time. Combined with private networks, this gives you full microsegmentation without a service mesh.

Current Status

Private networks are live on the production registry as of March 2026. The admin CLI runs on the registry host. We are testing network lifecycle operations under load and validating that trust semantics (auto-trust, SYN gating, resolve privacy) work correctly across all NAT configurations.

If you are interested in trying private networks for your agent deployment, create an account on the Pilot Console and set up your first network in minutes.