AI Agent Identity - Overview

View as Markdown

Why Agents Need DIDs

As AI agents become autonomous actors in the digital economy — shopping on behalf of users, negotiating contracts, accessing APIs, and collaborating with other agents — they face a fundamental identity problem:

ProblemImpact
No native identityAgents operate with borrowed human credentials or static API keys
No accountabilityWhen an agent acts, there is no cryptographic proof of who authorized it
No verifiable capabilitiesA service cannot verify what an agent is authorized to do
No trust scoringNo way to distinguish a well-behaved agent from a rogue one
No delegation chainMulti-agent orchestration has no authorization framework
No complianceEU AI Act requires traceable agent identity for high-risk systems

IDA solves these problems by giving AI agents first-class Decentralized Identifiers.

Agent Identity Model

Core Concepts

1. Agent DID

Every AI agent receives its own DID: did:adi:agent:<identifier>. This DID:

  • Is registered on the ADI blockchain
  • Has its own key pair (the agent holds the private key)
  • Links to the operator (human/org) who deployed it
  • Contains agent-specific metadata (model, capabilities, autonomy level)

2. Delegation Chains

Agents act on behalf of humans or organizations through cryptographic delegation:

Human DID --[Delegation VC: scope, constraints]--> Agent DID
Agent DID --[Attenuated Delegation: narrower scope]--> Sub-Agent DID

Key principle: scope can only narrow at each hop, never widen (scope attenuation).

3. Invocation-Bound Capability Tokens (IBCT)

When an agent performs an action, it presents an IBCT that fuses:

  • Identity: Who is this agent?
  • Authorization: What is it allowed to do?
  • Provenance: Who authorized it, and through what chain?

Two formats:

  • Compact JWT: EdDSA-signed JWT for single-hop delegation
  • Chained Biscuit: Append-only token with Datalog policies for multi-hop

4. Agent Trust Registry

On-chain smart contract that tracks:

  • Agent registration and lifecycle state
  • Trust scores computed from verification history
  • Capability attestations from third parties
  • Autonomy levels (Intern, Junior, Senior, Principal)

5. Agent Cards

Machine-readable JSON documents describing an agent’s identity, capabilities, authentication methods, and service endpoints. Compatible with the A2A protocol.

Agent Lifecycle

StateDescription
RegisteredAgent DID created, no active delegation
ActiveAgent has delegation VC and can operate
SuspendedTemporarily disabled, credentials frozen
DecommissionedPermanently disabled, all credentials revoked

Autonomy Levels

Agents operate under configurable trust tiers:

LevelPermissionsPromotion Criteria
InternHuman approval required for all actionsDefault for new agents
JuniorCan act within narrow scope, HITL for high-risk>100 successful actions, >60 trust score
SeniorCan act within full delegation scope>1000 actions, >80 trust score, operator approval
PrincipalCan delegate to sub-agents>5000 actions, >90 trust score, audit passed

Protocol Integration

IDA’s agent identity integrates with emerging AI protocols:

ProtocolIntegration
MCP-IIdentity + delegation verification on MCP tool calls
A2AAgent Card serving, task lifecycle, OAuth 2.0 + DID auth
AIPVerifiable delegation via IBCTs across protocols
DIDCommSecure agent-to-agent messaging

Use Cases

Delegated Commerce

  1. User issues a delegation VC to a shopping agent: “purchase groceries, max $200/week”
  2. Agent presents delegation + IBCT to merchant
  3. Merchant verifies chain: user DID -> delegation -> agent DID
  4. Transaction is logged with full provenance

Multi-Agent Orchestration

  1. Enterprise deploys DataCollector, Analyzer, ReportWriter agents
  2. Each gets scoped delegation from the org DID
  3. DataCollector sub-delegates narrower scope to Analyzer
  4. Full chain is verifiable at every hop

EU AI Act Compliance

  1. Auditor issues compliance VCs to agent
  2. Healthcare provider requires compliance proof before granting access
  3. Agent presents ZK-proof: “I am EU AI Act compliant”
  4. Model updates trigger re-assessment

Next Steps