The Pilot Protocol Trust Model: Why Agents Should Be Invisible by Default

When Google released the A2A (Agent-to-Agent) protocol, they introduced a concept called Agent Cards. An Agent Card is a JSON document published at a well-known URL (/.well-known/agent.json) that advertises an agent's capabilities, supported protocols, and endpoint. Any agent that knows the URL can fetch the card and start a conversation.

This is the default in agent frameworks: agents are discoverable. They announce themselves. They welcome connections. The assumption is that open communication is the norm and access control is layered on top.

Pilot Protocol takes the opposite position: agents should be invisible by default. A new agent on the network cannot be found, cannot be connected to, and cannot be enumerated. Visibility is not the default state -- it is a privilege granted explicitly through a cryptographic handshake.

This post explains why, how the trust model works technically, what it enables, and what it costs.

The A2A Default: Open by Design

A2A Agent Cards are designed for open ecosystems. The specification envisions agents publishing their capabilities publicly, like web services publishing API documentation. A client agent discovers a server agent by fetching its Agent Card, learning what tasks it supports, and sending task requests over HTTP.

This model works well for certain scenarios:

• Public services -- an agent that provides weather data or document translation has no reason to hide
• Internal platforms -- within a company's network, where network-level security provides a trust boundary
• Marketplace agents -- agents that compete for tasks and want maximum visibility

But most production agent deployments are not public services. They are private agents operating on sensitive data, executing privileged operations, and communicating across organizational boundaries. For these agents, being discoverable is a liability, not a feature.

Consider what an open-by-default model exposes:

• Capability enumeration -- an attacker can discover exactly what an agent does by reading its Agent Card
• Endpoint exposure -- the agent's URL is public, making it a target for denial-of-service, injection, and prompt manipulation attacks
• Network mapping -- by crawling Agent Cards, an attacker can map the entire agent topology of an organization
• Version fingerprinting -- Agent Cards include protocol versions and capabilities, enabling targeted exploits

These are not theoretical concerns. In the human web, the equivalent problem -- exposed API endpoints with inadequate access control -- is consistently among the OWASP Top 10 vulnerabilities. The agent web is making the same mistakes, faster.

Private by Default: How It Works

In Pilot Protocol, every new agent is registered as private. This is not a flag the agent has to remember to set -- it is the default state. The agent must explicitly opt into visibility with the --public flag.

The privacy model operates at three levels:

Lookup

Lookup is the operation of finding an agent by hostname. When you run pilotctl find alice, the rendezvous server checks whether "alice" is registered as public. If she is private, the server returns nothing -- not an error, not a "permission denied," just no result. The requesting agent cannot distinguish between a private agent and a nonexistent one.

# Alice is private — lookup returns nothing
$ pilotctl find alice
No agents found matching "alice"

# Alice is public — lookup succeeds
$ pilotctl find alice
alice  0:0000.0000.0003  public  203.0.113.42:4000

Resolve

Resolve is the operation of getting an agent's network endpoint (IP:port) so you can establish a tunnel. This is the critical operation -- without the endpoint, you cannot connect. Resolve requires a mutual trust relationship. The rendezvous server will only return an agent's endpoint to a peer that the agent has explicitly trusted.

Even if you know an agent's virtual address, you cannot resolve its endpoint without trust. The address alone is useless -- it is a virtual identifier, not a network location.

Enumeration

Backbone enumeration -- listing all agents on the network -- is blocked entirely. There is no command and no API to retrieve a list of all registered agents. An agent can only see agents it has already discovered through lookup (public agents) or through an established trust relationship.

This means an attacker who compromises one agent cannot use it to map the rest of the network. The compromised agent only knows about the peers it was explicitly trusted with.

The Handshake: Cryptographic Trust Establishment

Trust in Pilot Protocol is established through a mutual handshake ceremony. This is not an HTTP OAuth flow or a certificate signing request. It is a peer-to-peer cryptographic protocol built on Ed25519 digital signatures.

Step 1: Identity

Every agent generates an Ed25519 key pair during initialization (pilotctl init). The private key stays on the agent's machine in ~/.pilot/identity.json. The public key is registered with the rendezvous server alongside the agent's virtual address and hostname.

Ed25519 was chosen for several reasons:

• Deterministic signatures -- no random nonce that could leak the private key if the RNG is weak
• Fast verification -- the rendezvous server and peers can verify signatures with minimal CPU overhead
• Small keys -- 32-byte public keys, 64-byte signatures. They fit in packet headers without overhead
• Standard library support -- Go's crypto/ed25519 package, no external dependencies

Step 2: Handshake Request

Agent A initiates a handshake to Agent B. The request includes:

• Agent A's virtual address and public key
• A justification message explaining why A wants to connect
• An Ed25519 signature over the entire request, proving A controls the claimed identity

$ pilotctl handshake bob "Need access to Q1 analytics data for the board report"
Handshake request sent to bob (0:0000.0000.0004)
Waiting for approval...

The justification field is not just a comment -- it is a signed, auditable statement of intent. When Agent B reviews pending handshake requests, they can see exactly why each agent wants to connect, verified by the requester's cryptographic signature.

Step 3: Relay via Registry

The handshake request is relayed through the rendezvous server. This is necessary because Agent B might be private -- Agent A does not know B's endpoint and cannot send a direct UDP packet. The rendezvous server acts as a mailbox, holding the request until B retrieves it.

This relay mechanism means handshakes work even when both agents are behind NAT and have never communicated before. The rendezvous server never sees the agents' private keys -- it only forwards signed messages.

Step 4: Approval

Agent B reviews the request and decides whether to approve. This can be manual (an operator reviews and approves via CLI) or automatic (auto-approval rules based on the justification pattern, the requester's network, or other criteria).

# Review pending handshakes
$ pilotctl pending
PENDING HANDSHAKES:
  0:0000.0000.0003 (alice) — "Need access to Q1 analytics data for the board report"

# Approve
$ pilotctl approve 0:0000.0000.0003
Trust established with alice (0:0000.0000.0003)

If approved, Agent B signs an approval response and sends it back through the rendezvous server. Both agents now store the peer's public key locally. The trust relationship is mutual -- both sides explicitly agreed.

Auto-Approval

For use cases where manual approval is impractical (large fleets, automated deployment), agents can configure auto-approval rules. For example:

• Auto-approve any agent on the same network (same 16-bit network ID)
• Auto-approve agents whose justification matches a specific pattern
• Auto-approve when both sides request a handshake simultaneously (mutual interest signal)

The mutual-request auto-approval is particularly useful: if Alice sends a handshake to Bob, and Bob has already sent a handshake to Alice, both requests are automatically approved. The mutual initiation serves as proof that both sides want the connection.

Revocation Is Instant

Trust revocation is as important as trust establishment. In many systems, revoking access is slow, incomplete, or requires waiting for token expiration. In Pilot Protocol, revocation is immediate and complete.

$ pilotctl untrust 0:0000.0000.0004
Trust revoked for bob (0:0000.0000.0004)
Active tunnel torn down
Peer notified

When an agent runs pilotctl untrust, three things happen atomically:

1. Trust pair removed -- the peer's public key is deleted from local storage. The agent will no longer accept connections from this peer.
2. Active tunnel torn down -- if there is an active encrypted tunnel to the peer, it is closed immediately. All in-flight connections are terminated.
3. Peer notified -- the revoked peer receives a notification that the trust relationship has been terminated. It can clean up its own state and stop attempting reconnection.

There is no expiration window, no token refresh delay, no cache invalidation propagation. The instant the command runs, the peer is locked out. The next packet it sends will be rejected.

Compare this to revoking an API key in a typical system: the key might be cached in multiple services, the revocation might take minutes to propagate, and there is often no way to know if all instances of the key have been invalidated. In Pilot Protocol, the trust relationship is a point-to-point cryptographic pair. Revocation is local, instant, and verifiable.

What This Enables

A private-by-default trust model is not just a security feature. It enables architectural patterns that are impossible with open-by-default models.

Cross-Company Collaboration

Two companies want their AI agents to collaborate on a joint project. With an open model, they would need to expose agents to each other's networks, configure mutual API access, and manage shared credentials. With Pilot Protocol, the workflow is:

1. Company A's agent sends a handshake to Company B's agent with a justification: "Joint analysis for Project Atlas"
2. Company B's security team reviews and approves the specific agent-to-agent relationship
3. The agents can now communicate over encrypted tunnels, but neither can discover any other agents in the other company's network
4. When the project ends, either side runs pilotctl untrust and the relationship is severed instantly

No VPN peering. No shared credentials. No exposed endpoints. The trust is scoped to exactly the agents that need it, for exactly as long as they need it.

Regulatory Compliance

Regulations like GDPR, HIPAA, and SOC 2 require organizations to demonstrate access control, audit trails, and data flow boundaries. Pilot Protocol's trust model provides these natively:

• Access control -- only mutually trusted agents can communicate. Trust relationships are cryptographically verifiable.
• Audit trail -- every handshake includes a signed justification. Who requested access, why, and when is all recorded.
• Data boundaries -- agents can only see peers they have been explicitly trusted with. There is no risk of accidental data exposure to agents in other parts of the organization.
• Instant revocation -- access can be terminated immediately, with proof that it was terminated.

Compromise Containment

When an agent is compromised in an open network, the attacker can use it to discover and connect to every other agent. The blast radius is the entire network.

In Pilot Protocol, a compromised agent can only see the peers it was trusted with. It cannot enumerate the network, discover new agents, or establish connections to agents outside its trust set. The blast radius is limited to the compromised agent's trust relationships -- typically a small subset of the total network.

If the compromise is detected, revoking trust from the compromised agent immediately severs all its connections. The attacker loses access to every peer simultaneously. There is no race condition between detection and containment.

Trade-Offs: Discovery Is Harder

The private-by-default model has an obvious cost: discovery is harder. Two agents that have never communicated cannot find each other unless at least one of them is public or an out-of-band introduction happens.

This is intentional.

In a private-by-default network, agents are introduced to each other the way humans are introduced -- through a trusted intermediary, a shared context, or an explicit request. This is slower than automatic discovery, but it is far more secure.

For ecosystems that need open discovery, the recommended pattern is a separate discovery layer:

• Publish Agent Cards (A2A style) on a separate web service
• The Agent Card includes the agent's Pilot virtual address instead of an HTTP URL
• Interested agents initiate a handshake to the discovered address
• The agent behind the address approves or rejects based on its policies

This separates the discovery mechanism from the communication mechanism. Discovery can be as open or as restricted as the use case requires. But the communication channel is always authenticated, encrypted, and trust-gated.

Agents can also use the --public flag to opt into discoverability for specific use cases. A data-processing agent that wants to accept tasks from anyone can register as public. A financial analysis agent that should only communicate with approved partners remains private. The choice is per-agent, not per-network.

Comparison: Trust Models Across Protocols

No protocol is universally better -- each makes different trade-offs. A2A optimizes for open ecosystems and interoperability. MCP optimizes for tool access patterns. Pilot Protocol optimizes for security in adversarial environments where agents handle sensitive data, cross organizational boundaries, and operate autonomously.

For detailed technical documentation on configuring trust policies, auto-approval rules, and visibility settings, see the Trust & Handshakes documentation.