Trust Model: Agents Are 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 a more private position: connectivity should be gated by default. A new agent may have directory metadata in the registry, but its reachable endpoint is withheld from arbitrary peers. Connectivity is granted through a cryptographic trust handshake or an applicable shared-network policy.

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 or metadata. Public agents opt into broad search; private-agent metadata may still appear according to registry and network configuration. A lookup result does not grant a reachable endpoint or permission to connect.

# Results depend on visibility, registry, and network policy
$ pilotctl find alice
alice  0:0000.0000.0003  private  endpoint-withheld

# 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. The rendezvous server returns that endpoint only when a mutual trust relationship or shared-network membership authorizes connectivity.

An agent's virtual address is a durable identifier, not a physical network location. Knowing it is useful for identity and routing, but it does not by itself authorize endpoint resolution.

Enumeration

Endpoint enumeration is separated from directory discovery. Search and registry responses may expose agent metadata, while reachable endpoints remain governed by peer trust and network membership.

This limits connection scope for a compromised agent to the peers and networks its current policy allows. Directory metadata should still be treated as discoverable control-plane information.

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 when the daemon first starts. 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 binding the two identities (handshake:<node_id>:<peer_id>), 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 a plaintext statement of intent carried alongside the request. When Agent B reviews pending handshake requests, they can see exactly why each agent wants to connect. Note: the Ed25519 signature covers the identity pair, not the justification text -- so treat the justification as a human-readable label, not a cryptographically signed claim. (Signing the justification is on the roadmap.)

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 every incoming request via the daemon's -trust-auto-approve flag (open-door mode for trusted environments)
• 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 not notified — it will see connection failures on its next attempt

When an agent runs pilotctl untrust, two things happen locally:

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.

Revocation is a purely local action: the revoked peer is not notified. It simply sees its connections fail on the next attempt and must re-handshake if trust is ever re-established.

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 or shared credentials are required. Reachable endpoints are disclosed only where peer trust or network policy allows connectivity.

Regulatory Compliance

Regulated deployments typically need access control, audit evidence, and data-flow boundaries. Pilot's trust model contributes technical controls in those areas, while compliance remains a property of the complete deployment and operating program:

• Access control -- peer trust or shared-network policy determines which agents can communicate. Peer trust relationships are cryptographically verifiable.
• Audit trail -- every handshake includes a justification message. Who requested access, why, and when is all recorded.
• Data boundaries -- trust and network membership limit connectivity. Operators still need application authorization, data classification, and review of directory metadata.
• 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 establish connections only where its peer trust and network memberships permit. It may still see directory metadata, so containment depends on keeping those grants narrow and revoking them promptly.

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: authorized connectivity requires context. Two agents that have never communicated need a peer handshake, shared-network membership, or an operator-defined introduction before they can connect.

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, while the communication channel is authenticated, encrypted, and gated by peer trust or network policy. For a complete walkthrough of how agents discover each other through the registry and tag search, see How AI Agents Discover Each Other on a Live Network.

Agents can also use the --public flag to opt into broader discoverability for specific use cases. A data-processing agent may advertise itself publicly, while a financial analysis agent remains private and joins only governed networks. Visibility and network policy are separate controls.

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.