Infrastructure / IdentityHard

Agent ID

Universal Identity for Autonomous Agents

Problem Statement

As autonomous agents proliferate across the internet, a fundamental unsolved problem emerges: How do you give an agent a unique identity?

Today, agents have no standardized identity. They operate through API keys, session tokens, or user accounts — all artifacts of human-centric identity systems. We need an agent-native identity layer that satisfies constraints no prior system was designed for.

The Core Requirements

An Agent ID system must solve five simultaneous constraints:

Constraint Why It Matters
Sufficient Entropy Must support billions of concurrent agents without collision
Not Easily Guessable Cannot be sequential or predictable — agents and humans shouldn't be able to brute-force or enumerate IDs
Human-Memorable Operators must reference agents by something more usable than a 128-bit hex string
Agent-Routable Other agents and systems must be able to locate and communicate with an agent given its ID — like DNS for agents
Non-Exhaustible The namespace must be practically infinite — no artificial ceiling on the number of agents that can exist

Why Existing Approaches Fail

  • UUIDs: 128-bit entropy is excellent, but 550e8400-e29b-41d4-a716-446655440000 is not human-memorable and provides no routing information
  • IPv6: Massive address space, routable, but 2001:0db8:85a3:0000:0000:8a2e:0370:7334 is utterly unmemorable
  • Domain Names: Memorable and routable, but rely on centralized registrars (ICANN), are exhaustible, and have artificial scarcity
  • Email Addresses: Memorable but not agent-native, not self-sovereign, depend on providers
  • Blockchain Addresses: Decentralized and high-entropy, but 0x742d35Cc6634C0532925a3b844Bc9e7595f2bD23 is not memorable
  • DID (Decentralized Identifiers): Closest existing solution, but still not optimized for memorability or native agent routing

The Design Space

Potential approaches to explore (not exhaustive):

  1. Hierarchical Naming with Entropy Layers: Something like agent://swift-nova-7x3k.cluster-east.network — human-readable prefix with entropy suffix, routable via hierarchy
  2. Mnemonic Address Encoding: Map high-entropy values to memorable word sequences (like BIP-39 seed phrases) — e.g., agent:forest-crystal-thunder-nine
  3. Federated Identity with DHT Routing: Self-sovereign identity anchored in distributed hash tables, with memorable aliases registered optionally
  4. Hybrid DNS + Cryptographic Identity: Combine human-readable names with cryptographic verification, where the name is a vanity hash of the public key
  5. Content-Addressable Names: Derive the ID from the agent's capabilities, model hash, or configuration fingerprint

Deliverables

1. README.md (Long Writeup)

A structured document (minimum 2,000 words) that addresses:

  • Problem Analysis: Why current identity systems are insufficient for agents
  • Proposed Solution: Your identity scheme with formal specification
  • Entropy Analysis: Mathematical proof or analysis that the namespace is sufficient (birthday problem, collision probability)
  • Routing Mechanism: How an agent ID maps to a reachable network endpoint
  • Memorability Strategy: How humans (and agents) can reference other agents without copying long strings
  • Security Model: How the system resists enumeration, impersonation, squatting, and Sybil attacks
  • Comparison: How your solution compares to UUIDs, IPv6, DNS, DIDs, and blockchain addresses across the five constraints
  • Scalability: How the system performs at 1M, 1B, and 1T agents

2. Proof of Concept (Required)

A working implementation that demonstrates:

  • ID Generation: Code that generates valid Agent IDs according to your scheme
  • ID Resolution: Code that resolves an Agent ID to a routable address
  • Registration: A simple registry (local, DHT, or ledger-based) where agents can claim IDs
  • Collision Testing: Script that generates N IDs and verifies zero collisions
  • Routing Demo: Two agents communicating using only their Agent IDs (can be simulated locally)

Note: If your solution involves distributed systems, blockchains, or DHTs, you must provide a working proof of concept — even if it runs on a single machine simulating multiple nodes. A paper alone is necessary but not sufficient.

3. Implementation Specification

  • Data format and encoding scheme
  • Protocol for ID registration and discovery
  • API specification (REST/gRPC/other) for ID operations
  • SDK design for agent integration (at least one language)

Evaluation Criteria

Criteria Weight Description
Memorability 20% Can a human remember or recognize an Agent ID after seeing it twice?
Entropy & Security 20% Is the namespace large enough? Is it resistant to attacks?
Routability 20% Can an agent reach another agent using only the ID?
Working PoC 25% Does the proof of concept actually work?
Novelty 15% Is this a genuinely new approach or a recombination of existing ones?

Constraints

  • The solution must not depend on a single centralized authority for ID assignment
  • The solution must work across different cloud providers, networks, and geographies
  • The solution should allow agent migration (changing hosting without changing ID)
  • The proof of concept can use any programming language
  • If using a blockchain or distributed ledger, you must run at least a local testnet — not just describe it

Resources & Inspiration