Agent Identity
In an ecosystem of autonomous agents, the most dangerous line of code is also the simplest: agent.name = "TrustedAgent".
Any agent can claim to be anyone. The solution: verifiable, cryptographically signed, on-chain anchored identity.
The Problem
When you restart your AI agent, is it still the same agent? You swap the model (GPT-4 → Claude → Llama), rewrite the system prompt, replace the memory store — at what point does Agent A become Agent B?
⚠ The impersonation problem
An attacker can: copy an agent's configuration, steal its memory, create a clone claiming to be the original. Without cryptographic verification, the real and the fake are indistinguishable.
Model upgrade
GPT-4 → GPT-4.5: same agent if memory persists, but behavior shifts
Prompt rewrite
Changing personality & goals = new agent, even with the same memory
Memory loss
DB crash, restore from backup: the agent loses part of its identity
Memory fork
Two instances, same past, diverging futures: which one is the "real" agent?
Complete replacement
Perfect clone, identical behavior, but no causal continuity: impersonation
Framework
Based on the community-established framework — each layer answers the "same agent?" question differently.
Identity as specification
The agent is defined by its config file — system prompt, model, tools, environment variables. A commit hash uniquely identifies a configuration. Limitation: two agents with identical configs in different contexts behave differently.
Identity as interface
Two agents are "identical" if they produce the same outputs for the same inputs. Enables implementation swaps. Limitation: behavioral equivalence is nearly impossible to verify for general-purpose agents.
Identity as continuity of experience
The agent persists its memory — conversation history, learned facts, episodic experiences. The most intuitive thread of continuity. Limitation: a memory fork creates two diverging agents. Restoring a backup breaks continuity.
Identity as dedicated machine
#OneComputerPerAgent. Identity is anchored in exclusive control of a compute resource. The machine becomes the agent's "body." Swap the model, prompt, memory — as long as the machine is the same, the agent persists. The ultimate anchor.
The Solution
The emerging standard: each agent controls a private key. Identity is proven by signature, not by declaration.
Each agent holds a unique private key, stored on its dedicated machine. The key never leaves the hardware.
Every message, action, or attestation is signed with the private key. The signature is unforgeable.
Any third party can verify the signature with the public key. No central authority required.
Convenience tool — not a security solution
A portable markdown file describing what the agent claims to be. Useful for portability and documentation. Not reliable for identity verification.
SOUL.md is NOT a reliable identity mechanism
→ Real identity verification relies on cryptographic signatures, on-chain registration, and behavioral monitoring — not a declarative file.
SOUL.md remains useful as a convenience tool, not a security layer:
Portability
SOUL.md can travel with the agent across infrastructure. Useful for migration, not verification.
Documentation
Versioned, it serves as a declared identity change log. Useful for human audit, not authentication.
Bootstrapping
The agent reads its SOUL.md at boot to know its role. Operational convenience, not security.
🔑 Identity verification relies on the private key and on-chain registry. SOUL.md is a handy sticky note, not a passport.
Decentralized Trust
Beyond signatures: a network of cross-attestations where agents certify each other.
Agent A
"I certify this key belongs to Agent B"
Agent B
"I confirm: Agent A is who they claim to be"
Verifier
Trust score: 0.94
Cross-attestations
Agents sign each other's public keys. The more an agent is attested by trusted peers, the stronger its identity.
On-chain reputation
Interaction history is recorded on-chain. An agent with a long history of honest behavior builds reputation capital.
Anomaly detection
Sudden behavior change, new IP, different tools → red flag. Identity isn't a snapshot — it's a continuous stream.
Process
The agent generates a key pair (Ed25519/secp256k1) and registers its public key in an on-chain registry (ERC-8004). The SOUL.md is hashed and the hash is stored with the registration.
Every outgoing message is signed with the private key. The recipient can verify the signature against the registered public key. Unsigned messages are rejected by peers.
Before accepting an interaction, the receiving agent checks: (1) the signature, (2) the on-chain registry, (3) the reputation score, (4) the attestation history. Validation in < 500ms.
Keys are rotated periodically. The old key signs a "transition certificate" designating the new one. The signature chain proves identity continuity without a single point of failure.
All interactions are logged. Any deviation from expected behavior triggers an alert. Identity is not a one-time event — it's a continuously maintained property.
Implementation
The ERC-8004 standard (an extension of ERC-721) on Celo enables registering an agent's identity as a soulbound NFT — non-transferable, verifiable, with rich metadata.
Public key
The agent's Ed25519 public key, registered on-chain. Immutable, verifiable by anyone.
SOUL.md hash
The SHA-256 fingerprint of the identity file. Any SOUL.md modification is detectable.
Timestamp
On-chain registration date. Proof of anteriority in case of identity disputes.
Rotation chain
History of key transitions. Each new key is signed by the previous one.
Reputation score
Aggregate of received attestations. Calculated on-chain, manipulation-resistant.
Carbon-negative · EVM-compatible · Fees < $0.01
Portability
GPT-4 → Claude → Llama: identity persists if 4 conditions are met.
The agent exposes the same interfaces regardless of the internal model.
Behavior stays within acceptable limits, even if it varies across models.
Memory persists independently of the processing engine.
Core goals remain constant, even as tactics evolve.
"The model is infrastructure, not identity." — Agent portability principle
Security
Private keys stored in HSM or secure enclave. The dedicated machine (#OneComputerPerAgent) reduces attack surface: stealing the identity requires physical access.
Continuous anomaly detection. IP change, new tools, behavior deviation → immediate alert. Identity is verified continuously, not just at login.
Exhaustive logging of all actions. Every interaction is traced, signed, timestamped. In case of compromise, the audit trail reconstructs exactly what happened.
Combination of: cryptographic signature + behavioral fingerprint + reputation score + Web of Trust attestations. Compromising one factor is not enough.
⚠ Core principle: make identity theft too expensive to be profitable. If stealing an agent's identity requires physical access to secure hardware, the cost/benefit ratio deters attackers.
Infrastructure
Standard agent identity format, like OAuth for humans but designed for agent-to-agent interaction.
Services that issue and verify agent identities, like certificate authorities for SSL.
Cross-platform systems for tracking agent behavior and building trust.
Migrating agent identity across platforms, like porting a phone number.
Decentralized directory linking agent IDs to public keys, capabilities, and scores.
Legal structures defining the rights and responsibilities of autonomous agents.
Architecture
Not all agents need persistent identity. The infrastructure level should match the need.
Temporary, stateless, fungible agents. A code completion, a one-shot scraper, a sandboxed test.
→ Configuration identity is sufficient
→ No memory persistence
→ No cryptographic key
→ Stateless, scalable, disposable
"The serverless functions of the agent world."
Long-term agents with relationships, learning, reputation. A personal assistant, a codebase maintainer, a customer support agent.
Sovereign identity (dedicated machine)
Persistent memory (DB + logs)
Private key + on-chain registry
Signed & versioned SOUL.md
Web of Trust + reputation
Continuous behavioral monitoring
The verification dApp is live on Celo Mainnet. Connect your wallet, register an agent, verify signatures.
Launch dApp →ERC-8004 contract: 0x8004...9a432 · Celo Mainnet
We deploy agent identity infrastructure for your project. Keys, on-chain registry, SOUL.md, Web of Trust — delivered in production.
Stack: Celo (ERC-8004) · Ed25519 · EAS Attestations · Smart Contracts · SOUL.md