Agent identity is a category, not a feature

When Okta puts "agent support" on a slide, they mean a checkbox. When we say it, we mean a new species of software. The difference between feature and category determines who wins this decade.

The pattern in five examples

Every category-creation moment in software has a tell: the incumbent treats the new thing as a feature; the upstart treats it as a category. The history is consistent.

• 1990s — "Email security" looked like a feature of the email client. Mimecast and Proofpoint treated it as a category. Multi-billion-dollar outcomes.
• 2000s — "Mobile device management" looked like a feature of Active Directory. AirWatch and MobileIron treated it as a category. Billions in exits.
• 2010s — "Cloud security posture" looked like a feature of AWS. Wiz, Orca, and Lacework treated it as a category. Tens of billions.
• 2010s again — "API management" looked like a feature of the firewall. Apigee, MuleSoft, and Kong treated it as a category. Multi-billion outcomes each.
• 2020s — "AI observability" looked like a feature of Datadog. Arize, Fiddler, and others treated it as a category. The contest is ongoing.

In every case, the incumbent's instinct was to ship a feature. The upstart's bet was that the problem was structurally large enough to need a separate vocabulary, separate buyer, separate ROI story. The bets that paid off were the ones where the structural argument turned out to be true.

Why agent identity is structurally a category

Three structural arguments, each independently sufficient.

Argument one: scale inversion. The 100:1 ratio of non-human to human identities means traditional IAM is solving a minority problem. Categories that solve majority problems on inverted ratios become categories of their own. (Compare: TLS to SSH; CDNs to web hosting.)

Argument two: regulatory mandate. Article 14 of the EU AI Act, enforceable today, demands a specific cryptographic primitive — verified human supervision of agent action — that no incumbent IAM ships natively. Regulatory mandates that name primitives create categories. (Compare: PCI-DSS creating tokenization; GDPR creating consent management.)

Argument three: economic primitive. Verification gas, work attestation, trust-stake yields, and marketplace settlement together constitute an economic layer that no current IAM has. New economic primitives carry new categories with them. (Compare: payments to merchant services; on-chain governance to traditional ops.)

The feature trap

The incumbent strategy today is "agent support" as a feature: a checkbox in the SSO product, a new role type in the IDP, a per-agent license SKU. Each of these is shipping. None of them addresses the three structural arguments above.

This is not a criticism. It is a description. Incumbents optimize for incremental ARR; they cannot reasonably bet against their existing customer base. The feature trap is a rational local maximum that loses the global game.

What category-creation requires

Categories are created by saying the new word, repeatedly, until journalists, analysts, regulators, and buyers say it back. That is what we are doing with HATI — Human-Agent Trust Infrastructure. Five years ago we would have had to invent the word. Today the buyer's pain has done most of the work; we are naming what they already feel.

The vocabulary follows: "agent identity" instead of "service account." "Delegation token" instead of "API key." "Work attestation" instead of "audit log entry." "Trust score" instead of "endorsement." Each pair signals a categorical shift, not a feature improvement.

What this means for buyers

If you are evaluating vendors and they describe the work in feature language — "we added agent support to our IDP" — you are buying into a feature trap. The architecture is wrong, the audit log is wrong, the buyer's primary use case is wrong, and the math will not change with a new release.

If a vendor describes the work in category language — "this is a different control plane that lives next to your IDP, focused on the human-agent boundary" — they are at least asking the right question. Whether they answer it well is a separate evaluation.

Common objections

Two objections come up across every conversation. Will the platform vendors ship this themselves? Some will, inside their boundary; none can ship the cross-platform shape, by their own architectural choice. Is the category too narrow to matter? It's the layer beneath every agent action — narrow looks broad once the wire bends.

Frequently asked questions

Why does this category not already exist? Because the failure mode it addresses is recent. The pre-agent enterprise could pretend the service account was the human; the agentic enterprise cannot. The category becomes named when the failure becomes regulator-visible, which is now.

Where does this end up in the standards stack? As a layer above OAuth and below the application. OAuth carried scoped delegation between services; this layer carries scoped delegation from a verified human to an agent. The IETF and W3C working groups are converging on the shape; the protocol that ships first sets the verbs.

What does adoption look like in practice? Quietly. The integrations are middleware, not platforms. Each vertical sees its specific compliance pain solved — healthcare gets Article 14, finance gets SOC 2 evidence, hiring gets continuous identity — and treats the underlying primitive as plumbing once it ships.

Where to start

Read trust layer 100b company next for the deeper architecture. Then hati vendor map for the closest practical anchor. The mental model that holds those two together holds the rest of the site as well.

The incumbent ships features. The category-creator ships vocabulary.