Part-1: Can your Agents prove their identity without a central authority?

If you are building multi-agent systems and looking at the future of Agentic identity, this post is for you. As agents become more autonomous and operate across team and organizational boundaries, who can talk to whom becomes a security problem, not a routing problem. This post describes a practical approach using W3C Decentralized Identifiers and Verifiable Credentials, with working Python code you can run locally in under 10 minutes.

The Problem

Multi-agent systems today rely on shared secrets (API keys) or central registries (service meshes, config files) for trust. Both break down when:

• An agent is compromised and you need to revoke access immediately
• Agents span organizational boundaries (different teams, companies, cloud accounts)
• The central registry goes down or is itself compromised

These patterns assume you control the entire system. They do not scale to autonomous agents cooperating across trust boundaries.

What Is Decentralized Identity?

To understand decentralized identity (DID), it helps to see where identity systems have been and why each generation solved one problem while introducing another.

Centralized Identity (LDAP, Active Directory)

In a centralized model, a single authority owns and manages all identities. Microsoft Active Directory is the classic example: every user, every service account, every permission lives in one directory. To determine “is Agent X allowed to do Y?” you query the directory.

This works inside one organization. It creates a single point of failure. If the directory is down, nothing authenticates. If it is compromised, an attacker controls every identity. For multi-agent AI, centralized identity does not work across organizational boundaries. Your LDAP server cannot vouch for an agent running in someone else’s infrastructure.

Federated Identity (SAML, OAuth/OIDC)

Federation addresses cross-organization trust. Instead of one authority, multiple Identity Providers (IdPs) agree to trust each other. SAML and OAuth/OIDC enable “log in with Google” or accept tokens from a partner’s IdP.

Federation reduces single-point-of-failure risk but introduces structural dependencies. You need pre-negotiated trust relationships between IdPs. Token verification requires a round-trip to the issuer (or access to a JWKS endpoint). Setting up federation across many parties is operationally heavy.

Decentralized Identity (DIDs + Verifiable Credentials)

Decentralized identity removes the central authority entirely. Each entity creates its own identity (a DID backed by a cryptographic key pair) and carries its own credentials. Verification happens locally. The verifier checks a cryptographic signature, not a database.

The benefit of Decentralized identity is that there is no single point of failure, No pre-negotiated trust relationships and No issuer callback at verification time. All the verification is handled cryptographically.

Components of Decentralized Identity

A decentralized identity system has four core components.

1. Decentralized Identifier (DID) is a globally unique string like did:web:example.com:flight that the agent owns. The did:web method means “resolve this DID by fetching a document over HTTPS.” Other methods exist (did:key, did:ion, did:ethr) but did:web is the simplest for production web services.

2. DID Document is a JSON document published at the URL derived from the DID. It contains the agent’s public key, what that key can be used for (authentication, signing credentials), and service endpoints (where to reach the agent). Anyone who resolves the DID gets this document.

3. Verifiable Credential (VC) is a signed assertion from an issuer about a subject. “The Orchestrator certifies that Flight Agent has the capabilities: flight_search, flight_booking.” The credential is portable. The agent holds it and presents it on demand. The verifier checks the issuer’s signature without contacting the issuer.

4. Revocation List is a list of credential IDs that are no longer valid. The verifier checks this list during authorization. If the credential ID appears, the agent is rejected, even if the signature is perfect and the credential has not expired.

How the Trust Chain Works

When the Orchestrator needs to delegate a task to the Flight Agent, it runs a 5-step trust chain. Each step builds on the previous one. Failure at any step means the task is never sent.

Step 1, Discovery: The Orchestrator fetches the Flight Agent’s Agent Card (a JSON file at a well-known URL). The card states: “I am Flight Agent, I can search flights, my DID is did:web:example.com:flight.”

Step 2, Resolution: The Orchestrator resolves the DID. It converts did:web:example.com:flight into https://example.com/flight/did.json, fetches the document, and extracts the public key and service endpoints.

Step 3, Authentication: The Orchestrator sends a random 32-byte nonce to the Flight Agent: “sign this.” The Flight Agent signs it with its private key. The Orchestrator verifies the signature using the public key from the DID Document. If it verifies, the agent provably holds the private key. It is who it claims to be.

Step 4, Authorization: The Orchestrator fetches the Flight Agent’s Verifiable Credential and runs four checks locally: (1) Is the signature from the claimed issuer? (2) Has it expired? (3) Is it on the revocation list? (4) Does it grant the needed capability? All four checks must pass.

Step 5, Delegation: Only after all checks pass does the task flow. The agent has been discovered, identified, authenticated, and authorized. The Orchestrator sends the task.

The full chain completes in under 200ms. Five HTTP requests. Zero central databases.

Use Cases This Solves

Cross-organization agent collaboration. Agents from different companies verify each other without a shared authority. Each agent’s DID is self-sovereign.

Instant revocation without key rotation. A compromised agent is cut off by adding one credential ID to a revocation list. No restart, no config changes, no cascading updates across services.

Least-privilege enforcement. Credentials explicitly list granted capabilities. An agent authorized for flight_search cannot perform flight_booking unless its credential grants that capability.

Replay attack prevention. Every authentication uses a fresh 32-byte random nonce. A captured response is useless for future challenges.

Decentralized verification. Verifiers resolve DIDs and check credential signatures locally. No round-trip to an issuer or central authority at verification time.

Auditable trust decisions. Every step (discovery, resolution, authentication, authorization) produces a verifiable artifact. You can reconstruct exactly why an agent was trusted or rejected.

Graceful credential rotation. Credentials expire (for example, after 30 days). New ones are issued without downtime. Old ones naturally stop working.

Try It Yourself

The prototype uses three Flask servers (orchestrator, flight agent, hotel agent) with Ed25519 cryptography via PyNaCl. The code is available at github.com/r2rajan/did-vc under the sample1 directory.

Setup:

git clone https://github.com/r2rajan/did-vc.git
cd did-vc/sample1
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

What Is Next: Part 2, From Flask to AWS

The trust primitives stay the same. The deployment changes into minimum viable product (mvp) to deploy in AWS cloud.

• Flask becomes Lambda (serverless)
• localhost becomes API Gateway + CloudFront (HTTPS, global)
• Files on disk become DynamoDB + Secrets Manager (encrypted, managed)
• Hardcoded responses become Amazon Bedrock (LLM-powered agent reasoning)

The identity layer is independent of the infrastructure layer. That is the value of building on standards.

Part 1 of a two-part series. Part 2 deploys the system to AWS with Lambda, Bedrock, and use real time agents, LLMs and an UI.