How the identity layer is being built
A June 2026 snapshot of who is building agent identity and authorization, mapped to the controls. Standards first, vendors second, no recommendations.
This is the field-build companion to the groundwork post on identity and authority: that one lays out the controls, this one maps who is actually building them, as of June 2026. The disclosure at the end is worth reading first, this is a map of activity, not a buyer's guide.
Identity is the most commercially mature of the six layers, because the people building it are the people who already built enterprise identity. That is a strength and a risk. A strength because the primitives are real standards, not slideware. A risk because the established identity vendors and the agent platforms are now circling the same ground, and where they meet is unsettled.
The standards come first
This layer rests almost entirely on open standards, and the primitives are solid enough to design against well before any procurement decision.
- SPIFFE gives a workload its own verifiable identity (an SVID, a short-lived auto-rotating ID document for software); SPIRE is the open reference implementation.
- W3C DID and Verifiable Credentials [standard] provide portable, cryptographically verifiable identity not tied to one vendor's directory, though portability in practice still depends on the DID method, the resolver, and which relying parties accept it.
- OAuth is the spine of authorization: token exchange (RFC 8693) carries delegation through the
actclaim, and the broader OAuth 2.1 profile is still an IETF draft, so the ground is settling even as everyone builds on it. - OIDC/CIBA handles out-of-band approval; NGAC and Zero Trust (NIST SP 800-207) frame continuous, attribute-based authorization.
- NIST's NCCoE concept paper on agent identity and authorization is a government concept paper that points at the same primitives: OAuth, SPIFFE/SPIRE, NGAC.
Who is building what, by control
Distinct agent identity (IA-01). Microsoft puts agent identity in the enterprise directory with Entra Agent ID. Okta and Ping Identity approach it from the identity-platform side. SPIRE carries the open SPIFFE implementation. The contest here is whether agent identity lives in the directory you already run or in a new agent-specific layer.
Short-lived, scoped keys (IA-02). Ping Identity and Okta (through Auth0's Auth for GenAI) build the token-broker pattern: present an identity, get back a minutes-long token scoped to one tool.
Delegation with approval (IA-03). Okta's Cross App Access is an OAuth extension built specifically for agent-to-app delegation, the clearest example of the industry treating this as a protocol problem rather than a product feature. Ping sits here too.
Continuous authorization (IA-04). Ping's Agent Gateway [shipping product] puts the per-call authorization decision in the request path; CrowdStrike [shipping product] adds endpoint-side enforcement, applying the allow/deny at the host where the agent's action actually runs.
Shadow-agent discovery (IA-05). CrowdStrike (endpoint), Microsoft (Agent 365 as a registry/control plane), and Ping all work the discovery-and-reconciliation problem of finding agents nobody registered.
Where implementation activity is concentrated
The energy here is incumbent identity vendors moving fast to define agent identity as a protocol problem, and the published standards work pointing the same way: NIST's NCCoE concept paper and the Agent Standards Initiative both build agent identity on cryptographic primitives (SPIFFE, DIDs).
The disintermediation question to watch is a turf one: does agent identity get absorbed into the agent platforms (Microsoft's Entra plus Agent 365 covering identity, registry, and discovery in one place), or do the specialist identity vendors (Okta, Ping) hold it as a distinct layer? A platform that owns identity, the registry, and discovery at once is convenient, and concentrates a lot of trust in one place.
Consolidating or fragmenting?
Consolidating, more than any other layer. The vendors disagree on packaging but agree on core primitives like OAuth, SPIFFE, and DID, which NIST's concept paper points to as the baseline. For a defender, that means you can design architectural requirements around those open standards regardless of whether you adopt a platform-native registry or a specialist identity vendor.
The handoff
Identity vendors can issue and broker authority. What no mapped product owns is what happens to that authority after it leaves the issuer, especially across an organizational boundary: does a delegated token degrade correctly when it rides an A2A call into someone else's environment? Issuers sit on one side of that seam; on the other side there is no clear owner. That is the identity-to-protocol handoff, and it is where the field's first gap lives.
See the identity groundwork post for the controls and validation steps, and browse the standalone Identity domain at apeiris.ai.
Sources
- SPIFFE/SPIRE · W3C DID Core v1.0 · RFC 8693 Token Exchange · OAuth 2.1 (draft) · OIDC CIBA · NGAC (NIST SP 800-178)
- NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization
- Okta, Cross App Access and Auth for GenAI · Ping Identity, Identity for AI
- OWASP Non-Human Identities Top 10 · CSA + Strata Identity, Securing Autonomous AI Agents (2026 survey)
---
How to read this. Snapshot dated 21 June 2026. A product appears here because it maps to a control, not as a recommendation or independently validated efficacy; vendor figures are their own claims; status tags mark what kind of thing each entry is. The full neutrality statement and method are in the capstone.