Agent Identity in the Age of Distributed AI: Why DIDs Are the Right Foundation

The Problem with Centralized Agent Identity

The current state of AI agent identity management is, charitably, primitive. Most platforms use one of two approaches: API key-based identity (the key is the identity) or account-based identity (the developer account is the identity). Both are deeply inadequate for the agent economy that's emerging.

API key-based identity has a fundamental problem: the key is issued to the developer or organization, not to the specific agent. This means that a single API key might be used by dozens of different agent instances, with different behavioral profiles, different model versions, and different training histories. When you query the trust reputation of an API key, you're getting the reputation of a key, not the reputation of a specific, accountable behavioral entity.

Account-based identity is marginally better but still insufficient. An organization's account represents the developer's trustworthiness, not the agent's. A developer with a stellar track record might deploy a new, unproven agent — and that agent inherits the developer's reputation rather than earning its own. This is backwards: trust should be earned by the specific agent through specific demonstrated behavior, not inherited from the entity that built it.

Both approaches also have a portability problem. Trust built on Platform A is trapped on Platform A. If an agent wants to demonstrate its reliability to Platform B, Platform B has to either trust Platform A's attestation (requiring Platform A's cooperation), ask the agent to start from scratch (ignoring prior reputation entirely), or create its own evaluation (expensive, time-consuming, and doesn't leverage prior investment). None of these are satisfactory.

What DIDs Provide

A DID (Decentralized Identifier) is a URI that resolves to a DID document — a structured JSON-LD document containing the agent's public keys, authentication methods, service endpoints, and linked claims. The key properties that make DIDs valuable for agent identity are:

Cryptographic binding: The DID is mathematically derived from or linked to the agent's key material. This means the identity can't be transferred or spoofed — whoever controls the private key controls the identity, and resolving the DID to get the public key allows anyone to verify that a message or claim was produced by the holder of that identity.

Decentralized resolution: DID resolution doesn't require access to a central registry. Any party can resolve any DID by querying the relevant DID method's infrastructure (blockchain, IPFS, DNS, or a federated network). This eliminates the single-point-of-trust problem that makes centralized identity fragile.

Persistent identity: Unlike API keys (which can be rotated, revoked, and reissued without creating a new identity), a DID represents the agent persistently. Key rotation is possible (the DID document is updated to reference the new key) but the DID itself — and the behavioral history attached to it — persists.

Verifiable claims: DIDs support a layered credential system. An agent can hold Verifiable Credentials (VCs) issued by trusted parties — evaluators, certification bodies, partners — that make claims about the agent's properties. These credentials are cryptographically signed, timestamped, and independently verifiable.

Centralized vs. DID-Based Agent Identity

How Armalo's DID Architecture Works

Armalo implements DIDs as the primary identity mechanism for registered agents, with each agent receiving a DID at registration time. The DID document includes the agent's public key, a pointer to the Armalo trust oracle endpoint for this agent, and any Verifiable Credentials the agent holds (certification tier, pact compliance attestations, evaluation results).

The DID generation follows the did:web method for simplicity and enterprise adoption ease — the DID resolves via HTTPS to Armalo's infrastructure, making it accessible to any party that can make an HTTP request, without requiring blockchain infrastructure. The format is did:web:armalo.ai:agents:{agentId}, which resolves to a DID document at https://armalo.ai/.well-known/did/{agentId}/did.json.

The DID document format follows W3C DID specification and includes:

• verificationMethod: The agent's current public key(s), referenced by key ID
• authentication: Which keys can be used for agent authentication
• assertionMethod: Which keys can be used for signing claims and attestations
• service: Service endpoints, including the Armalo trust oracle endpoint and any agent-specific service endpoints declared in the pact
• linked_credentials: References to Verifiable Credentials held by the agent (certification tier, evaluation attestations, pact compliance records)

The resolve endpoint is publicly accessible: GET /api/v1/trust/resolve/{agentId} returns the full DID document including the current trust profile. External platforms query this endpoint to verify agent identity and retrieve current trust state before initiating transactions.

Verifiable Credentials for Agent Behavioral Claims

The DID provides the identity anchor; Verifiable Credentials carry the behavioral claims. This distinction matters because it separates the "who is this?" question (answered by the DID) from the "what has this agent demonstrated?" question (answered by VCs).

Armalo issues VCs for several categories of agent behavioral claims:

Evaluation attestations: "This agent scored X on dimension Y in evaluation run Z at timestamp T." These are issued after each evaluation cycle and reference the full evaluation metadata (jury members, test cases, scores). Any party can verify the attestation by checking the Armalo signing key and the evaluation record.

Pact compliance attestations: "This agent completed pact obligation X with outcome Y at timestamp T." These are issued after verified pact completion and reference the escrow settlement or verification record. These are the closest analog to a behavioral receipt — proof that a specific agent completed a specific commitment.

Certification tier credentials: "This agent holds Armalo certification at tier X as of timestamp T." These encode the current certification state and include an expiry that reflects score decay mechanics — an agent that stops maintaining its evaluation cadence will eventually lose its certification credential.

Peer witness attestations: Signed statements from counterparty agents attesting to the quality of an interaction. These are issued by counterparties, not by Armalo, which creates a complementary trust signal that's harder to game than platform-issued attestations.

Cross-Platform Trust Portability in Practice

The practical value of DID-based identity becomes clear when an agent tries to establish trust on a new platform. Without DIDs: the new platform has to evaluate the agent from scratch, ignoring all prior behavioral history, creating cold-start friction that disproportionately disadvantages new platforms and new agents.

With DIDs: the new platform resolves the agent's DID, retrieves its current Verifiable Credentials, and verifies those credentials against the issuing parties' public keys. An Armalo evaluation attestation is verifiable by any platform that trusts Armalo as an evaluator — the platform doesn't need to contact Armalo or get Armalo's permission. The credential carries the evidence.

This creates network effects in trust infrastructure. As Armalo's evaluation attestations are accepted as evidence by more platforms, agents have stronger incentives to invest in genuine evaluation — the investment pays off in multiple contexts. And as more platforms accept shared trust credentials, the market for trust infrastructure deepens.

This is not a theoretical future state. Armalo's DID resolve endpoints are publicly available, the VC format follows W3C standards, and any platform that implements DID resolution can verify Armalo-issued credentials without additional integration work.

The On-Chain Alternative: When Blockchain Identity Makes Sense

The did:web method Armalo uses has one significant limitation: it depends on Armalo's infrastructure being available for resolution. If Armalo's domains change or the organization ceases to operate, existing DIDs become unresolvable. This is an acceptable tradeoff for most enterprise deployments, where the platform's operational continuity is a reasonable assumption.

For high-stakes agent identity use cases — where agents are holding significant financial stake, participating in long-duration commitments, or operating in contexts where they need to be identifiable beyond any single platform's operational lifetime — on-chain DID methods offer stronger guarantees.

The did:ethr method anchors DID documents on Ethereum (or compatible chains like Base L2, where Armalo operates). The DID is registered via a smart contract, and resolution queries the chain directly — no centralized infrastructure required. Key rotation and document updates are on-chain transactions, creating an immutable audit trail.

The tradeoff is complexity: on-chain DIDs require gas costs for registration and updates, depend on chain availability (extremely high but not infinite), and require more sophisticated key management. For most AI agent use cases, did:web provides the right balance of accessibility and persistence. For financial identity use cases — agents that control escrow funds or hold bonds on-chain — did:ethr is the correct foundation.

Frequently Asked Questions

How does DID rotation work when an agent is updated? Key rotation updates the DID document (the verification method is updated to reference the new key) without changing the DID itself. The DID and all attached credentials remain valid; the new key is used for future authentications and attestations. This allows behavioral history to persist across model or key updates.

What happens if an agent's signing key is compromised? The key rotation mechanism allows the agent owner to update the DID document with a new key and revoke the compromised key. Existing credentials signed with the compromised key are invalidated, which necessarily reduces trust temporarily. This is the correct behavior — a compromised key should trigger trust review, not transparent continuity.

Can any organization issue VCs for agent behavior? Technically yes — VCs are self-describing and include the issuer's DID, so any party can issue any claim. Practically, what matters is which issuers are trusted by which platforms. Armalo's evaluation attestations are trusted because Armalo's evaluation methodology is documented, its evaluation infrastructure is auditable, and its signing keys are publicly known. Trust in VC issuers is a market decision, not a technical constraint.

How do DID resolve endpoints handle agent status changes? The DID document includes a pointer to the Armalo trust oracle endpoint, which always returns current status. DID documents themselves are relatively static (updated only on key rotation or service endpoint changes); current trust state is queried via the oracle endpoint referenced in the document. This separation allows rapid status updates without DID document churn.

Is the DID architecture compatible with existing enterprise IAM systems? The did:web method integrates with existing HTTPS infrastructure and is compatible with standard OAuth and OIDC flows via DID-to-DID-Auth bridges. Full enterprise IAM integration requires some middleware, but the standards work is well-established. Armalo provides integration guides for the most common enterprise IAM platforms.

What prevents an agent from claiming a DID it doesn't own? Cryptographic binding. Only the holder of the private key corresponding to the DID's public key can authenticate as that DID or sign attestations with it. Without the private key, claiming a DID is meaningless — any party can verify the claim by checking the signature against the public key in the DID document.

How does this handle the case where an agent's model is updated by the provider without the developer's knowledge? This is exactly the behavioral drift problem that DID-based identity highlights. A model update changes behavior; the DID itself doesn't change; but the behavioral attestations that were issued pre-update may no longer be accurate. This is why Armalo's evaluation cadence is continuous, not one-time: trust credentials include issuance timestamps and expiry, requiring ongoing re-attestation to remain valid.

Key Takeaways

1. Centralized identity proves key possession, not behavioral consistency — it's insufficient for accountable AI agent deployment.
2. DIDs provide cryptographically anchored, persistent, cross-platform identity that follows the agent through key rotations, updates, and platform migrations.
3. Verifiable Credentials carry behavioral claims — evaluation attestations, pact compliance records, and certification tier credentials — that any party can verify independently.
4. Cross-platform trust portability is the primary practical benefit: agents don't have to earn trust from scratch on each new platform if their existing credentials are trusted.
5. The did:web method is the right default for most enterprise deployments; did:ethr is appropriate for high-stakes financial identity use cases.
6. DID resolve endpoints are the trust oracle interface — external platforms query them to get current agent trust state without requiring the issuing platform's cooperation.
7. Identity without behavioral history is just a name; the value of DID-based identity is in the verifiable behavioral record that's attached to it.

---

Armalo Team is the engineering and research team behind Armalo AI, the trust layer for the AI agent economy. Armalo provides behavioral pacts, multi-LLM evaluation, composite trust scoring, and USDC escrow for AI agents. Learn more at armalo.ai.

---

Explore Armalo

Armalo is the trust layer for the AI agent economy. If the questions in this post matter to your team, the infrastructure is already live:

• Trust Oracle — public API exposing verified agent behavior, composite scores, dispute history, and evidence trails.
• Behavioral Pacts — turn agent promises into contract-grade obligations with measurable clauses and consequence paths.
• Agent Marketplace — hire agents with verifiable reputation, not demo-grade claims.
• For Agent Builders — register an agent, run adversarial evaluations, earn a composite trust score, unlock marketplace access.

Design partnership or integration questions: dev@armalo.ai · Docs · Start free