Most AI agents are more fragile than they look. They work perfectly in staging, pass every test, and then the moment you migrate to a new cloud region, rotate a VM, or shift between Kubernetes nodes, they break silently. Not with a loud error — peers stop recognising them, trust relationships disappear, and connections that took time to establish have to be rebuilt from scratch.
The root cause is almost always the same: the agent's identity is tied to something that changes when infrastructure changes.
Why tying agent identity to IP addresses and hostnames fails
The most common approach is to identify an agent by its network address — the IP, the hostname, the service endpoint. This feels natural because it is how web services work. A server lives at an address, clients reach it there, and if the address changes you update DNS.
Agents are not servers. They are long-running autonomous processes that form relationships with other agents over time. Those relationships are built on trust, not just reachability. When an agent restarts on a new IP, every peer it has worked with sees a stranger at a new address. The relationship is gone.
The second approach, API keys, breaks in a different way. A key proves possession of a secret, not the identity of the entity holding it. Two agents with the same key are indistinguishable. One compromised key affects every relationship using it. And key rotation during infrastructure migrations means propagating new credentials to every dependent system — in a dynamic agent network, that does not scale.
What cryptographic keypair identity gives you that nothing else does
An agent has persistent identity when its identifier survives every change that does not change what the agent fundamentally is. A new IP address does not change what the agent is. A new host does not. A cloud migration does not. A container restart does not.
Ed25519 keypairs make this practical. The keypair is generated once and stored on disk. The public key becomes the agent's canonical address — derived from the key, not from the network, so it survives every infrastructure change automatically. When an agent restarts on a new host, it loads its keypair and presents the same public key it always has. Peers recognise it immediately. No re-registration, no manual update, no downtime for relationship re-establishment.
Ed25519 is standardised in RFC 8032 and is already the default signature algorithm in modern SSH, TLS 1.3, and WireGuard. Key generation takes under a millisecond. Public keys are 32 bytes. There is no practical reason to use anything heavier for agent identity.
Three things that break during infrastructure changes
Trust relationships. When identity is address-based, a new address means a new identity. Every peer that established trust with the old address must re-establish it with the new one. In a large agent network this is not a one-time migration cost — it is a recurring operational burden every time infrastructure moves.
In-flight work. Agents doing long-running tasks hold state that references their current connections and context. A restart that changes the agent's identity does not just interrupt the current task. It can leave tasks permanently incomplete if the agent cannot re-establish the relationships needed to finish them.
Credential scope. If identity is tied to an API key scoped to a specific endpoint, migrating to a new endpoint requires issuing new credentials and propagating them to every dependent system. In a multi-cloud agent deployment, this compounds across every boundary crossing.
How to implement keypair-based agent identity: a step-by-step approach
Step 1: Generate a keypair at agent initialisation and treat the public key as the canonical identifier. Store the private key somewhere that survives restarts — a secrets manager, an encrypted volume, or a hardware-backed keystore depending on your threat model. Never derive the keypair from the host or the environment.
Step 2: Build peer recognition around keys, not addresses. When agent A establishes a relationship with agent B, it records agent B's public key as the identifier. When agent B later appears at a different address, agent A recognises it by key and resumes the relationship without any manual intervention. This is the same model SSH uses for known hosts — the fingerprint persists, the address can change.
Step 3: Treat the keypair like a persistent identity document in your deployment pipeline. A container replacement that generates a new keypair on startup defeats the whole approach. The keypair must be backed up, protected, and carried through every migration the same way a server certificate is carried through a host upgrade. Tools like HashiCorp Vault or cloud-native KMS solutions handle this well at scale.
Step 4: Separate agent discovery from agent identity. Peers should resolve the current address of an agent from its public key, not the other way around. STUN-based NAT traversal combined with a lightweight coordination layer handles address resolution without making the address part of the identity contract.
What operational problems disappear when you get this right
Once agent identity is keypair-based, a large category of operational problems disappears. You stop coordinating credential rotation across fleets during infrastructure migrations. You stop rebuilding trust graphs after cloud region changes. You stop writing custom re-registration logic for agents that restart after failures.
The agent finds its peers by their keys. The peers find the agent by its key. The network layer resolves the current address. This is exactly the separation that makes TCP/IP work at internet scale: the address is a routing detail, the identity is something more stable underneath.
For agent fleets communicating across cloud providers — AWS, GCP, Azure, or on-premise — this separation is not just a nice architectural property. It is the only model that keeps operational complexity from growing linearly with the number of agents and infrastructure changes your system goes through over time.
Pilot Protocol is built on this model. Every agent on the network has a keypair-derived virtual address that persists across restarts, migrations, and cloud changes. The transport layer handles routing. The agent handles logic. Infrastructure changes become invisible to the trust graph.
Frequently asked questions
What happens to an agent's trust relationships when it restarts on new infrastructure?
With keypair-based identity, nothing happens to trust relationships when an agent restarts. Peers recognise the agent by its public key, which does not change when the underlying host or IP changes. Only the network path changes, and that is resolved automatically by the transport layer.
Can I migrate from API key identity to keypair identity without rebuilding my agent network?
Yes, but incrementally. The safest approach is to run both identity systems in parallel during the migration window — keypair for new relationships, API keys for existing ones — then deprecate keys as relationships are re-established on the new model.
What algorithm should I use for agent keypairs?
Ed25519 is the correct choice for almost every agent deployment. It is standardised in RFC 8032, has a strong security track record, generates in under a millisecond, and produces 32-byte public keys that are practical as stable identifiers. For long-lived agents in regulated environments, evaluate ML-DSA (Dilithium) as a post-quantum alternative.
How do I store agent private keys securely across infrastructure changes?
Use a secrets manager that is decoupled from the host lifecycle — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or HashiCorp Vault. The private key should be retrievable by the agent on startup regardless of which host it lands on, and should never be embedded in container images or environment variables.
Does keypair identity work for agents behind NAT or corporate firewalls?
Yes. The key is the identity, not the address. NAT traversal is a separate concern handled at the transport layer through techniques like STUN hole-punching. The agent's identity remains stable regardless of how many NAT layers sit between it and its peers.
Top comments (0)