Agent identity inside a single organization is a solved problem in principle: your identity provider issues credentials, your services validate them, and the trust anchor is shared by everyone involved. It is work, but there is no conceptual gap.
The gap appears when agents interact across organizational boundaries. Your agent receives a task request from an agent claiming to belong to a partner company. There is no shared identity provider. The claim arrives as a string in a payload. What makes it more than a string?
This is the problem decentralized identifiers and verifiable credentials address, and it is becoming load-bearing as agent-to-agent protocols move from demos into production.
Why Bearer Names Fail Across Boundaries
An agent asserting agent-42@partner.example is asserting a name. Three questions follow, and none of them are answered by the name:
Is this really that agent? Without cryptographic proof, anyone who knows the identifier can claim it. Identifiers appear in logs, in messages, in documentation. Knowledge of an identifier must not constitute proof of it.
Who vouches for it? Even proven control of an identifier says nothing about what organization stands behind it, whether that organization is who they claim, or what the agent is authorized to do.
Is it still valid? Agents get retired, compromised, and revoked. An identifier that was legitimate last month may be actively hostile now, and a counterparty needs a way to find out.
Federating traditional identity across every counterparty is theoretically possible and practically unworkable: it requires bilateral trust configuration between every pair of participants, which scales quadratically and breaks whenever a new partner appears.
What a DID Actually Gives You
A decentralized identifier is a URI that resolves — via a method-specific mechanism — to a DID document containing public keys and service endpoints. The important property: control of the identifier is demonstrated by producing a signature verifiable against a key in the document.
So the interaction changes shape. Instead of "I am agent-42," it becomes "I am did:web:partner.example:agents:42, and here is a signature over this request." The verifier resolves the DID, obtains the public key, checks the signature. Now impersonation requires the private key, not knowledge of the name.
Several DID methods exist with different trade-offs. did:web anchors to a domain and resolves over HTTPS — no distributed ledger, immediately deployable, and its trust derives from control of the domain, which is exactly the property most organizations already establish. That makes it the pragmatic default for cross-organization agent identity. Ledger-anchored methods provide stronger tamper-evidence and independence from DNS at the cost of operational complexity, and did:key embeds the key directly for ephemeral use where no resolution or rotation is needed.
For how this fits the broader identity taxonomy, see machine identity vs workload identity vs agent identity and AI agent identity: why agents need credentials.
Verifiable Credentials: Attestations Worth Checking
A DID proves control of an identifier. It says nothing about attributes. Verifiable credentials fill that gap: signed statements by an issuer about a subject, presented by the holder and independently verifiable by anyone who trusts the issuer.
Useful attestations for agents:
- Ownership. This organization operates this agent — signed by the organization's own DID.
- Capability. This agent is authorized to perform these task types up to these limits.
- Compliance. This agent's deployment has been assessed against a framework, issued by an auditor.
- Provenance. This agent runs a specific model version and configuration, with a signed build attestation.
- Behavioral history. Aggregate performance or reliability signal, issued by a platform that observed it.
The verifier's decision then rests on issuer trust rather than subject trust — a familiar model from certificate authorities, applied to attributes rather than to names. And selective disclosure allows a holder to prove one attribute without revealing the whole credential, which matters when the attestation contains commercially sensitive detail.
See trust scores and attestations for agents and cross-org agent federation and trust manifests.
Where Spoofing Actually Gets In
The cryptography is not usually where implementations fail. These are:
Unvalidated signatures. Systems that parse the DID from a message and use it for authorization without verifying the signature at all. Surprisingly common in early implementations, because the identifier is right there in the payload and the code works in testing.
Resolution poisoning. For did:web, resolution is an HTTPS fetch. If certificate validation is lax, or the resolver follows redirects to an attacker-controlled host, or DNS is compromised, the attacker supplies the key. Pin what you can, validate certificates strictly, and refuse to follow cross-origin redirects during resolution.
Stale caches. Resolution is expensive so documents get cached. Cache too long and a rotated or revoked key remains accepted. Cache too briefly and resolution becomes a hot dependency and a denial-of-service vector. Cache with a short TTL, revalidate on signature failure before rejecting, and always check revocation separately from resolution.
Key rotation confusion. When an agent rotates keys, both old and new may be valid briefly. Implementations that accept any key ever seen for a DID accept a compromised key forever. Honor the key's status in the current document and enforce the overlap window explicitly.
Missing revocation checks. A credential can be valid-by-signature and revoked in fact. Status list checking is the step most often omitted because it requires another fetch and works fine in testing. Fail closed when status cannot be determined for high-value operations.
Confusing identity with authorization. A verified DID tells you who is calling, not what they may do. Authorization is a separate decision against your own policy, and treating a strong identity as an authorization grant is the same category of error as trusting a role because the login succeeded. See how to authenticate AI agents.
Replay. A validly signed request captured and replayed remains validly signed. Bind signatures to a nonce, a timestamp, and the specific request content, and track nonces for the acceptance window.
Deploying This Incrementally
You do not need to rebuild internal identity. The sequence that works:
- Internal first, unchanged. Keep your identity provider and short-lived tokens for internal agent-to-service calls. DIDs add nothing where a shared trust anchor already exists.
- DIDs at the boundary. Assign each externally-visible agent a DID, publish DID documents, and require signed requests on cross-organization interactions. Map the verified external DID to an internal principal at the boundary, then use ordinary internal authorization from there.
- Ownership credentials. Issue and require organization-ownership attestations so a verified DID also carries a verified operator.
- Capability and compliance credentials. Add attestations where counterparties need them, driven by actual partner requirements rather than speculatively.
- Feed reputation. Once identity is verifiable, behavioral history can be attached to something that cannot be cheaply discarded — which is the precondition for reputation being meaningful at all. See public agent reputation and k-anonymity.
That ordering keeps the work proportional: the boundary is where the problem is, and the boundary is a small fraction of your agent traffic.
Common questions
Is did:web secure enough given it depends on DNS and TLS?
For most commercial agent interactions, yes — it inherits exactly the trust model that already underpins your API integrations and your partners' identity assertions. If DNS and TLS for partner.example are compromised, you have a much larger problem than agent identity. Ledger-anchored methods remove that dependency and are worth the operational cost where the counterparty relationship is adversarial or the stakes justify it, but starting with did:web gets verification deployed rather than deferred.
Do I need a blockchain for this?
No. did:web requires an HTTPS endpoint. Verifiable credentials require a signing key and a status endpoint. Neither needs a distributed ledger. Ledgers offer tamper-evident history and issuer independence — genuinely valuable in open ecosystems with no established relationships, largely unnecessary between organizations that already have contracts.
How does this relate to mTLS, which we already have?
They solve overlapping problems at different layers. mTLS authenticates the transport connection between two workloads, which is excellent inside a mesh and awkward across organizations where certificate distribution and revocation must be coordinated bilaterally. DIDs authenticate the message and the logical agent identity, survive proxies and store-and-forward hops, and resolve without pre-shared configuration. Use mTLS internally where it already works, and DID-signed messages at boundaries and for anything asynchronous. See mTLS, SPIFFE, and workload identity for agents.
What if a partner's agent is compromised?
That is the case revocation exists for: the partner revokes the DID or the ownership credential, and your next status check rejects it. Which is why status checking and short cache TTLs are not optional details — they are the entire difference between a revocation that takes effect and one that does not. Complement it with your own trust scoring, so a counterparty exhibiting anomalous behavior loses access before a formal revocation arrives.
How Praesidia approaches verified agent identity
Praesidia gives each agent a DID-based identity and verifies signed interactions at the boundary, mapping a verified external identity to an internal principal before authorization is evaluated. Which external organizations and agents are recognized is an explicit policy decision, and cross-organization dispatch is governed by that policy rather than by the identity claim alone.
Reputation and trust signal is attached to the verified identity, and connections can require a minimum trust level — so identity, attestation, and behavioral history compose into one authorization decision that is recorded with the acting agent, the asserted principal, and the policy outcome. See securely sharing AI agents across orgs and the Praesidia documentation.