Enterprise Private Networks: The Roadmap

Enterprise Private Networks: The Roadmap

A question came up recently that cut through the usual "cool project" feedback and hit the actual enterprise bar:

"Solves connectivity" is only part of the enterprise problem. The harder bar is: does the connectivity layer also align with workload identity, policy, revocation, audit, and dark-by-default reachability, instead of just making peer connectivity easier? How would Pilot interoperate with existing identity models rather than becoming a parallel trust island?

This is the gap between a networking project and enterprise-grade infrastructure. Here is how we are closing it.

What We Already Have

Pilot Protocol is not starting from zero on enterprise requirements. The current implementation includes:

This is a solid foundation. But it is not enough.

The Gaps That Matter

We conducted a thorough audit across six enterprise dimensions. Three findings stand out:

Critical: The SYN Handler Trust Gap

The resolve layer enforces dark-by-default at the control plane—you cannot discover a private node's endpoint without trust or shared network membership. But the daemon's SYN handler accepts connections from any source that knows the endpoint. If an attacker obtains an endpoint by any means (sniffing, leaked config, prior trust that was revoked), they can connect without authorization.

This is the most critical security gap. Phase 1 fixes it with a trust gate at SYN time: incoming connections from untrusted sources (no trust pair, no shared network) are rejected with RST.

High: Parallel Trust Island

Every Pilot deployment today is a self-contained identity system. Nodes prove they hold an Ed25519 private key, but cannot prove they are authorized by an enterprise identity provider. There is no OIDC token validation, no SPIFFE SVID acceptance, no trust domain federation. Enterprises will not deploy a second identity system.

High: Revocation Does Not Cascade

Revoking trust is purely bilateral. When a node is compromised, each individual peer must manually untrust it. There is no admin-initiated mass revocation. There is no block list. This is inadequate for deployments with more than a handful of nodes.

The Roadmap: Five Phases

Each phase is independently shippable and valuable. You do not need to wait for Phase 5 to benefit from Phase 1.

Phase 1: Activate & Harden

Enable the existing WIP network primitives (create, join, leave networks via CLI). Fix the critical SYN trust gap by adding trust verification to the daemon's connection handler. Fix the hostname resolve information leak. This phase delivers token-gated and invite-gated networks, same-network auto-trust, and SYN-level dark-by-default enforcement.

Phase 2: Auto-Join & Audit

Agents auto-join configured networks at startup—deploy an entire swarm with the same config file. The registry gains structured audit events (network created, node registered, trust revoked) in machine-parseable JSON for SIEM integration. Webhook delivery becomes reliable with retry logic and monotonic event IDs for gap detection.

Phase 3: Organization + Policy + Cascading Revocation

The enterprise fleet management phase. Organizations group networks and members under a single admin. Tag-based access policies control who can reach whom on which ports: "nodes tagged frontend can reach nodes tagged api on ports 80 and 443." Policies are evaluated at both resolve time and SYN time. Admin revocation cascades instantly—org revoke removes a node from all networks, revokes all trust pairs, and pushes revocation to every online peer.

Phase 4: CA-Based Enrollment

Replace shared tokens with cryptographic proof. Networks can require a CA-signed certificate to join. Certificate signing happens offline—the CA never touches the network. Per-network revocation lists. Identity expiry forces key rotation.

Phase 5: External Identity (OIDC + SPIFFE)

The phase that ends the parallel trust island. Networks can require a valid OIDC JWT from a configured issuer (Google, Azure, Okta, GitHub). Or a valid SPIFFE JWT-SVID from a configured trust domain. The daemon can optionally integrate with the local SPIFFE Workload API to auto-fetch SVIDs. Audit logs link Pilot's 48-bit addresses to enterprise identities. No shared secrets to distribute. Enterprises adopt Pilot without deploying a second identity system.

Standards Alignment

We mapped the roadmap against three emerging standards for agent security:

Where This Sits

A2A defines what agents say to each other. MCP defines what tools agents can use. Pilot defines how agents reach each other.

After all five phases, that becomes: how agents reach each other within the organization's existing trust boundaries. Not in a parallel island. Not with a second set of credentials. With the OIDC tokens and SPIFFE SVIDs they already have.

The full technical assessment—including gap analysis tables, standards alignment matrix, and competitive positioning—is available in the Enterprise Readiness Report (PDF).

Enterprise Readiness Report

Full audit of Pilot Protocol against six enterprise dimensions: workload identity, policy, revocation, audit, dark-by-default reachability, and interoperability with existing identity models.

View on GitHub  ·  Wire Specification