From 790becaf7325ed1fa390097cf1874e291daaf59b Mon Sep 17 00:00:00 2001 From: pstayets Date: Wed, 22 Jul 2026 13:08:53 -0700 Subject: [PATCH] learn: how are network agent tokens different? Signed-off-by: pstayets --- ...w-are-network-agent-tokens-different.astro | 187 ++++++++++++++++++ 1 file changed, 187 insertions(+) create mode 100644 src/pages/learn/how-are-network-agent-tokens-different.astro diff --git a/src/pages/learn/how-are-network-agent-tokens-different.astro b/src/pages/learn/how-are-network-agent-tokens-different.astro new file mode 100644 index 0000000..cf8072c --- /dev/null +++ b/src/pages/learn/how-are-network-agent-tokens-different.astro @@ -0,0 +1,187 @@ +--- +import BlogLayout from '../../layouts/BlogLayout.astro'; + +const bodyContent = `

Every AI agent on a network needs a way to prove who it is. The standard answer for the last decade has been a token: an API key in an HTTP header, a JWT in an Authorization field, an OAuth bearer token. These work well enough for human-driven applications where a user logs in, gets a token, and calls an API. But the assumptions baked into traditional tokens break down when autonomous agents are the ones authenticating.

+ +

This post compares traditional network tokens with the approach Pilot Protocol takes for agent identity. The difference is not incremental. It is a distinct design choice with concrete implications for agent autonomy, operational complexity, and security posture.

+ +

What Traditional Tokens Do

+ +

Traditional tokens solve an identity problem by indirection. An API key is a shared secret string that a server looks up in a database to determine who the caller is. A JWT is a signed JSON object that carries claims about the caller — their user ID, role, expiration time. An OAuth token delegates authorization from an identity provider to a resource server.

+ +

All three share the same fundamental pattern: the token is issued by a central authority, stored by the client, and presented to prove identity. The server validates the token against its own records or a cryptographic signature. This works because there is always a server, and the server trusts the issuer.

+ +

But the pattern imposes constraints that matter for autonomous agents:

+ + + +

These constraints are manageable when a human operator provisions credentials and handles failures. For a fleet of autonomous agents running unattended across clouds, they become operational debt that compounds.

+ +

Agent Identity in Pilot Protocol

+ +

Pilot Protocol does not use tokens in the traditional sense. Instead, every agent generates its own Ed25519 key pair during initialization. The private key stays in ~/.pilot/identity.json and never leaves the node. The public key is registered with the network registry as the agent's identity.

+ +

When two agents establish trust, they exchange public keys and sign handshake messages with their private keys. The receiving agent verifies the signature against the registered public key. No shared secrets. No central issuer. No token to leak or expire.

+ +

This is not a minor implementation detail. It changes what identity means at the protocol level:

+ + + +

Seven Differences That Matter

+ +

The divergence between traditional tokens and Pilot's cryptographic identity shows up in tangible, operational ways. These are not theoretical distinctions — they affect how you build, deploy, and secure an agent network.

+ +

1. Self-Sovereign vs. Issued

+ +

A traditional token is granted by an authority. An agent that needs credentials must authenticate to that authority first, which requires either another credential (bootstrap problem) or human intervention. This model requires an always-available identity provider and introduces a single point of failure for the entire agent fleet.

+ +

Pilot identity is self-sovereign. The agent generates its key pair locally during pilotctl init. The registry learns the public key after generation, but the generation itself does not depend on the registry. An agent that has never contacted the network still has a valid identity. This matters for air-gapped deployments, edge devices with intermittent connectivity, and agents that must bootstrap autonomously.

+ +

2. Permanent vs. Ephemeral

+ +

Traditional tokens expire. This is by design — expiring limits the blast radius of a leaked token and forces regular re-validation of the holder's authorization. But expiration imposes lifecycle management on every agent: monitor expiry, refresh before it hits, handle the race condition where a token expires between check and use, queue requests that fail with 401, retry with the new token.

+ +

Pilot's Ed25519 identity does not expire. The key pair is valid until the operator explicitly rotates it or the node is decommissioned. An agent that has established trust with a peer can communicate indefinitely without credential maintenance. The equivalent of token refresh — re-verifying trust — is a cryptographic signature check on each connection, not a token exchange.

+ +

3. No Shared Secrets

+ +

API keys are shared secrets. The same string that authenticates the caller is stored in the server's database. A database breach exposes every API key — the attacker authenticates as any agent whose key was leaked. Industry surveys indicate that a substantial portion of organizations still use shared API keys for agent-to-agent communication, meaning a single database compromise can compromise the entire agent fleet.

+ +

Pilot uses asymmetric cryptography. The private key never leaves the agent node. The public key is registered with the network but reveals nothing that can be used to impersonate the agent. A registry breach exposes public keys, not credentials. The only way to impersonate an agent is to compromise its specific node and extract its private key — a much higher bar than a database dump.

+ +

4. Bilateral vs. Unilateral

+ +

Traditional tokens authenticate one direction. The caller presents a token to prove its identity to the server. The server authenticates itself to the caller via TLS, using a certificate issued by a public CA. These are two different mechanisms with two different trust chains.

+ +

Pilot uses a single mechanism for both directions. The handshake protocol exchanges Ed25519 signatures. Both sides verify. If trust is not mutual, no connection exists. This eliminates the asymmetry where a client authenticates to a server but trusts any server that presents a valid TLS certificate from a CA it may not even recognize.

+ +

5. Instant, Local Revocation

+ +

Revoking a traditional token is a distributed systems problem. The token may be cached by the authorization server, by the resource server, by CDN edge caches, or by the client itself. JWT revocation is particularly problematic because the whole point of JWTs is stateless verification — the resource server validates the signature without contacting the issuer. Revoking a JWT before its natural expiry requires maintaining a blocklist, which undermines the statelessness that made JWTs attractive in the first place.

+ +

Pilot revocation is local and instant. Running pilotctl untrust removes the peer from the local trust store and tears down the active encrypted tunnel. The revoked peer learns about the revocation when its next connection attempt fails — no cache propagation, no blocklist synchronization, no distributed state to manage. This is possible because trust is tracked per-peer, not per-token, and the trust store is local to each agent.

+ +

6. Stolen Token vs. Key Compromise

+ +

A stolen API key or JWT is usable from anywhere. An attacker who intercepts an HTTP request and extracts the Authorization header can replay that token from their own machine, for as long as the token is valid. The token carries no binding to the specific agent that originally presented it.

+ +

Pilot's identity is bound to the node that holds the private key. Extracting the virtual address from a network packet reveals only a 48-bit identifier — not a credential. An attacker who intercepts traffic on the wire sees encrypted payloads and an address, but cannot authenticate as that agent without the private key. The cost of compromise is higher, and the blast radius of a network-level interception is zero.

+ +

7. Identity Binds to Agent, Not Account

+ +

A traditional API key or JWT identifies an account, a project, or a user — a many-to-one mapping. Multiple agents can use the same API key because the key identifies the subscriber, not the specific agent instance. When something goes wrong, there is no way to trace an incident to the specific agent that caused it.

+ +

Pilot's address is assigned to exactly one agent. The 48-bit virtual address (displayed as N:NNNN.HHHH.LLLL) is unique per node. Every message carries source and destination addresses in the packet header. Every encrypted tunnel is scoped to a specific pair of agents. If an incident occurs, the responsible agent is identified by its address — no ambiguity, no shared credentials obscuring the trail.

+ +

What This Means in Practice

+ +

The concrete difference between traditional tokens and Pilot's agent identity shows up in everyday operational scenarios:

+ + + +

Where Traditional Tokens Still Fit

+ +

None of this means traditional tokens are obsolete. For human-facing APIs, web applications, and cloud services that authenticate users, JWTs and API keys remain the right tool. The comparison is specific to agent-to-agent identity on a network layer — not application-layer authentication.

+ +

Pilot agents can still use API keys and JWTs for the application protocols they run over the overlay. A pilotctl handshake replaces the transport-layer credential. The Tunnel carries HTTP, gRPC, or any other protocol unchanged — those protocols can use whatever authentication they need at the application layer.

+ +

Summary

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DimensionTraditional TokensPilot Protocol Identity
GenerationIssued by central authoritySelf-generated (Ed25519 key pair)
LifetimeEphemeral (minutes to months)Permanent (until rotated)
Secrecy modelSymmetric (shared secret)Asymmetric (private key never leaves node)
AuthenticationUnilateral (client→server)Bilateral (mutual handshake)
RevocationDistributed cache invalidationLocal and instant
Compromise responseRotate all keys in scopeUntrust the single peer
Identity granularityAccount or roleIndividual agent (unique address)
Token theftReusable from any locationPacket does not carry reusable credential
+ +

Frequently Asked Questions

+ +

Can Pilot agents still use API keys for application-level auth?

+

Yes. Pilot Protocol replaces the transport-layer credential — how agents prove their identity to establish a tunnel. Application protocols running over that tunnel (HTTP, gRPC, database connections) can use whatever authentication they need, including API keys and JWTs.

+ +

What happens if an agent's private key is compromised?

+

The operator rotates the key pair using pilotctl rotate-key, re-registers the new public key, and re-establishes trust with its peers. The compromised private key is replaced. Unlike a shared API key leak, the private key only authenticates that specific agent — no other agent or service is affected.

+ +

How does Pilot handle token-less authentication for public services?

+

Public service agents (like the 430+ specialist agents in the Pilot directory) use a different trust model: they are in a trusted-agent allowlist and require no handshake or token. Any agent can query them directly. This is the exception, not the default — the default is that agents are invisible and must be handshaked.

+ +

Do I need to manage certificate authorities?

+

No. Pilot Protocol uses Ed25519 signatures for identity verification. There is no certificate authority, no chain of trust to maintain, and no CA to keep online. Trust is established peer-to-peer through the handshake protocol — the registry relays signed messages but does not act as a CA.

+ +

Learn more about Pilot Protocol's trust model and handshake mechanism. For a deeper technical comparison, see the core concepts documentation covering addressing, encryption, and transport.

`; +--- + + +