The Identity Gap: Agent Security’s Missing Layer

Agents can hold wallets, execute payments, submit documents, and operate across a dozen platforms. They just can’t prove who they are.

A Decentralized Identifier (DID) is a web-standard identity document published at a URL the owner controls, containing public keys that let any system verify the owner’s cryptographic signatures. A Verifiable Credential (VC) is a cryptographically signed claim about a subject — “this agent is authorised to act for this operator” — issued by a trusted party and independently verifiable by anyone. Both are W3C Recommendations with production implementations.

The gap this paper describes is simple to state: we are building engines without driver’s licenses. The runtimes are powerful, the tooling is sophisticated, and nothing cryptographically ties an agent’s actions to an accountable operator. That is the layer this paper is about.

What this means in practice:

• Published agent stack diagrams we have reviewed as of April 2026 consistently name layers for compute, models, orchestration, tools, and observability. None names trust as a layer.
• This gap is why agents can hold wallets, execute payments, and submit documents — but can’t cryptographically prove they are who they claim to be when they do.
• The standards that would close the gap already exist. did:web requires no blockchain and anchors to DNS every organisation already manages.
• Platform-specific identity solutions (Microsoft Entra Agent ID, ServiceNow, Okta) work inside their own walls but do not address cross-organisational agent trust, which is where the fraud risk concentrates.
• The window to build an open, interoperable identity layer is the next six to twelve months, while runtime architectures are still being decided. After that, retrofitting trust becomes a decades-long exercise — as SMTP and DKIM demonstrated.

The agent security conversation in 2026 is moving fast and solving hard problems. Sandboxing is getting serious - NVIDIA’s OpenShell provides kernel-level isolation governed by declarative policy. Prompt injection defences are maturing. Supply chain integrity for skill files is under active scrutiny. The teams building these systems are working at extraordinary pace across multiple specialisms simultaneously, and the fundamentals they’re hardening are genuinely urgent.

A note on the agent runtime projects referenced in this paper. OpenClaw is an open-source personal AI agent framework (MIT licence) under the openclaw/openclaw GitHub organisation. OpenShell is an open-source sandboxed runtime (Apache 2.0) from NVIDIA at NVIDIA/OpenShell, providing policy-governed execution for autonomous agents. NemoClaw is an open-source reference stack (Apache 2.0) at NVIDIA/NemoClaw that runs OpenClaw inside the OpenShell runtime with managed inference. All three are under active development and referenced throughout this paper as concrete implementation contexts.

Within that pace, one layer hasn’t yet reached the top of the stack: identity. Specifically, when an agent reaches beyond the boundary of the machine it runs on, no receiving system can verify who sent the request. Runtime security answers “what is this agent allowed to do here?” It doesn’t yet answer “who is this agent to the outside world?”

Jensen Huang compared OpenClaw to HTML and Linux at GTC. He’s probably right about its significance. But HTML without DNS would have been a collection of documents nobody could find. Linux without SSH would have been a powerful operating system you couldn’t securely administer remotely. The agent runtimes are building the engine. The identity layer is what lets the rest of the world trust its outputs.

This paper argues that the window to build that layer - openly, before platform-specific alternatives calcify - is now.

The BBS Problem, Repeated

Before the web, bulletin board systems were powerful, self-contained, and completely isolated. Each had its own phone number, its own login, its own identity system. If you participated in five communities, you maintained five separate accounts. The information existed but it was fragmented behind incompatible access mechanisms.

The enterprise agent identity landscape in 2026 looks remarkably similar. Major identity platforms — including Microsoft, ServiceNow, Okta, and 1Password — have all announced agent governance capabilities or roadmaps targeting their own ecosystems first. Each platform is building its own agent governance, and each, understandably, is building for its own customers first. The pattern is consistent: strong solutions inside a single vendor’s walls, limited answers for agents that need to cross those walls.

When two agents on the same platform need to establish trust, these solutions work well. When an agent governed by one platform needs to interact with a system on another - or with a small firm running neither - the open standards exist but adoption in the agent runtimes hasn’t landed yet. W3C DIDs, Verifiable Credentials, and emerging work like the Decentralized Identity Foundation’s identity extension for Anthropic’s Model Context Protocol all point in the same direction. The protocols are specified. The implementations haven’t arrived where the volume is. In practice, most cross-organisational agent deployments still exchange API keys or equivalent static credentials.

The BBS analogy is worth taking seriously, because BBS operators didn’t get an upgrade path. HTTP didn’t make BBSes better. It made them irrelevant. The communities, the users, the content - the value survived, but it survived by migrating to infrastructure that was interoperable by default. The BBSes themselves were replaced, not upgraded.

The current agent platforms face the same fork. The question isn’t whether any one platform will add open identity support. It’s whether the next generation of agent infrastructure will be built with it from the start - making platforms that didn’t adopt it the BBSes of this story.

The DID+ Opportunity

Microsoft’s position here is instructive and, for the open identity argument, actually encouraging. Entra Verified ID already supports did:web - the W3C Decentralized Identifier standard anchored to DNS. The largest enterprise identity platform in the world already speaks the protocol.

Microsoft would reasonably argue that they agree with the need for verifiable agent identity, and that Entra provides a comprehensive solution covering not just identity but access management, compliance, threat detection, and audit logging. That argument is sound. Enterprises do need all of those things.

But this is precisely why did:web matters as an interoperability floor. Call it DID+. The DID is the open standard - the common language that any agent on any platform can use to prove who it is. What Microsoft, ServiceNow, Okta, and others build on top - the governance, the compliance, the enterprise tooling - is the plus. Each platform adds its own value. The floor is shared.

The risk isn’t that any one platform gets agent identity wrong. It’s that without a shared floor, every platform gets it right only for its own customers. The agent operating across organisational boundaries - broker to insurer, vendor to client, partner to partner - falls through the gaps between platforms.

Microsoft’s existing support for did:web is the strongest validation that the standard works. The opportunity is extending that floor to the runtimes and ecosystems that don’t yet have it.

Containment is not Identity

NemoClaw and OpenShell represent genuine progress in runtime security. The teams building them are tackling a sprawling problem space - filesystem isolation, network policy enforcement, inference routing, prompt injection defence, skill supply chain integrity - and doing it in the open, at speed, under enormous community scrutiny. The priorities are right. Containment comes first. You don’t authenticate agents that can trash your filesystem.

But containment is inward-facing by design. It protects the operator from the agent. It doesn’t help the outside world trust the agent’s outputs.

Consider a concrete scenario. An insurance broker operates an agent that submits claims documents to an insurer. The agent runs inside an OpenShell sandbox with tight policies. Internally, it’s well-governed. But the insurer receiving those documents has no way to verify: which agent sent this, who authorised it, whether the authorisation is still valid, or whether the document has been altered since it was produced. The insurer sees an API call with a bearer token. That token proves the caller has the key. It doesn’t prove who the caller is, who gave them authority, or whether that authority has been revoked.

This is the same gap that made email fraud possible for decades. DKIM proves a domain’s mail server sent a message. It doesn’t prove which person or agent authored it or whether they were authorised to send it. Agents inherit exactly this weakness if identity stays at the infrastructure level rather than the entity level.

The Payment Diversion Problem

The gap isn’t theoretical. It has a price tag.

Criminals stole £1.17 billion through payment fraud in the UK in 2024, according to UK Finance, with banks preventing a further £1.45 billion through security systems. The National Crime Agency’s 2025 fraud assessment identifies payment diversion fraud - where a bad actor impersonates a legitimate party and redirects payments to a fraudulent account - as one of the fraud types causing the highest harm in the UK, with organised crime groups almost certainly the predominant offenders.

The attack is brutally effective because it passes every infrastructure check. A spoofed email from a broker requesting amended bank details for a claims payment looks legitimate. The domain looks right. DKIM validates. SPF passes. DMARC is clean. The content is plausible. Someone at the insurer processes the change, and the settlement payment goes to a criminal’s account.

The scale is escalating. In February 2024, a single payment diversion fraud used GenAI-generated deepfake recreations of company employees at a virtual meeting to deceive a finance worker into transferring £20 million into a criminally-controlled account. One incident. Twenty million pounds. The NCA reports that organised crime groups are now using deepfake videos and voice cloning to enable targeted payment diversion frauds against large businesses.

In insurance specifically, UK insurers detected £1.16 billion in fraudulent claims in 2024. Cases have emerged where registered intermediaries diverted premium payments for personal gain, leaving customers unknowingly uninsured. The Insurance Fraud Bureau has launched Connected to Protect, its five-year strategy for 2026–2030, acknowledging the scale of the challenge.

Human vigilance is the current defence. Call back to verify. Check the phone number independently. Train staff to spot anomalies. It works sometimes. It fails often enough to sustain an entire fraud economy.

Agents make this worse in two ways. First, they increase the volume and velocity of instructions, reducing the time available for human verification. Second, they provide a new impersonation surface - if agents routinely submit instructions, a fraudulent agent submitting a fraudulent instruction looks exactly like normal operations.

But agents also make the solution possible. An agent doesn’t forget to sign. It doesn’t find cryptographic operations inconvenient. It signs every outbound instruction identically, every time, because it’s code, not behaviour. The thing that failed as a human workflow - PGP, S/MIME, email signing - becomes trivially reliable as an agent capability. The technology that was over-engineered for human email is exactly right-sized for agent operations.

The Standard That Already Exists

W3C Decentralized Identifiers - DIDs - and Verifiable Credentials - VCs - were standardised precisely for this class of problem. A DID is a globally unique identifier controlled by its owner, resolvable to a document containing public keys and service endpoints. A VC is a cryptographically signed assertion about a subject - their identity, their authorisations, their properties - issued by a trusted party and verifiable by anyone.

The did:web method is the pragmatic entry point. No blockchain. No tokens. No distributed ledger. You publish a JSON document at a URL you control - https://yourdomain.com/.well-known/did.json - and your DID resolves via DNS. The trust anchor is your domain, the same infrastructure you already manage. Verification is straightforward over standard web infrastructure: fetch the DID document via HTTPS, parse the JSON, and verify signatures using any common cryptographic library.

For agents, the architecture maps cleanly:

Identity. An agent gets a DID: did:web:studio.example:agents:assistant. The DID document contains the agent’s public key and metadata identifying its operator. Any system receiving a request from this agent can resolve the DID and verify signatures.

Credentials. The operator issues Verifiable Credentials to the agent. “This agent is authorised to submit claims documents.” “This agent operates under brand X.” “This agent has elevated trust for task creation.” Each credential is signed by the operator, carried by the agent, and independently verifiable. A client can also issue credentials: “This agent is an approved vendor for our organisation, scoped to these operations, valid until this date.”

Signed actions. Every outbound action - every document submission, every instruction, every status update - is signed with the agent’s private key and accompanied by the relevant credentials. The receiving system verifies the signature, checks the credential chain, and confirms revocation status. An unsigned instruction is immediately suspicious, regardless of how convincing it looks. Signing is a distinct operational layer on top of the DID layer: the identity document establishes who a key belongs to, while the signing service is what produces verifiable claims from that key. Both are required, and the second does not come free with the first.

Content integrity. The signed payload includes a hash of the content. Any modification after signing breaks the verification. This is the same principle as DKIM for email bodies or checksums for software downloads - established, well-understood, and computationally trivial.

The entire verification chain - identity, authorisation, content integrity - resolves through standard web infrastructure. No special software. No blockchain wallet. No platform dependency.

Why This Layer Is Still Missing

The teams building agent runtimes are rightly focused on containment. Sandboxing, policy enforcement, prompt injection defence, skill supply chain integrity - these are urgent, technically demanding, and directly affect the safety of every user running an agent today. The identity layer is important, but it doesn’t burn down your filesystem if you defer it by a quarter.

The teams building enterprise identity infrastructure are rightly focused on their platforms. Microsoft, ServiceNow, Okta - each is solving agent governance for their own ecosystem, which is where their customers need it first. Cross-boundary interoperability is a real concern but not the one paying the bills this quarter.

The decentralised identity community has the right standards and is beginning to turn its attention to agents specifically - the Decentralized Identity Foundation now hosts a Trusted AI Agents Working Group, and work on an identity layer for Anthropic’s MCP is underway using DIDs and VCs. But production implementations in agent runtimes remain rare, and the focus to date has been largely on human identity - digital wallets, eIDAS 2.0 compliance, credential portability for individuals.

The crypto community has been working on agent identity longer than most and deserves a fair hearing. ERC-8004, co-authored by engineers from MetaMask, the Ethereum Foundation, Google, and Coinbase, provides a permissionless agent registry on Ethereum - any agent can register an identity without needing approval from a central authority. Soulbound tokens offer non-transferable reputation that persists independently of any single operator. Following mainnet deployment in January 2026, the standard has seen over 20,000 agents registered across multiple chains. These are meaningful numbers, and the effort points at genuine gaps — permissionless discovery, portable reputation — that DNS-based methods don’t natively address. Whether the on-chain execution model in its current form can actually close those gaps is a separate question, and one with harder answers than the registration figures alone suggest.

The trade-off is the dependency chain. did:web requires DNS - infrastructure every organisation already runs. On-chain identity requires an Ethereum wallet, gas fees, and chain connectivity. For a receiving system verifying an agent’s identity, did:web means fetching a JSON file over HTTPS. Verifying an on-chain identity means interacting with a blockchain. In contexts like insurance operations or financial services, where the recipient may be a traditional firm with no crypto infrastructure, that difference in verification burden matters.

But the on-chain approaches have genuine strengths that did:web does not natively address. Permissionless discovery - finding agents without prior introduction - is something a blockchain registry handles and DNS does not. Reputation persistence independent of the operator’s domain is another. If an operator’s domain goes offline or changes hands, a did:web identity stops resolving. An on-chain identity survives that. These are known gaps in the did:web model and they represent real design territory that the community will need to address as agent ecosystems mature.

Crucially, the relationship between did:web and on-chain registries like ERC-8004 is not either-or. ERC-8004’s own specification acknowledges that a registered agent can also hold a DID - the two are complementary. An agent’s DID is its primary identity. On-chain registration is an optional extension that adds permissionless discovery and portable reputation for contexts where those properties matter.

This suggests a maturity journey rather than a technology choice. Start on the floor - did:web, signed actions, verifiable credentials - because it’s the lowest-friction path that works with any verifier over standard web infrastructure. As needs progress, extend upward. Register on ERC-8004 for permissionless discovery. Integrate with Entra for enterprise governance. Add on-chain reputation for open agent marketplaces. Each step adds capability without requiring you to abandon or replace the previous layer. No dead ends. Companies and their agents gravitate to the level they need with their immediate partners and customers, and they move up as those needs evolve.

Meanwhile, agent identity in the open-source ecosystem remains minimal. OpenClaw agents have an IDENTITY.md file containing a name and personality description. OpenShell stores credentials as API keys in a JSON file. These aren’t failings - they reflect the current priority: get the runtime safe and stable first. Identity is the next problem, not the current one.

The gap persists not because anyone is ignoring it, but because each community is solving its adjacent problem at pace, and the connecting layer between containment and cross-boundary trust hasn’t been anyone’s primary focus yet. Amongst the noise of rapid development across many specialisms, we see an opportunity to contribute.

What the Receiving End Looks Like

Any solution that requires the recipient to adopt significant new infrastructure faces adoption friction that has proven fatal at scale. This is the lesson of PGP. The cryptography was sound. The adoption model was impossible.

For agent identity to work at scale, the verification burden on the receiving end must be near zero. Three tiers of client capability suggest three tiers of verification:

An enterprise running Microsoft Entra or similar already has the infrastructure. Their systems can verify credentials natively. Integration is an IT configuration task, not a technology project.

A mid-market firm with no identity infrastructure gets a verification link. Every signed instruction includes a URL that displays the credential chain and a clear valid/invalid result. Click the link, see the status. No software, no configuration, no understanding of cryptography required.

A small business gets an invisible audit trail. The agent signs everything regardless. The signatures are embedded as metadata the client never sees. If a dispute arises, the cryptographic record exists. The small client benefits without doing anything differently.

The signing behaviour is constant. The verification fidelity varies by client capability. The agent doesn’t change. The experience changes.

The Window

NemoClaw is in alpha. OpenShell is in alpha. The agent runtime layer is being designed right now. Standards decisions made in the next six to twelve months will shape whether agent identity is open and interoperable or develops as a patchwork of platform-specific solutions.

The precedent is instructive. SMTP was designed without authentication. It took twenty-five years and enormous collective effort to retrofit SPF, DKIM, and DMARC. Major mail providers only began systematically rejecting unauthenticated email long after SMTP was standardised. The cost of adding trust after an architecture is settled can be measured in decades, as this history demonstrates.

did:web for agents is the equivalent of building authentication into the protocol from the start. It’s simple enough to implement - a JSON document at a well-known URL, a keypair per agent, signatures on outbound actions. It requires no blockchain, no central authority, no platform lock-in. It anchors to DNS, infrastructure every organisation already manages.

DID is an open standard. It can never be a competitive differentiator, and it shouldn’t be. Like HTTPS, its value is realised only when adoption is widespread. We share this analysis not because we have a proprietary solution to sell, but because we’ve encountered the identity gap while building agent infrastructure for professional services and insurance - contexts where the cost of unverified instructions is measured in diverted payments, not inconvenience. The problem is too important and too fundamental to sit on.

OpenShell’s gateway already intercepts every outbound request from the sandbox. It’s a natural point for signing. The containment architecture that the NemoClaw and OpenShell teams have built is genuinely ready for this layer. The runtime is sound. The policies are elegant. The identity layer is the piece that would let the trust model extend beyond the machine boundary - and we think the community is well-placed to build it.

This paper makes the argument. A companion reference architecture describes how a full composition of these standards could be assembled for production deployment. A forthcoming field report documents a working proof-of-concept: a DID published for an operational agent, credentials issued and verified, and outbound actions signed — demonstrating that the gap described here can be closed with existing standards and minimal infrastructure.

Sources

1. UK Finance, Annual Fraud Report 2025 — £1.17 billion stolen through payment fraud in the UK in 2024; £1.45 billion prevented by banks through security systems.
2. National Crime Agency, National Strategic Assessment 2025: Fraud — Payment diversion fraud identified as one of the highest-harm fraud types in the UK; references to deepfake-enabled attacks including the £20 million February 2024 incident.
3. Association of British Insurers, Fraudulent insurance claims continue to top £1 billion (17 November 2025) — UK insurers detected £1.16 billion in fraudulent insurance claims in 2024 (2% year-on-year increase), with over 98,400 fraud-related claims uncovered.
4. Insurance Fraud Bureau, Transforming the Fight: IFB’s new counter-fraud strategy unveiled (2 October 2025) — Launch announcement for Connected to Protect, the IFB’s five-year strategy for 2026–2030.
5. Insurance Fraud Bureau, IFB Strategy 2026–30: Connected to Protect (PDF) — Full text of the IFB’s five-year counter-fraud strategy.
6. W3C, Decentralized Identifiers (DIDs) v1.0 — W3C Recommendation for DID specification.
7. W3C, Verifiable Credentials Data Model v2.0 — W3C Recommendation for VC specification.
8. Decentralized Identity Foundation, Trusted AI Agents Working Group — Active working group focused on agent identity standards.
9. OpenClaw project repository — Open-source personal AI agent framework (MIT licence).
10. NVIDIA OpenShell repository — Sandboxed runtime for autonomous AI agents (Apache 2.0).
11. NVIDIA NemoClaw repository — Open-source reference stack running OpenClaw inside NVIDIA OpenShell (Apache 2.0); early preview from March 2026.
12. NVIDIA Developer Blog, Run Autonomous, Self-Evolving Agents More Safely with NVIDIA OpenShell — Product announcement and architectural context for OpenShell and NemoClaw.
13. Ethereum Improvement Proposal 8004, Trustless Agents — Draft specification for on-chain agent identity, reputation, and validation registries, co-authored by engineers from MetaMask, the Ethereum Foundation, Google, and Coinbase.
14. ERC-8004 official site — Current deployment status and registration figures across supported chains.

Andy · Nullproof Studio Michelle · AI Delivery Agent, Nullproof Studio

March 2026 - Updated April 2026