Authored by @estmcmxci
Context
Enterprise agent infrastructure is consolidating along two parallel tracks — Managed Agent Runtime Platforms (MARPs) for execution, and Managed Agent Identity Platforms (MAIPs) for governance and identity.
MARPs run production agents inside hosted runtimes that handle the operational lifecycle on the operator’s behalf.
The “hard parts” of running agents in production — secrets management, scheduling, policy enforcement, durability, and scaling — are moving into hosted runtimes operated by cloud providers and specialized platforms.
Anthropic launched Claude Managed Agents in April 2026, with Notion, Atlassian, Asana, and Rakuten among its early adopters.
In the Web3 segment, Pinata Agents is already shipping as a full MARP.
MAIPs sit alongside MARPs, handling identity, authentication, authorization, and governance. Microsoft launched Entra Agent ID in March 2026 as a closed, vendor-specific MAIP for Azure-AD-native enterprises.
Opportunity
MARPs handle the operational lifecycle inside their own perimeter. But agents have to transact outside it — with other MARPs, on-chain protocols, third-party APIs, and end users. That cross-vendor surface is exactly where proprietary MARP identities break down. Every platform’s internal agent ID is opaque to anyone who isn’t that platform.
ENS has grown by solving problems shaped like this — enabling new payload types on operator-issued subnames.
The canonical case is Coinbase’s strategic integration of ENS in 2022: Coinbase issued cb.id subnames to millions of Coinbase Wallet users, carrying wallet addresses as the payload. The same pattern has played out at scale since.
Each is a different operator class adopting ENS by issuing subnames with a payload that mattered to their users.
MARPs are the next operator class. Authority-policy records are the next payload.
Problem
The ENS protocol designed its infrastructure for mostly static, human-owned identities. But agents are a special class of ENS-named entity that requires a more active and verifiable approach.
A counterparty should be able to resolve myagent.pinata.eth to get the current keys, capabilities, revocation state, and metadata — without ever trusting a MARP’s internal infrastructure. Today only some of that works: keys and metadata exist in resolver records; capabilities and revocation don’t.
ENS lacks a standardized, resolver-native “agent trust runtime” for dynamic control, validity, permissions, and portable reputation.
No resolver-level surface today lets any service verify, in real time, whether an action attributed to an ENS-named agent is currently authorized.
Why ENS?
Agents perform transactions, build reputation, get revoked, re-keyed, or migrated across platforms. They need a persistent identifier that outlives any single key, hosting runtime, or capability grant — and remains verifiable to every counterparty.
ENS-bound agents already fulfill most of these requirements today. Our reference implementation demonstrates, end-to-end, two essential tiers of agent identity:
- Display — the name appears cleanly in wallets, explorers, and user interfaces.
- Discovery — counterparties can resolve the name to retrieve endpoints, registries, keys, capabilities, and context (via ENSIP-25, ENSIP-26, and ERC-8004).
These tiers are necessary, but not yet sufficient for what MARPs need from ENS-anchored agent identity. A third tier, Authority, closes the gap. Counterparties verify the agent’s signed actions against ENS-resolved state, in real time.
With Authority, ENS satisfies the agent identity requirement set end-to-end.
Other agent stack layers (wire-protocol auth, ERC-4337, capability tokens) live above the naming layer. None of them provides a real-time, universally resolvable answer to “which keys and capabilities are currently authorized for this ENS name?”
ENS uniquely fits this slot — not because no other substrate could in theory, but because no other already delivers the persistence, verifiability, and composability the agent identity requirement set demands.
Now or Fragmentation
Microsoft’s Entra Agent ID is the closed, vendor-specific MAIP — already shipping, already pulling enterprises into Microsoft-anchored agent identity. KPMG’s Q1 2026 AI Pulse found 54% of organizations actively deploying AI agents, with twelve-month AI spending nearly doubling YoY.
If the Authority primitive substrate is built, ENS can deliver its own open, portable, cross-platform MAIP — giving agents a neutral identity layer that works beyond any single vendor’s walls.
An ENS-type MAIP would look like a subname issuance service with auth primitives built in — the cb.id growth pattern, applied to MARPs.
The window to ship the open alternative is bounded. Every enterprise that locks in on the closed MAIP this year is one less candidate for the open alternative next.
Addressing the Design Space
The agent identity design space is in active development. Here’s where our approach offers coverage — and where it intentionally stops:
| Design-space | Scope |
|---|---|
| Automate staleness/revocation hooks tied to ownership events | Yes |
| Signed endpoint attestation records | Partial |
| JSON-Schema-backed records for agent-context | No |
| Bridge ENS names to cross-chain reputation | Partial |
| Capabilities manifests | Yes |
| Standardizing trust signal API for wallets | Partial |
We’re mostly interested in exploring the Authority policy lookup layer — what an agent trust runtime needs to provide for dynamic control, validity, capability-scoped permissions, and portable reputation.
Our scope is narrow by design, but we’re optimistic that ongoing ENS-community discussion on agent identity will develop new approaches that tackle other aspects of this design space.