Agent Identity Is Not a Category: A Structural Audit of Six Vendors, Three Missing Layers, and One Absent Platform

The vote was 154 to 38. Both numbers were votes in favor. That is the detail worth staring at.

On October 15, 2026, six vendors were shipping agent identity products. The IETF had not finished the standard. The usual reading of that sentence is a supply-demand mismatch — markets moving faster than process, engineering outrunning governance. That reading is wrong, and it is wrong in a way that misleads every procurement decision made in the next eighteen months.

154 people wanted a working group. 38 would accept the proposed charter as written. The delta is not a scheduling delay. It is a disagreement about what the object under discussion actually is. A working group with a contested charter does not produce an RFC. It produces four years of mailing list archaeology and a shelf of expired individual drafts. Anyone who has watched an IETF effort die knows the shape: the BoF is enthusiastic, the charter is narrow, the narrow charter excludes half the interested parties, the excluded parties publish competing profiles, and the "standard" arrives as five mutually incompatible documents that all cite the same RFC number in their marketing.

The 154-to-38 split is the single most informative data point in the entire agent identity cycle, and almost nobody is pricing it.

I have spent the last eight months auditing an AI-agent framework's API integration with smart wallets. I found a race condition that let agents bypass multi-sig requirements under specific latency conditions. That work taught me something about this sector that enterprise IAM analysts keep missing: the failure mode is never the cryptography. It is always the semantics. The signature verifies. The question of what the signature meant is where everything breaks.

So let me do what the vendor decks will not do. Strip the launch announcements down to their mechanisms, and count what is actually there.

The context nobody wants to re-read

Agent identity is not new. It is a rename.

The mechanisms underneath every one of these six products were standardized between 2014 and 2020, by people who were not thinking about AI agents because AI agents did not exist as a commercial category. Three of them matter.

RFC 7523, published in 2015, defined the JWT Bearer Grant — the ability to present a signed assertion as proof of authorization. RFC 8693, published in 2020, defined Token Exchange — the ability to take a token valid at one authorization server and trade it for a token valid at another, with reduced scope. SPIFFE and its sibling WIMSE defined workload identity — a cryptographic identity issued to a running process rather than a human, bound to the process's attested state rather than to a password.

Every product in this market is a repackaging of those three primitives. That is not a criticism. Repackaging is how infrastructure matures. TCP/IP was a repackaging of ideas that had circulated for a decade.

But the repackaging has a specific shape, and the shape determines who wins.

ID-JAG — Identity Assertion JWT Authorization Grant — is the reference implementation of the repackaging. Its mechanism is a three-stage chain: a JWT assertion is issued (RFC 7523), exchanged across authorization servers (RFC 8693), and constrained by OAuth 2.1 scope semantics. The incremental value is that the chain extends from "user → application" to "user → application → agent → target resource," and that the identity provider, not each resource server, signs the head of that chain.

That is a real engineering convergence. It solves a real problem. It is not a new trust model.

The market framing has been "ID-JAG camp versus protocol-agnostic camp." Okta and Descope anchor the first. Postman, ServiceNow, and Cequence occupy the second. That framing is the vendors' framing, and it is a surface distinction dressed as an architectural one.

The actual fault line runs somewhere else entirely.

Core: three layers, none of them named

The disagreement inside the IETF is not about token formats. Token formats are the easy part; the JWT specification has been stable for a decade and nobody is arguing about base64url encoding.

The disagreement is about three technical layers that no vendor deck names, and that the 154-to-38 vote is implicitly a vote about.

Layer one: delegation semantics

The question is precise. Agent A is authorized by user U. Agent A delegates to Agent B. Agent B requests resource R with a constrained scope S. How is that entire chain expressed in a single unforgeable credential that an auditor can read eighteen months later?

ID-JAG does not answer this. ID-JAG answers "how does the agent get a token." It does not answer "how does the token carry the provenance of a three-hop delegation." Scope strings do not compress. If you try to encode a delegation chain into a scope string you get something like act:agent-b:on-behalf-of:agent-a:on-behalf-of:user-u:scope:read — which is unbounded, unparseable by anything that did not write it, and impossible to revoke at a single hop.

WIMSE does not answer it either. WIMSE gives you workload identity at a point in time. It does not give you lineage.

Every product in this market can tell you which agent is calling. None of them can tell you, from the credential alone, who that agent is standing in for and whether the standing-in was ever re-authorized.

I have seen this failure mode up close. In 2026 I was auditing an agent framework's smart-wallet integration and found a latency window where an agent could re-enter the authorization path before the multi-sig challenge had resolved. The credential was valid. Every signature verified. The problem was that the credential asserted "this agent may act" without asserting "this agent may act as this principal, for this duration, down this chain." The gap between those two assertions is the entire security surface.

Layer two: proof of possession

A bearer token is a bearer instrument. Whoever holds it, uses it. This is a forty-year-old problem and it is not solved.

Of the six vendors, exactly one touches this layer. Descope supports SPIFFE-bound workload identity plus mTLS, which means the token is bound to a key that never leaves the process, which means a stolen token is a useless token. The other five ship bearer tokens with a shorter expiry and call it mitigation.

The public commentary on this compressed Descope's SPIFFE work into a single clause — "a step beyond Okta's current posture" — which is roughly equivalent to describing a deadbolt as "a step beyond a doorknob."

Consider what bearer tokens mean for agents specifically. A human's bearer token sits in a browser session. An agent's bearer token sits in a process that ingests untrusted text — web pages, emails, tool outputs, other agents' messages — and executes on it. The attack is not credential theft. The attack is prompt injection against a process that already holds the credential. PoP does not fully solve that either, because the legitimate process is the one being manipulated. But PoP at least ensures the credential cannot be exfiltrated and reused elsewhere, which cuts the blast radius from "unbounded" to "bounded by what this specific process could already do."

Five of six vendors chose the shorter expiry. Short expiry is not a security control. It is a latency tax paid by the honest.

Layer three: revocation granularity

If a delegation chain is user → A → B → R, and B is compromised, can you revoke B without revoking A and without invalidating every token that ever touched R?

Only ServiceNow has an explicit answer, and the answer is coarse: tiered execution plus a kill switch. Kill switch means the whole chain stops. That is defensible. It is not granular, but it is a decision, and a decision is more than anyone else has published.

Everyone else has the standard OAuth story: revoke the refresh token, let the access token expire. In a world where an agent chain can complete a hundred thousand operations inside one access token's lifetime, "let it expire" is a description of the incident, not a remedy.

These three layers — delegation semantics, possession proof, revocation granularity — are the actual competitive terrain for the next eighteen months. Token format is a distraction that the market has mistaken for a strategy.

The protocol-agnostic tax nobody is billing for

The second camp is built on a claim: we do not care which protocol your agents speak, we govern all of them. Postman governs at the API gateway. Cequence governs at the traffic layer. ServiceNow governs at the workflow layer.

This is presented as an elegant abstention from a standards fight. It is not abstention. It is a much harder engineering commitment than the ID-JAG camp has made, and the vendors are not being honest about the cost.

MCP's authorization model runs on OAuth 2.1 with Resource Indicators plus an Enterprise-Managed Authorization extension. A2A's authorization model runs on security schemes declared inside the Agent Card, predominantly OIDC and OAuth 2.0. These are not isomorphic. They differ on three axes that matter:

Subject identification. In MCP, the resource is the anchor; the token is scoped to a resource indicator. In A2A, the agent is the anchor; the agent's card declares what it can do and how it authenticates. The same request has two different natural subjects depending on which protocol carries it.

Capability declaration. MCP declares capability through tool enumeration at session initialization. A2A declares capability through the Agent Card, statically. A policy engine that wants to answer "may this agent call this tool" has to reconcile a dynamic enumeration with a static declaration, and there is no specified mapping between them.

Delegation chain expression. Neither protocol has a normative representation. Both leave it to the OAuth layer, which as established does not have one either.

"Protocol-agnostic execution" is easy if you mean "accept any token format." Parsing a JWT and parsing an opaque string are both trivial. Protocol-agnostic execution is extremely hard if you mean "normalize MCP's and A2A's authorization semantics into one policy model" — which is what it actually has to mean, and which is functionally writing a cross-protocol semantic middleware layer that no standards body has specified.

Postman has the distribution to make that middleware matter, because it sits on the API traffic path and can enforce without asking permission. Cequence has the behavioral telemetry to make it interesting. Neither has published a mapping specification. Until they do, "protocol-agnostic" is a marketing word for "we intercept the call and hope the semantics line up."

The consensus failure is structural, not incidental

IETF working groups succeed under a narrow set of conditions. Two matter here.

First, a single dominant vendor willing to absorb the implementation cost of the reference stack. OIDC emerged because a small number of large implementers needed it and could fund it. SCIM emerged because the use case set was tiny and unambiguous — create, read, update, delete a user record across a boundary.

Second, a converging use case set. Not a large one. A converging one.

Agent identity fails the second condition catastrophically. A customer support agent that reads tickets needs a trust model measured in read scopes and session lifetime. A coding agent that writes and executes code needs a trust model measured in filesystem and network reachability. A financial trading agent needs a trust model measured in transaction limits and human-in-the-loop thresholds and regulatory retention. These three have almost nothing in common except that all three are called "an agent."

A single working group charter covering all three is either so broad it specifies nothing, or so narrow it excludes two-thirds of the interested parties. The 154-to-38 split says the room understands this and has not found the narrow cut.

The likely outcome is not a failed standard. It is no single standard at all — a set of narrow profiles that do not interoperate, each backed by whichever vendor could afford to write it. That outcome is fine for vendors with distribution and catastrophic for vendors whose only asset is standards positioning.

The revocation question is also unresolved at the process level. ID-JAG's current revision carries a validity window running to November 22, 2026. Nobody has published the probability that the following revision enters Working Group Last Call. When a draft's expiry date is the most concrete fact in its roadmap, the roadmap is not a roadmap.

The absent platform

Here is the fact that reorganizes the entire competitive map, and it appeared in the source material as a subordinate clause.

Microsoft does not implement ID-JAG.

Entra ID is the largest installed base of enterprise identity on the planet. Entra Agent ID went generally available in April 2026 — four months before Okta's announcement — and it ships bundled inside existing E5 and E7 licensing, which means the marginal cost to an existing Entra customer of adopting agent identity is zero.

A standard that the largest installed identity provider does not implement is not a default standard. It is a coalition. Coalitions matter. Okta's alliance of 25-plus partners — Anthropic, Zoom, Slack, Cloudflare among them — is a real distribution asset. But coalition members are also Entra customers, and when the procurement conversation reaches the licensing line, the bundle wins.

So the two-camp framing collapses into three:

Standard anchors — Okta, Descope. Bet: a converged IETF profile becomes the procurement requirement, and being first to draft it confers structural advantage.

Protocol-agnostic governors — Postman, ServiceNow, Cequence. Bet: the standard never converges, so the enforcement point becomes the standard.

Platform-native — Microsoft. Bet: no standard is needed when you own both ends of the connection. Entra issues the identity and Entra validates it, and the interoperability question is definitionally out of scope because there is nobody to interoperate with.

The third camp is not competing on standards. It is competing on the absence of standards, and it is structurally advantaged by every month the IETF fails to converge.

Every week of IETF deadlock is a week of market share transferred to the vendor that never wanted a standard in the first place.

The certification gap

The deepest structural omission in the whole cycle is not technical. It is institutional.

Enterprise identity does not converge at the IETF. It converges at the certification bodies. FAPI, the financial-grade profile family, was largely shaped inside the OpenID Foundation rather than the IETF. Enterprise procurement teams do not write "must implement RFC 8693" into a requirements document. They write "must be Kantara certified" and "must be FIDO Certified." Those certifications are what a compliance officer can point at during an audit. An RFC number is what an engineer can point at during a design review. They are not the same currency.

None of the six vendors has announced a certification pathway. None has named a conformance program. None has published a test suite.

Even if the IETF delivers a perfect RFC in 2027, no enterprise will be able to procure against it, because there will be no certifying body, no conformance test, and no auditor willing to sign off on "the vendor says it complies."

The likely resolution is that a narrow profile gets pushed through the OpenID Foundation as an extension of existing FAPI work, and the certification question is quietly absorbed into an existing program. That is a less exciting story than an IETF working group. It is also the only path that ends in a purchase order.

Who pays

The commercial analysis of this sector has a hole in the middle of it, and the hole is the customer.

Traditional IAM has a clean payer: the enterprise buys identity management for its own employees, the budget line is IT security, the buyer is the CISO. Agent identity has three candidate payers with three different budget lines and three different willingness to pay.

The agent's owner — enterprise IT. Budget line is IAM. Buyer is the same CISO who already has an Entra or Okta contract. This is a renewal conversation, not an acquisition conversation, which means incumbents win by default.

The agent's operator — a SaaS vendor running agents on behalf of customers. Budget line is cloud cost. This buyer is extremely price-sensitive, has engineering capacity, and defaults to building rather than buying. This segment will not pay for agent identity. It will build a shim.

The resource owner — the party being accessed. Budget line is API security. This is Cequence's territory and Postman's adjacency. This buyer pays, but pays for a control, not an identity.

Three payers, three budget lines, no single product that covers all three. Every vendor in this market has picked one and is marketing to the other two.

ServiceNow's actual moat

The most undervalued position in the six is ServiceNow's, and the reason has nothing to do with AIMS or WIMSE.

ServiceNow AI Passport's differentiation is that its policy decisions are grounded in CMDB and GRC data. Read that again in operational terms. The hard part of agent identity is not issuing the credential. Issuing a credential is a signing operation. The hard part is deciding what the credential should permit — and that decision requires an authoritative inventory of what assets exist, what depends on what, what is classified how, and who owns it.

ServiceNow owns the most complete enterprise IT asset graph in existence. It does not need to win the identity standard. It owns the input side of the policy engine. Every competitor has to buy, scrape, or approximate that graph, and every competitor's approximation will be worse.

ServiceNow can lose the standards fight, lose the token format fight, lose the partner alliance fight, and still win, because the policy decision requires an asset inventory and it already sold that inventory to the customer.

The public framing put ServiceNow in the same bucket as Cequence — "the protocol-agnostic camp." That bucket contains two companies with opposite risk profiles. Cequence's product only works if agents lie about their identity. ServiceNow's product works whether they lie or not, because it is checking against ground truth it owns.

Okta's four-month problem

Okta has the best standards position and the worst structural position, and the two are related.

Its assets are real: 25-plus partners, the drafting position on ID-JAG, a seat at the table on MCP's Enterprise-Managed Authorization extension. If standards convergence were the deciding factor, Okta would win.

Its vulnerability is simpler. Its customers are Microsoft's customers. Entra Agent ID reached general availability four months earlier and arrives at zero marginal cost inside an existing license. Okta's counter-position has to be cross-platform neutrality — the argument that a customer with Entra, Okta, AWS IAM, and a pile of SaaS IdPs needs a neutral control plane.

That argument is correct. It is also the hardest argument in enterprise procurement to quantify. No CISO has ever been fired for buying the bundle. Plenty have been asked why they paid a premium for neutrality.

Four months of lead time plus zero marginal cost plus an existing billing relationship is not a marketing advantage. It is a structural one.

The acquirers nobody listed

The six-vendor map is missing two entire classes of player, and both classes are the natural buyers.

The first class is privileged access management and machine identity incumbents: CyberArk, now inside Palo Alto Networks; HashiCorp Vault; Venafi. These companies have spent two decades selling credentials to non-human entities — service accounts, certificates, secrets, daemons. They already have the customer, the budget line, and the organizational muscle memory for "this thing is not a person and still needs an identity." Agent identity is not a new product category for them. It is a new workload type.

The second class is the non-human identity security startups that dominated 2024 and 2025: Astrix, Oasis, Entro, Clutch. These companies built discovery and governance for the sprawl of service accounts, API keys, and OAuth grants that already exists. Their entire product thesis is that organizations have no inventory of their non-human identities. An agent is a non-human identity with a language model attached.

Neither class appears in the six-vendor narrative. Both are better positioned to acquire Descope or Cequence than any of the six is to acquire each other.

The most likely consolidation path is not IAM vendor buys IAM vendor. It is machine identity incumbent buys agent identity startup and relabels the product line.

Ship is not adopt

The headline word is "shipping." The word that never appears is "adopted."

Across six vendors, there is exactly one deployment-scale number in circulation: Descope's claim of millions of agents and over a thousand MCP servers. That number has no definition attached. What is an agent? Is a single API call from an agent a unit? Is a long-running process a unit? Is an agent that has been provisioned but never invoked a unit?

There are no published paid customer counts. No renewal rates. No deployment sizes. No reference architectures with named enterprises. Five of the six key figures in the cycle originate from vendor press materials rather than independent measurement.

This is not unique to agent identity. It is the standard texture of an early market. But it means that every market-sizing claim in circulation should be read as a vendor's forecast, not a measurement.

And the timing tells its own story. Five of six announcements landed inside a seven-week window, from August 24 to October 15, with Descope and ServiceNow announcing on the same day. Seven weeks is not the rhythm of a market maturing. Seven weeks is the rhythm of an analyst briefing calendar and a conference season.

The legitimate subject with the illegitimate behavior

This is the question the entire sector is avoiding, and it is not a standards question.

An agent holds a valid credential. A malicious document reaches that agent through a tool call, an email, a web page, or another agent's message. The agent is now executing the attacker's intent while holding the user's authority. Every signature verifies. Every scope is respected. The audit log records a legitimate subject performing a permitted action.

No vendor in this market has an answer. Not one.

Descope's selling point is that users do not have to click through a consent screen for each connection. That is a genuine UX improvement. It is also the removal of the last human checkpoint in the chain, traded for convenience. Enterprises pay to reduce audit findings. They do not pay to reduce clicks. The willingness-to-pay curve points the wrong direction.

Cequence's behavioral detection is the only product in the six whose value proposition survives this attack — because its premise is that identity claims cannot be trusted and behavior must be checked. But that same premise caps its ceiling. A product that exists because agents lie about their identity can never become the identity infrastructure. It stays a detection tool, priced as a detection tool, acquired by a detection vendor.

The on-chain version of this problem is worse, and I have watched it play out. When I audited agent frameworks against smart wallets in 2026, the failure was not that the agent lacked permission. It was that the agent had exactly the permission it had been granted and used it for something the granter never imagined. Session keys in an ERC-4337 account encode scope. They do not encode intent. EIP-7702 delegation lets an EOA hand execution rights to a contract; it does not let that EOA express what the contract is for.

On-chain there is no IdP to appeal to, no support ticket, no chargeback. The transaction is final and the credential was valid. The gap between "authorized" and "intended" is where every one of these systems will fail, and it is the one gap nobody is building for.

What the bulls got right

I have spent four thousand words dismantling this sector. The bulls are not wrong about everything, and the strongest version of their case is better than most of the vendors are making it.

They are right that the IETF's failure is not fatal. In fact, the failure may be correct. A single unified agent identity standard would have to serve a support agent, a coding agent, and a trading agent with one semantic model, and any model broad enough to do that would be broad enough to be useless. Narrow profiles that do not interoperate are ugly, but they are honest. They map to real, distinct threat models. The alternative — a grand unified standard that specifies nothing precisely — is how you get a compliance checkbox that means nothing.

They are right that protocol-agnostic enforcement is where the volume goes. The overwhelming majority of agent traffic in 2027 will cross an API gateway that neither the agent's vendor nor the resource's vendor controls. Whoever sits on that path has leverage regardless of what the IETF does. Postman's position on the traffic path is worth more than any drafting committee seat.

They are right that bundling beats standards. Microsoft proved it four months before Okta shipped. Entra Agent ID will be the most widely deployed agent identity product in the world by the end of 2027, and it will not be because it is the best. It will be because it was free to people who had already signed.

And they are right about one thing that the skeptics keep getting wrong: the token exchange work is genuinely good engineering. RFC 8693 was a well-designed primitive and ID-JAG is a competent application of it. The people building this are not hacks. They are solving a hard problem with the tools available.

The blind spot is the assumption that a competent technical primitive produces a durable commercial category. I have watched that assumption fail repeatedly. In 2017 I submitted a pull request to a major protocol's core team identifying a proxy pattern that produced 40% higher gas costs under specific conditions. It was rejected as premature optimization. The technical finding was correct. The commercial outcome was that nobody cared, because the people who cared about correctness were not the people writing checks.

That pattern is repeating here at a larger scale.

Takeaway

Three questions will separate the vendors that survive this cycle from the ones that get absorbed.

First: what is the deployment count, defined precisely, and how many of those deployments renewed? Not shipped. Renewed. Any vendor that cannot answer this is selling a press release.

Second: what is the proof-of-possession story? If the answer involves token expiry as the primary control, the vendor has not addressed the layer that matters. One of six has. That ratio is the state of the industry.

Third: which certification body will attest to conformance? If the answer is "the IETF," the vendor has misunderstood how enterprise procurement works and the product will not clear the audit committee.

The standard's heart. It is not the token format. It is the delegation chain, the possession proof, and the revocation granularity — three layers that no charter currently addresses, that one vendor partially solves, and that the largest platform in the market has no incentive to solve at all.

The market's heart. It is not the announcement. It is the renewal.

And the bundle's heart. It beats four months early, at zero marginal cost, inside a contract the customer already signed. Everything else in this sector is a negotiation about who gets to sit at a table the platform owner did not agree to attend.