The AI agent explosion is here. Every week brings new frameworks—AutoGPT, CrewAI, LangGraph, OpenAI's Assistants API—and enterprises are rushing to deploy autonomous agents that can book meetings, execute trades, manage infrastructure, and interact with external services on behalf of users.
There's one problem nobody's talking about: these agents have no identity.
When an AI agent calls your API, who is it? Who authorized it? What permissions does it have? Can you revoke access if something goes wrong? Today's answer is usually "we gave it an API key and hoped for the best."
This is a security disaster waiting to happen. And decentralized identity (DID) technology is the fix.
The Agent Identity Crisis#
Consider what happens when you deploy an AI agent today:
- You create an API key or OAuth token
- You embed that credential in the agent's configuration
- The agent uses that credential for all requests
- Every service sees the same identity—yours
The agent isn't an entity. It's you, wearing a mask. When it calls Stripe, it's "you." When it queries your database, it's "you." When it accidentally sends 10,000 emails, it's "you."
This creates three immediate problems:
Attribution failure. When something breaks, audit logs show your credentials. Good luck figuring out which of your twelve agents caused the incident at 3 AM.
Permission sprawl. Agents inherit your permissions. That research agent that only needs read access to public data? It's running with your admin credentials because that's easier than setting up proper scoping.
Revocation nightmares. To disable a compromised agent, you revoke your credentials—which breaks every other agent and service using those same credentials.
The traditional solution is to create service accounts for each agent. But service accounts in centralized identity providers still require someone to manage them, still create single points of failure, and still don't solve the fundamental problem: the agent's identity is derived from the platform, not inherent to the agent itself.
What DID Changes#
Decentralized Identifiers flip the model. Instead of identity being granted by a platform, identity becomes an intrinsic property of the entity—human or machine.
A DID looks like this:
did:abt:z1muQ3xqHQK2uiACHyChikobsiY5kLqtShA
That identifier is:
- Self-sovereign: The agent (or its owner) controls it, not a central authority
- Cryptographically verifiable: The agent can prove it controls this DID by signing with its private key
- Resolvable: Anyone can look up the DID Document to find public keys and service endpoints
- Portable: The identity works across chains, services, and platforms
When an AI agent has its own DID, it exists as a first-class entity. Services can recognize it, grant it specific permissions, and audit its actions independently of its creator.
Building Agent Identity with ArcBlock#
ArcBlock's DID implementation provides the infrastructure to make agent identity practical. Here's how the pieces fit together.
Creating an Agent DID#
Every agent gets its own decentralized identifier. On ArcBlock, this involves generating a key pair and registering the DID:
const { WalletType, fromRandom } = require('@arcblock/did');
// Create a wallet for the agent
const agentWallet = fromRandom(WalletType.default);
console.log('Agent DID:', agentWallet.toAddress());
console.log('Public Key:', agentWallet.publicKey.toString('hex'));
The agent now has an identity that doesn't depend on any platform. The private key stays with the agent; the DID can be shared with any service that needs to verify the agent's identity.
Verifiable Credentials for Permissions#
Raw identity isn't enough. You need to express what the agent is allowed to do. This is where Verifiable Credentials (VCs) come in.
A VC is a signed statement about an entity. For AI agents, these credentials might include:
- Capability credentials: "This agent can read from the orders database"
- Scope credentials: "This agent operates on behalf of user X for task Y"
- Limit credentials: "This agent can spend up to $100 per day"
const { issueCredential } = require('@arcblock/vc');
const agentCapability = await issueCredential({
issuer: adminWallet, // The human or org granting permission
subject: agentWallet.toAddress(),
type: 'AgentCapabilityCredential',
claims: {
capabilities: ['database:orders:read', 'api:shipping:write'],
rateLimit: { requests: 1000, period: 'hour' },
expiresAt: '2025-12-31T23:59:59Z'
}
});
Now when the agent presents this credential, services can verify:
- The credential was issued by a trusted authority
- The credential hasn't expired
- The credential applies to this specific agent
- The requested action falls within the granted capabilities
Authentication Flow#
When an agent connects to a service, the authentication flow uses DID-based verification:
// Agent side: Create a signed request
const authRequest = {
did: agentWallet.toAddress(),
timestamp: Date.now(),
nonce: crypto.randomBytes(16).toString('hex'),
capabilities: [agentCapability]
};
authRequest.signature = agentWallet.sign(
JSON.stringify(authRequest)
);
// Service side: Verify the request
const isValid = await verifyDIDAuth(authRequest);
const capabilities = await extractVerifiedCapabilities(authRequest);
if (isValid && capabilities.includes('database:orders:read')) {
// Grant access
}
No shared secrets. No API keys to rotate. The agent proves who it is cryptographically, and its permissions are encoded in portable, verifiable credentials.
Real-World Agent Scenarios#
Let's walk through how this applies to actual agent deployments.
Multi-Agent Systems#
You're running a customer service system with three agents: a triage agent, a technical support agent, and a billing agent. Each needs different permissions.
Without DID, you'd create three service accounts, manage three sets of credentials, and hope you got the permissions right.
With DID:
const triageAgent = createAgentWithDID({
name: 'triage-agent',
capabilities: ['tickets:read', 'tickets:route']
});
const techAgent = createAgentWithDID({
name: 'tech-support-agent',
capabilities: ['tickets:read', 'tickets:update', 'kb:read']
});
const billingAgent = createAgentWithDID({
name: 'billing-agent',
capabilities: ['tickets:read', 'billing:read', 'refunds:create:limit:50']
});
Each agent has its own identity. Audit logs show exactly which agent took which action. If the billing agent gets compromised, you revoke its credential without affecting the others.
Cross-Platform Agent Operations#
Your research agent needs to query your internal database, call a third-party API, and store results in cloud storage. Three different services, three different auth systems.
With DID, the agent presents the same identity everywhere:
// Same agent DID, different capability credentials
const dbCredential = await getCredential(agentDID, 'internal-db');
const apiCredential = await getCredential(agentDID, 'research-api');
const storageCredential = await getCredential(agentDID, 'cloud-storage');
// Each service verifies the same identity,
// different permissions
await internalDB.query(data, { auth: dbCredential });
await researchAPI.fetch(params, { auth: apiCredential });
await cloudStorage.write(results, { auth: storageCredential });
The agent's identity is portable. Services that support DID verification can all work with the same agent identity, while enforcing their own permission models.
Delegation and Hierarchy#
Some agents create sub-agents. A planning agent might spawn worker agents for specific tasks. How do you handle identity for dynamically created agents?
DID supports delegation. The parent agent can issue credentials to child agents that express limited, scoped permissions:
// Parent agent creates a temporary worker
const workerWallet = fromRandom(WalletType.default);
// Parent issues a scoped credential
const delegatedCredential = await issueCredential({
issuer: parentAgentWallet,
subject: workerWallet.toAddress(),
type: 'DelegatedAgentCredential',
claims: {
parentAgent: parentAgentWallet.toAddress(),
scope: 'task:12345',
capabilities: ['files:read:task:12345'],
expiresAt: new Date(Date.now() + 3600000) // 1 hour
}
});
The worker agent has its own identity but limited, time-bounded permissions derived from its parent. Services can verify the delegation chain.
The Infrastructure Requirement#
DID-based agent identity requires infrastructure that most enterprises don't have yet. You need:
- DID resolution: Looking up DID Documents to get public keys
- Credential verification: Checking signatures and expiration
- Revocation checking: Ensuring credentials haven't been invalidated
- Key management: Secure storage for agent private keys
ArcBlock provides this infrastructure through its blockchain platform. DIDs are registered on-chain, making them globally resolvable. Credential status is tracked, enabling reliable revocation. The DID Wallet SDK handles key management across platforms.
For developers integrating with existing systems, ArcBlock's DID gateway provides REST APIs that abstract the blockchain complexity:
# Resolve a DID
curl https://did.abtnetwork.io/api/did/z1muQ3xqHQK2uiACHyChikobsiY5kLqtShA
# Verify a credential
curl -X POST https://did.abtnetwork.io/api/vc/verify \
-d '{"credential": "..."}'
What's Next#
AI agents are going to become the primary way software interacts with software. When that happens, identity can't be an afterthought.
The building blocks exist today. DIDs provide self-sovereign identity for any entity. Verifiable Credentials encode permissions in a portable, cryptographic format. Blockchain infrastructure makes these identities globally resolvable and auditable.
The organizations deploying AI agents now should be thinking about identity infrastructure. The ones using shared API keys and service accounts will spend the next five years dealing with security incidents and compliance failures.
The ones building on decentralized identity will have agents that are secure, auditable, and interoperable by default.
The choice seems obvious. The question is whether the industry will make it before the first major agent-related breach forces the issue.