Source: Dev.to

Zero‑Trust for Agents

The phrase “zero trust” gets applied to a lot of things that aren’t really zero‑trust.
In most agent infrastructure today, “secure” means “behind a VPN” or “talking over TLS.” That’s transport security – it’s not the same thing.

Zero trust for agents means something more specific:

• Mutual authentication before any data is exchanged.
• Every agent has a cryptographic identity that persists across restarts and cloud migrations.
• Private routing is the default, not an opt‑in you configure after the fact.

Most agent frameworks skip this entirely. They assume agents live inside trusted perimeters and communicate over HTTPS. That assumption breaks fast in production.

TLS vs. True Agent Identity

• TLS secures the channel between two endpoints, but it does not authenticate the agents themselves.
• A compromised proxy, a man‑in‑the‑middle inside a VPC, or a mis‑configured gateway can sit between two agents without either side knowing. The encrypted tunnel exists, but you have no guarantee about what’s at the other end.

Agent‑to‑agent communication needs something closer to what SSH does for machines, or mTLS does for micro‑services: mutual authentication where both sides present identity before the connection is established.

The harder part is that agent identity can’t be tied to an IP address. Agents move, restart, and migrate between cloud regions. An IP‑based identity breaks the moment you scale or redeploy.

Pilot Protocol – Network‑Layer Zero Trust

Pilot Protocol handles identity and routing at the network layer:

1. Virtual address – each agent gets a 48‑bit virtual address derived from a public key, not from a machine IP.
2. Key exchange – when two agents connect, they run an X25519 key exchange and authenticate with Ed25519 identity keys.
3. Pre‑exchange authentication – both sides know who they’re talking to before any application data is exchanged.

Addressing format

0:A91F.0000.7C2E

• A structured virtual address that the agent transport layer resolves via a distributed registry – no DNS required.
• Two agents on opposite sides of the world, with different ISPs, can establish a direct encrypted tunnel without either side knowing or caring about the other’s physical IP.

NAT Traversal

Most agents run behind NAT, which means they can’t accept inbound connections without a relay or port‑forwarding configuration.

• RFC 5389 (STUN) established the standard approach for real‑time communications. Pilot applies the same technique at the agent layer.
• The network layer below MCP and A2A uses STUN‑based hole punching to let two agents behind separate NATs establish a direct peer‑to‑peer tunnel without a central server in the data path.
• For symmetric NATs where hole punching fails, there’s an encrypted relay fallback – the relay only sees ciphertext (AES‑256‑GCM), never plaintext.

This is meaningfully different from most “agent networking” solutions, which route all traffic through a cloud service that has full visibility into what’s being exchanged.

Three Concrete Things That Break Without This Model

1. Impersonation – An agent calling itself billing-agent-prod must be able to prove it’s the deployed billing agent, not something that merely registered the same name. Without cryptographic identity, names are unverifiable.
2. Replay attacks – Even if you verify identity, a captured valid request can be replayed later. Per‑tunnel session keys tied to the key exchange mean captured traffic can’t be replayed against a different session. This mirrors the nonce‑management problem formally addressed in TLS 1.3; Pilot applies equivalent protections at the session layer.
3. Trust inheritance – In a multi‑agent pipeline, an agent hands off a task to another, which calls a third. If the first agent is compromised, does the compromise propagate? With mutual authentication at every hop, each agent independently verifies who it’s talking to. There’s no inherited trust.

Architectural Placement

Pilot Protocol sits at layer 5 (Session Layer) of the OSI model, below your application layer and below MCP or A2A.

• Authentication and encryption happen before your application code runs, for every connection, without you writing any auth logic.

The Pilot IETF Internet‑Draft formalizes the addressing scheme and cryptographic handshake in standards‑track format – modeled after RFC 7364, the NVO3 problem statement that led to VXLAN and GENEVE. Worth reading if you’re designing agent infrastructure from scratch and want to understand why the session layer is the right place to solve this rather than the application layer.

The WireGuard protocol paper is also instructive on why cryptographic identity at the network layer beats application‑layer auth bolted on after the fact. Pilot applies similar thinking to the agent context, with the addition of a bilateral trust model that neither WireGuard nor libp2p was designed for.

What an Agent Gains by Installing Pilot

• A permanent cryptographic identity that survives any infrastructure change.
• Mutual authentication on every inbound and outbound connection automatically.
• Private‑by‑default routing with no open endpoints.
• NAT traversal without a central proxy.
• Compatibility with existing agent frameworks while providing true zero‑trust at the network layer.

lity with whatever you're running on top - MCP, A2A, HTTP, raw TCP. It's below all of that.  
The security model isn't something you configure. It's the default behavior of the transport.

```sh
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl daemon start --hostname my-agent

• Address: 0:A91F.0000.7C2E
• Mutual auth: enabled
• Private routing: on

Zero trust for agents doesn’t require a new security vendor or a policy engine.
It requires a transport layer that builds authentication into the addressing scheme from the start.

  curl -fsSL https://pilotprotocol.network/plain
  curl -fsSL https://pilotprotocol.network/install.sh | sh