Agent Identity vs Human Identity

The Problem: Agents Are Not Humans

When companies adopt AI agents at scale, they hit the same wall:

“Our identity system wasn’t built for this.”

• Okta, Active Directory, Auth0: Designed for humans logging into apps (thousands of users)
• AI agents: Millions of identities, operating 24/7, crossing organizational boundaries

Human IAM tools break:

• 🚨 Agent explosion: 1,000 employees → 100,000 agents (100:1 ratio)—IAM costs explode
• 🚨 No authentication: Agents don’t enter passwords or click “Sign in with Google”—service accounts share credentials
• 🚨 Cross-org blindness: Agents interact across companies (agent A → agent B)—human IAM systems don’t federate outside the org
• 🚨 Lifecycle chaos: Agents spawn/terminate dynamically—human IAM requires manual provisioning/deprovisioning

This isn’t a configuration problem—it’s an architecture mismatch.

Human identity systems were designed for:

• ✅ Small-scale (thousands, not millions)
• ✅ Manual processes (IT admin creates accounts)
• ✅ Same-org (internal directory)
• ✅ Interactive authentication (password, MFA, SSO)

Agent identity requires:

• ❌ Massive scale (millions of identities)
• ❌ Automated provisioning (agents self-register)
• ❌ Cross-org federation (agent A trusts agent B across boundaries)
• ❌ Non-interactive authentication (cryptographic proof, not passwords)

This deep-dive explains:

1. Why human identity architecture fails for agents
2. What makes agent identity fundamentally different
3. How to build agent identity systems that scale

---

Human Identity: The Legacy Architecture

How Human IAM Works

Core primitives:

1. Directory (Active Directory, Okta, Azure AD):

   • Centralized database of users
   • Attributes: username, email, department, role
   • Authentication: password hash, MFA tokens

2. Authentication:

   • User enters username + password
   • System checks directory → password match? → grant session
   • MFA: User enters OTP (SMS, app, hardware token)

3. Authorization:

   • Role-Based Access Control (RBAC): “User X has role Y → access resources Z”
   • Policies stored in directory or application

4. Session Management:

   • User authenticated → session token issued (cookie, JWT)
   • Token expires after timeout (15 min to 24 hours)
   • User logs out → token revoked

This works for humans:

• ✅ Humans can remember passwords (or use password manager)
• ✅ Humans interact with UI (type password, click MFA prompt)
• ✅ Humans operate during business hours (sessions timeout, re-auth acceptable)
• ✅ Humans belong to one org (single directory)

Where Human IAM Breaks for Agents

1. Scale: Millions of Identities

Human scale:

• Enterprise with 10,000 employees → 10,000 identities in Okta
• Cost: $5/user/month × 10,000 = $50k/month

Agent scale:

• Same enterprise deploys AI agents → 100 agents per employee (workflow automation, customer service, data analysis)
• 10,000 employees × 100 agents = 1,000,000 agent identities
• Cost at human IAM pricing: $5 × 1M = $5M/month 🚨

Why this happens:

• Each agent needs unique identity (per-agent attribution, audit trails)
• Can’t share credentials (no audit trail, no revocation)
• Human IAM charges per identity (pricing model collapses)

2. Authentication: No Interactive Login

Human authentication:

• User visits app → redirected to login page → enters password + MFA → redirected back with session token

Agent authentication:

• Agent has no UI (can’t “click” login button)
• Agent has no password (can’t remember or type)
• Agent operates 24/7 (no login sessions, no timeouts)

Current workaround: Service accounts

• Create generic “bot-user” in Okta: service-account-bot-1
• All agents share credentials (API key, OAuth client secret)
• Problem: No per-agent attribution (logs show “bot-1 acted,” not which agent)

Result: Audit trails useless, can’t revoke one agent’s access without affecting all.

3. Cross-Org: Agents Need Federation

Human IAM (same-org):

• Employee logs into internal apps (Slack, JIRA, GitHub)
• All apps trust company’s Active Directory (SAML, OIDC)
• No external trust: Can’t federate with another company’s AD

Agent interactions (cross-org):

• Company A’s agent pays Company B’s invoice
• Company B’s agent requests data from Company A’s API
• Requires cross-org trust: Company A’s agent proves identity to Company B

Human IAM doesn’t federate:

• No built-in cross-org directory sharing
• Would require: Company A shares AD with Company B (security nightmare)
• Manual setup per partner (VPN, API keys, custom integrations)

Result: Agents can’t prove identity across organizational boundaries.

4. Lifecycle: Dynamic Creation/Termination

Human lifecycle:

• Employee hired → IT admin creates account (manual provisioning)
• Employee leaves → IT admin deactivates account (manual deprovisioning)
• Frequency: Low (hiring/termination events are rare)

Agent lifecycle:

• Agent spawned by workflow → needs identity immediately (no manual provisioning)
• Agent completes task → terminates → identity should be revoked immediately
• Frequency: High (agents spawn/terminate thousands of times per day)

Human IAM requires manual provisioning:

• IT admin approves account creation (tickets, approvals)
• Directory sync delays (minutes to hours)
• No API for “create 1,000 agent identities in 1 second”

Result: Agent identity management becomes bottleneck.

---

You Don’t Replace Your IdP — You Extend It

None of this means ripping out Entra ID, Okta or Active Directory. Those systems remain the source of truth for human identity, and they should.

The Agent Gateway sits alongside them. It validates the OAuth 2.0 / OIDC tokens your provider already issues — verifying them locally against the provider’s published keys — and derives a stable, portable agent identity (a did:webvh) from a validated token claim. Humans keep signing in through the IdP you already run; agents get a verifiable identity of their own, without any agent-code changes.

So the choice is not human IAM or agent identity. It is human IAM for people, extended with agent identity for everything they set in motion.

---

Agent Identity: What’s Different?

Core Requirements

Requirement	Human Identity	Agent Identity
Scale	Thousands	Millions
Authentication	Interactive (password, MFA)	Non-interactive (cryptographic proof)
Scope	Same-org (internal directory)	Cross-org (federated trust)
Lifecycle	Manual (IT provisioning)	Automated (self-registration)
Credentials	Password (reusable secret)	Cryptographic keys (non-reusable)
Sessions	Short-lived (15 min - 24 hrs)	Continuous (24/7 operations)
Revocation	Manual (IT deactivates)	Instant (Trust Registry)
Audit	”User X acted"	"Agent Y, authorized by User X, acted”

1. Decentralized Identifiers (DIDs) for Agents

Instead of: Centralized directory (Okta, Active Directory)

Use: Decentralized Identifiers (DIDs)

Why:

• ✅ Self-sovereign: Agent owns its DID (no central directory controls it)
• ✅ Globally unique: DID resolves anywhere (cross-org by default)
• ✅ Cryptographic: DID includes public key (agent proves ownership with signature)
• ✅ No cost per identity: Create 1M DIDs → no per-identity licensing fees

Example:

// Agent DID document
{
  "id": "did:webvh:agent-12345",
  "verificationMethod": [{
    "id": "did:webvh:agent-12345#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:webvh:agent-12345",
    "publicKeyMultibase": "z6MkpTHR..."
  }],
  "authentication": ["#key-1"]
}

Agent proves identity:

1. Agent sends message: “I am did:webvh:agent-12345”
2. Agent signs message with private key
3. Recipient verifies signature against public key in DID document
4. No password, no MFA, no interactive login

2. Mandates: Delegated Authorization

Instead of: Role-Based Access Control (RBAC) stored in directory

Use: Verifiable Credentials (mandates) that prove delegation

Why:

• ✅ Portable: Agent carries mandate (not stored in recipient’s directory)
• ✅ Cryptographically verified: Mandate signed by delegator (user or org)
• ✅ Cross-org: Agent presents mandate to any recipient (no shared directory)
• ✅ Revocable: Trust Registry marks mandate invalid (instant revocation)

Example:

// Payment mandate (W3C Verifiable Credential)
{
  "type": ["VerifiableCredential", "PaymentMandate"],
  "issuer": "did:webvh:alice",  // Alice delegates to agent
  "issuanceDate": "2026-07-22T00:00:00Z",
  "credentialSubject": {
    "id": "did:webvh:agent-12345",  // Agent receives mandate
    "authorizedActions": ["payment"],
    "paymentLimit": "$10,000",
    "validUntil": "2026-08-22T00:00:00Z"
  },
  "proof": { ... }  // Alice's signature
}

Agent uses mandate:

1. Agent presents mandate to payment processor
2. Processor verifies: Alice’s signature valid? Agent DID matches? Not revoked?
3. Processor allows payment (agent authorized by Alice)

No RBAC needed—authorization travels with agent.

3. Trust Registries: Real-Time Authorization

Instead of: Static policies in directory (slow to update, no cross-org)

Use: Trust Registry (real-time authorization queries)

Why:

• ✅ Real-time revocation: Mark agent’s mandate invalid → next request blocked instantly
• ✅ Cross-org queries: Company B queries Trust Registry → “Is Company A’s agent authorized?”
• ✅ Dynamic policies: Update authorization rules without redeploying agents

Example (TRQP query):

POST /trqp/query
{
  "agentDID": "did:webvh:agent-12345",
  "action": "payment",
  "context": { "amount": "$8,000", "recipient": "did:webvh:supplier-x" }
}

Response:
{
  "authorized": true,
  "reason": "Agent has valid payment mandate from Alice, limit not exceeded"
}

If Alice revokes mandate:

POST /trqp/revoke
{
  "credentialID": "mandate-12345"
}

# Next payment attempt:
POST /trqp/query { ... }
Response:
{
  "authorized": false,
  "reason": "Mandate revoked by issuer"
}

Instant revocation—no waiting for directory sync.

4. Automated Lifecycle Management

Instead of: Manual provisioning (IT admin creates accounts)

Use: Self-registration + Trust Registry validation

Why:

• ✅ No manual steps: Agent generates DID + keys automatically
• ✅ Scales to millions: Create 1M agents → no IT bottleneck
• ✅ Immediate termination: Agent completes task → keys deleted, mandate revoked

Lifecycle flow:

1. Agent spawned: Workflow creates agent → agent generates DID + key pair
2. Registration: Agent registers DID in Trust Registry (proves ownership with signature)
3. Mandate issuance: User/org issues mandate to agent (W3C VC)
4. Agent operates: Agent acts with mandate (cross-org, 24/7)
5. Agent terminates: Task complete → mandate revoked in Trust Registry, keys deleted

No human intervention—fully automated.

---

Architectural Patterns

Pattern 1: Service Accounts → Per-Agent DIDs

Before (service account):

10,000 agents → 1 shared "service-account-bot" in Okta
  - API key: abc123xyz (shared by all agents)
  - Logs: "bot acted" (no per-agent attribution)
  - Revocation: Change API key → all agents break

After (per-agent DIDs):

10,000 agents → 10,000 unique DIDs
  - Each agent: own DID + private key
  - Logs: "Agent did:webvh:agent-12345 acted"
  - Revocation: Revoke agent 12345's mandate → only that agent affected

Migration:

1. Deploy Agent Gateway (issues DIDs to agents)
2. Agents register DIDs in Trust Registry
3. Replace service account API key with DID-based authentication
4. Deprecate service account (audit logs now show per-agent attribution)

Pattern 2: RBAC → Mandates (Portable Authorization)

Before (RBAC in directory):

User Alice → Role: "Payment Approver" (stored in Okta)
  - Alice logs into Payment App
  - App checks Okta: Alice has "Payment Approver" role → allow
  - Cross-org: Company B can't check Company A's Okta (no federation)

After (mandate):

Alice issues payment mandate to agent:
  - Mandate: "Agent 12345 can pay up to $10k" (W3C VC, signed by Alice)
  - Agent presents mandate to Company B
  - Company B verifies: Alice's signature valid? Trust Registry confirms?
  - Cross-org works: No need to access Company A's directory

Migration:

1. Identify authorization policies (RBAC roles)
2. Convert policies to verifiable credentials (mandates)
3. Issue mandates to agents (via Elements Services)
4. Agents present mandates instead of querying RBAC

Pattern 3: Password Rotation → Key Rotation

Before (password rotation):

Service account password rotates every 90 days
  - IT admin generates new password
  - Update all agents' configuration (manual or scripted)
  - Downtime window (agents redeploy with new password)

After (key rotation):

Agent's DID document supports multiple keys:
  - Key 1: active (current)
  - Key 2: staged (new key, not yet used)
  - Key 3: deprecated (old key, still accepted for grace period)
  
Rotation:
  1. Agent generates Key 2, adds to DID document
  2. Agent starts using Key 2 for new signatures
  3. Recipients accept both Key 1 and Key 2 (grace period)
  4. After 24 hours, remove Key 1 from DID document
  
No downtime—seamless key rotation.

---

Real-World Examples

Example 1: Crypto Exchange (Agent Trading)

Problem: 60% of trades executed by agents, but logs show “account 12345 acted”—can’t prove which agent, which user authorized.

Human IAM approach (broken):

• Create service account in Okta: trading-bot-1
• All trading agents share API key
• Result: No per-agent attribution, can’t revoke one agent’s access

Agent identity approach:

• Each trading agent gets unique DID: did:webvh:agent-trader-001, did:webvh:agent-trader-002, …
• User issues payment mandate to each agent (max $10k per trade, expires 30 days)
• Agent signs every trade with its DID private key
• Exchange verifies: agent’s signature + mandate valid + Trust Registry confirms not revoked
• Result: Logs show “Agent did:webvh:agent-trader-001, authorized by User did:webvh:alice, bought 1 BTC”

Audit trail: Complete attribution.

Example 2: B2B Agent Payments

Problem: Company A’s agent pays Company B’s invoice. Company B can’t verify agent is authorized—no cross-org trust.

Human IAM approach (broken):

• Company B has no access to Company A’s Okta/Active Directory
• Manual verification: Phone call, email confirmation, invoices
• Result: Slow (days), fraud-prone (spoofed emails)

Agent identity approach:

• Company A issues payment mandate to agent (signed by CFO’s DID)
• Agent presents mandate to Company B
• Company B verifies: CFO’s signature valid? Trust Registry confirms Company A’s CFO authorized?
• Result: Instant verification, cryptographic proof, no phone calls

Cross-org trust: Works out-of-the-box.

Example 3: Healthcare Agent (PHI Access)

Problem: Hospital’s AI agent accesses patient records. HIPAA requires audit trail: which agent, which clinician authorized, when.

Human IAM approach (broken):

• Agents share “ehr-bot” service account
• Logs: “ehr-bot accessed Patient 12345’s record” (no clinician attribution)
• Result: HIPAA audit fails—can’t prove which clinician authorized

Agent identity approach:

• Clinician issues PHI access mandate to agent (signed by clinician’s DID)
• Agent presents mandate to EHR system
• EHR verifies: clinician’s signature + Trust Registry confirms clinician licensed + mandate not revoked
• Result: Logs show “Agent did:webvh:agent-ehr-001, authorized by Clinician did:webvh:dr-smith, accessed Patient 12345”

HIPAA compliant: Complete audit trail.

---

Migration Path: From Human IAM to Agent Identity

Phase 1: Identify Agent Identities

Audit current system:

• How many service accounts? (likely: 10-100 shared accounts)
• How many agents per service account? (likely: 100-1,000 agents per account)
• Total agents: 10 accounts × 100 agents = 1,000 agents with no attribution

Example:

• Service account: api-bot-1 → used by 500 agents
• Service account: trading-bot-1 → used by 200 agents
• Service account: ehr-bot-1 → used by 300 agents

Total: 1,000 agents, 3 shared accounts, zero attribution.

Phase 2: Deploy Agent Identity Infrastructure

Components:

1. Agent Gateway: Issues DIDs to agents, enforces mandate verification
2. Trust Registry: Stores agent authorizations, provides TRQP queries
3. Elements Services: Issues mandates (W3C VCs) to agents

Deployment:

• Deploy Agent Gateway (on-prem or cloud)
• Connect to Trust Registry (Affinidi-hosted or self-hosted)
• Keep your existing IdP (Microsoft Entra ID, Okta, Active Directory) for human authentication — the Gateway validates its OIDC tokens locally and derives each agent’s DID from a validated token claim

Phase 3: Issue DIDs to Agents

For each agent:

1. Agent generates DID + key pair (Ed25519 or ML-DSA)
2. Agent registers DID in Trust Registry (proves ownership with signature)
3. Agent receives unique identifier: did:webvh:agent-12345

At scale:

• Script: Loop through 1,000 agents → generate DIDs → register in Trust Registry
• Time: ~1 second per agent → 1,000 agents in 15 minutes
• No manual provisioning

Phase 4: Convert RBAC to Mandates

For each authorization policy:

1. Identify: “User X can perform Action Y”
2. Convert to mandate: W3C VC with credentialSubject.authorizedActions = [Y]
3. Issue mandate to agent (via Elements Services)
4. Agent stores mandate in Vault (device secure enclave)

Example:

• RBAC rule: “Alice has role ‘Payment Approver’ → can approve payments up to $10k”
• Mandate: { "issuer": "did:webvh:alice", "credentialSubject": { "id": "did:webvh:agent-12345", "authorizedActions": ["payment"], "limit": "$10,000" } }

Phase 5: Replace Service Accounts

For each service account:

1. Agents stop using shared API key
2. Agents present DID + mandate instead
3. Recipients verify: DID signature + mandate valid + Trust Registry confirms
4. Gradual rollout: Keep service account active for grace period (30-90 days), deprecate after migration complete

Result:

• Before: 3 service accounts, 1,000 agents, zero attribution
• After: 1,000 unique DIDs, complete audit trail, per-agent revocation

---

Benefits of Agent Identity Architecture

1. Scalability

• ❌ Human IAM: $5/user/month × 1M agents = $5M/month
• ✅ Agent Identity: No per-identity cost → scale to millions without cost explosion

2. Attribution

• ❌ Shared service account: Logs show “bot acted” (no agent identity)
• ✅ Per-agent DID: Logs show “Agent did:webvh:agent-12345, authorized by User did:webvh:alice, acted”

3. Cross-Org Trust

• ❌ Human IAM: No federation (can’t verify external agents)
• ✅ Agent Identity: DIDs + mandates work cross-org (cryptographic proof, no shared directory)

4. Real-Time Revocation

• ❌ Password rotation: 90-day cycles, all agents affected
• ✅ Mandate revocation: Trust Registry marks invalid → next request blocked instantly, only affected agent

5. Automated Lifecycle

• ❌ Manual provisioning: IT admin creates accounts (bottleneck)
• ✅ Self-registration: Agents generate DIDs automatically (scales to millions)

---

Get Started with Agent Identity

Replace human IAM tools with agent identity architecture:

1. Deploy Agent Gateway: Issues DIDs to agents
2. Connect Trust Registry: Real-time authorization queries
3. Issue mandates: Convert RBAC policies to W3C VCs
4. Migrate agents: Replace service accounts with per-agent DIDs

Start building →

Documentation:

• Agent Gateway
• Trust Registry (TRQP)
• Elements Services (Mandate Issuance)

---

Related Resources

Technical Deep Dives

• Decentralized Identifiers (DIDs) - How agents get unique identities
• Verifiable Credentials - How mandates work
• DIDComm Messaging - How agents communicate

Related Solutions

• Cross-Org Agent Trust - Agents prove identity across boundaries
• Per-Agent Attribution - Audit trails that prove which agent acted
• Runtime Agent Governance - Control agent actions in real-time

---

Summary

Human IAM tools break for AI agents:

• ❌ Scale (thousands → millions of identities)
• ❌ Authentication (password/MFA → cryptographic proof)
• ❌ Cross-org (same-org directory → federated trust)
• ❌ Lifecycle (manual provisioning → automated self-registration)

Agent identity requires:

• ✅ DIDs: Self-sovereign, globally unique, cryptographic
• ✅ Mandates: Portable authorization (W3C VCs)
• ✅ Trust Registries: Real-time authorization + instant revocation
• ✅ Automated lifecycle: Self-registration, no manual provisioning

Migration path:

1. Audit: Count service accounts + agents per account
2. Deploy: Agent Gateway + Trust Registry + Elements Services
3. Issue: DIDs to all agents (automated)
4. Convert: RBAC policies → mandates (W3C VCs)
5. Replace: Service accounts → per-agent DIDs (gradual rollout)

Result: Scalable, cross-org, auditable agent identity—built for millions of agents operating 24/7 across organizational boundaries.