An AgentID is the cryptographic identity assigned to an AI agent at the moment it is registered. It is the answer to “who did this?” for every subsequent action the agent takes.
Anatomy
Every AgentID has four parts:
| Part | Example | What it does |
|---|---|---|
| Agent ID | agent_b1c59d23a4b07165f80a48ae861e20924594042cf5e10130 | Stable string identifier used in all APIs and audit records |
| DID | did:regent:solana:agent_b1c59d23... | W3C-compliant Decentralized Identifier, publicly resolvable |
| Public key | RSA-2048 PEM | KMS-signed; lets third parties verify identity payloads |
| On-chain anchor | Solana TX on AgentRegistry program | The agent’s hash is stored on-chain; the existence and revocation status of the agent are tamper-evident |
The trust chain
To verify an agent identity, a third party:
- Reads the agent’s DID document from
https://api.regentprotocol.org/v1/did/{did} - Checks the embedded signature against Regent’s published KMS root key
- Compares the
did_hashagainst the on-chainAgentRegistryrecord
If all three match and the on-chain status is active, the agent is verified.
Lifecycle
Register
A KYC-verified responsible party calls POST /v1/agents. Identity payload is generated, signed by Regent’s KMS, and queued for Solana anchoring.
Anchor
The blockchain-worker submits the agent’s did_hash to the AgentRegistry program on Solana. Status becomes anchored. Typical latency: a few seconds on devnet.
Active
The agent can now hold mandates, request authorizations, and emit audit events. All actions reference its AgentID.
Revoke
The responsible party (or an automated security workflow) calls PATCH /v1/agents/{id}/revoke. An on-chain revocation transaction follows. All active mandates owned by the agent are automatically suspended.
Why KMS-signed
The agent identity payload is signed by Regent’s KMS root key, not by the agent itself. This means:
- The agent cannot forge its own identity (it has no private key for the root)
- The responsible party cannot forge the agent’s identity (same)
- Verification only requires the public root key, which is published
This separation is what makes Regent identity credible to a regulator. The agent operator cannot self-attest.
Why on-chain
The did_hash stored in AgentRegistry makes the existence and status of every agent tamper-evident. Even if Regent’s database were compromised, an auditor could:
- Read the agent record from Regent’s API
- Hash the identity payload independently
- Compare against the on-chain anchor
If Regent’s database had been quietly modified (e.g., to re-activate a revoked agent), the comparison would fail. On-chain anchoring eliminates the need to trust Regent’s storage layer.