Okta's Agent Identity Grant: A Draft Standard, a Beta Gateway, and a New Billing Unit

Hook

The Runtime Agent Gateway entered beta on September 16, 2026. It has not entered general availability. The identity standard the gateway exists to execute — Identity Assertion Authorization Grant, ID-JAG — is an IETF Internet-Draft, not a Request for Comments. And the headline attached to both facts was that the market is building around a pre-GA standard.

Read that phrase again. Pre-GA modifies standard, not product. The product is pre-GA too, but the announcement chose to hang its credibility on the ecosystem, not the shipping code.

I have spent nine years auditing the gap between a protocol's described behavior and its deployed behavior. The gap is almost never fraud. It is almost always sequencing — a claim made public before the mechanism that supports it has finished being built. Okta's agent identity stack is a textbook case of sequencing error, and the error is not subtle. The execution point of the entire authorization model — the inline gateway that mints, scopes, and revokes every agent credential — was, at the moment of announcement, a beta API behind a roadmap page.

That is not a detail. That is the load-bearing wall.

Everything downstream of that wall — the delegation chain, the downscoping, the audit trail, the revocation semantics, the billing unit — depends on a component that a procurement officer cannot yet buy, cannot yet benchmark, and cannot yet put in a service-level agreement. The announcement describes a finished governance architecture running on an unfinished machine.

I want to be precise about what I am and am not alleging. I am not alleging that the mechanism is fake. The protocol mechanics described in the coverage are technically coherent and map cleanly onto published specifications — that is the strongest part of the story, and I will give it full credit. I am alleging something narrower and more damaging: that the coverage conflates a correct design with a shipped product, and conflates authorization with security, and conflates an ecosystem of two vendors with a market.

Three conflation errors. Each one individually survivable. Stacked, they produce a narrative that a security buyer could reasonably act on and be wrong.

The ledger does not lie, but it forgets. It forgets that a draft is not a contract. It forgets that a beta is not a control. It forgets that a logo on a partner page is not an integration test.

So let us reconstruct the ledger line by line, and see what survives.

Context: Why Agent Identity Became an Emergency

The problem Okta is addressing is real, and it is worse than the marketing suggests.

For roughly a decade, the dominant pattern for connecting software to software has been the static credential: an API key, a service account password, a long-lived OAuth client secret, occasionally a bearer token with an expiry measured in months. These credentials live in environment variables, in YAML files, in CI secrets stores, in a .env file someone forgot to gitignore in 2019. They are copied, pasted into Slack, embedded in Docker images, and rotated roughly never.

The static key model survived because the blast radius was bounded by the number of integrations a human had to configure by hand. A company might have two hundred service credentials. Two hundred secrets is a manageable — if ugly — inventory problem.

Agentic software breaks that bound. An agent that plans, calls tools, and chains sub-tasks does not have two hundred credentials. It has a credential per tool, per task, per session, potentially per invocation. A single enterprise deployment of five hundred agents, each executing two thousand tool calls a day, generates a million authorization events daily. The inventory problem becomes a rate problem. The static key model does not degrade gracefully at that rate. It fails structurally.

The failure has a name in the security literature: non-human identity, or NHI. The category covers service accounts, workload identities, CI/CD principals, and now agents. Industry surveys through 2024 and 2025 consistently put NHI counts at ten to fifty times human identity counts in mid-to-large enterprises, with the ratio climbing. The governance tooling for that population has historically been an afterthought bolted onto human-focused IAM suites.

Okta's announcement is a bid to move NHI from afterthought to centerpiece. The specific components, per the coverage, are these:

Agent SSO, described as generally available. Agent-to-Agent Connections, generally available. Resource Access Certifications, generally available. Runtime Agent Gateway, with a beta API dated September 16, 2026, and no GA date disclosed. And Identity Assertion Authorization Grant (XAA), Okta's branded name for a flow built on the ID-JAG draft specification.

The flow itself, as described: an agent presents an inbound token plus a requested scope to the gateway. The gateway submits that to Okta's token endpoint. A secure token service completes consent and authorization, then returns a short-lived, single-use ID-JAG token. That token is downscoped to the specific task, carries the human user's sub claim, and carries a nested act claim identifying the agent as the actor in the delegation chain.

This maps directly onto RFC 8693, OAuth 2.0 Token Exchange, published January 2020, which defines the act claim precisely for this purpose: representing a chain of delegation where a subject acts on behalf of another subject. The nested structure — human subject, agent actor, possibly a further nested actor for a sub-agent — is not Okta's invention. It is the specification working as designed.

That matters for credibility. It means the technical description in the coverage was not improvised by a reporter working from a press release. Somebody at Okta described a real mechanism, and the mechanism has a real paper trail.

It also means something else, which the coverage does not say. If the mechanism is RFC 8693 plus OIDC plus the Shared Signals Framework plus JWT claim chaining, then the technical contribution is composition, not invention. Composition is legitimate engineering. It is also the most replicable kind of engineering there is, because every component is public.

Core: The Systematic Teardown

The mechanism is sound, and that is the least interesting fact about it

I want to establish the baseline honestly before I take the structure apart.

The XAA flow as described is internally consistent. Short-lived single-use tokens eliminate the standing credential. Downscoping to the specific task bounds the blast radius of any single token. Audience binding prevents a token minted for tool A from being replayed against tool B. The sub claim preserves human accountability — the audit trail always terminates at a person, not at a process. The nested act claim preserves the delegation chain, so a reviewer can reconstruct which agent, on whose behalf, invoked which tool, at what time.

These are the correct primitives. If you asked me to design an agent authorization model from first principles in 2026, I would reach for RFC 8693 and the act claim too. I have audited enough token systems to know what the failure modes look like, and this design avoids the obvious ones.

That is the ceiling of my endorsement. Everything past this paragraph is a critique, and none of it disputes the design.

Provenance check: where the mechanism actually came from

My 2021 work on digital art provenance taught me a habit I have not been able to break. Before I evaluate a claim, I trace the lineage of the thing making the claim.

Trace this one. The act claim: RFC 8693, Section 4.1, January 2020. Token exchange semantics: same document. Delegation chain representation: same. Downscoping: a documented token exchange behavior, not a novel construct. Short TTL and revocation: the Shared Signals Framework and standard OAuth practice. Audience restriction: RFC 8705 and RFC 9068 territory.

The only genuinely novel element is the modeling decision — treating an agent as a first-class identity type with its own lifecycle, rather than as a generic machine principal or an extension of a human account. That is a real conceptual contribution and I do not want to understate it. Getting the identity taxonomy right is where most IAM projects fail before they begin.

But conceptual contribution is not architectural innovation, and it is certainly not technical moat. Every element of the mechanism is published, readable, and implementable by anyone with an OAuth library and a week of patience. The barrier to replication is not knowledge. It is distribution.

Which brings us to the standard.

The standard is a draft, and drafts drift

ID-JAG is an IETF Internet-Draft. Not an RFC. Not even, as far as the coverage discloses, a working group item with a clear path to publication.

This distinction is load-bearing, and the coverage treats it as a formality. It is not.

An Internet-Draft is a document someone submitted. It carries no normative weight. Its field names, its claim structures, its error semantics, its flow diagrams can all change between revisions — and they frequently do. The IETF's own process documentation is blunt about this: drafts are working documents, they expire after six months if not refreshed, and a substantial fraction never become RFCs at all. The OAuth extension space in particular is littered with drafts that reached implementation and then died — some because a competing approach won, some because a security review found a flaw, some because the authors lost interest.

When a vendor builds on a draft, that vendor's early adopters absorb standard drift risk. If the act claim nesting semantics get redefined in revision -04, every integration built against -03 has to be rewritten. If the audience binding rules tighten, previously valid tokens become invalid. If the draft is superseded by a different working group's output, the entire integration surface is stranded.

The coverage frames early adoption as a signal of demand. It may equally be a signal of co-marketing economics. Two mid-sized vendors announcing pre-GA support for a pre-standard specification is not evidence of a market. It is evidence that two vendors found the press release cheap to participate in. Sample size n=2. No disclosed integration depth, no disclosed joint customers, no disclosed revenue.

The ledger does not lie, but it forgets. It forgets that a signature on a partnership page is not a signature on a contract.

The execution point is not shipped

Here is the structural fact the announcement's narrative is built to obscure.

XAA depends on the gateway. The gateway is the component that receives the inbound token, performs the token exchange, applies the downscoping, and returns the ID-JAG token. Remove the gateway and the flow has no execution point. There is no XAA without it.

As of the announcement, the gateway's underlying API was in beta, dated September 16, 2026. The gateway itself was not generally available. The coverage acknowledges this in passing and then proceeds as though the architecture is operational.

It is not operational at enterprise scale, because it cannot be procured at enterprise scale. A security organization that wants a control in production needs three things the beta does not provide: a contractual availability commitment, a published latency budget, and a threat model for the component itself. None of the three appear in the coverage. I checked twice.

This is not pedantry. An inline authorization component that sits on the execution path between an agent and its tools is a different class of dependency than an out-of-band identity provider. If the IdP is slow, logins are slow. If the inline gateway is slow, the agent's work stops. If the gateway is down, the agent is down — unless you configure it to fail open, in which case the security control evaporates precisely when the system is under stress, which is precisely when you need it.

That is the fork in the road the coverage never reaches. Fail-closed means availability risk. Fail-open means the control is decorative. There is no third option, and the choice has to be made explicitly, per integration, with a documented risk acceptance. That decision is the actual product. It is not discussed.

The arithmetic of an inline authorization layer

Let me do the calculation the announcement does not do, because this is where my 2022 work on mechanism stability becomes relevant.

When I reconstructed the Terra-Luna death spiral, the exercise was not to explain why people panicked. It was to show that the peg mechanism had a mathematical property — reflexive collateral dilution under redemption pressure — that made collapse a matter of when, not if, given a sufficient shock. The mechanism was not unlucky. It was load-bearing on an assumption that could not hold.

An inline authorization gateway has an analogous property, and it is not discussed anywhere in the coverage. The property is multiplicative availability decay.

Consider a single agent task that requires sixty tool invocations — not an extreme figure for a multi-step agent workflow with retries. Under XAA, each invocation requires a token exchange. The token exchange traverses the gateway.

If the gateway has three nines of availability — 99.9%, a reasonable enterprise target for a non-critical dependency and a good number for a beta-stage component — the probability that all sixty exchanges succeed is 0.999^60.

0.999^60 = 0.9417.

A gateway with three nines of availability, invoked sixty times per task, delivers a task success rate of 94.2%. The authorization layer alone contributes a 5.8% task failure rate.

Push the gateway to four nines — 99.95%, a demanding target. 0.9995^60 = 0.9704. Still a 3.0% failure rate attributable to the authorization layer, independent of the agent's own reliability, independent of the model, independent of the tool.

This is the governance tax made quantitative, and it is the single most important number missing from the announcement. Every nine of gateway reliability you add costs real engineering. Every increment of agent complexity — every additional tool call per task — multiplies the requirement. An agent that needs two hundred invocations per task, at 99.9% gateway availability, succeeds 81.9% of the time on authorization alone. 0.999^200 = 0.8186.

Now layer on latency. Each exchange is a network round trip to the token endpoint. Intra-region, a well-engineered STS might return in 20 to 40 milliseconds at p50, with p99 in the 100 to 200 millisecond range. Sixty exchanges at 30 milliseconds p50 is 1.8 seconds of pure authorization overhead per task. At p99, sixty exchanges at 150 milliseconds is nine seconds.

The coverage discusses none of this. Not the availability math, not the latency budget, not the p99. For a component positioned as inline infrastructure, those three numbers are the product. Their absence is not an oversight. It is the shape of a narrative that has not yet had to survive a load test.

The billing unit migration

Here is the most consequential fact in the entire announcement, and it is the one stated nowhere.

Okta's traditional revenue model is per-user subscription. Seats. The addressable market is bounded by the global population of knowledge workers who need SSO and MFA — roughly a billion people, of whom a few hundred million are addressable by a vendor at Okta's price point.

Declaring the agent a first-class identity is, in commercial terms, the creation of a new billable seat class. Every agent gets an identity. Every identity is an object in the directory. Every object in the directory is a candidate for a license line item.

If an enterprise with two thousand human seats deploys five hundred agents, and agent identities are priced at even a fraction of human seat pricing, the revenue increment is material — plausibly ten to fifty percent of that account's existing spend, depending entirely on pricing structure that the announcement does not disclose.

That is the growth story. It is a good growth story. It is also a story with a specific pressure behind it: Okta is a public company whose revenue growth has compressed from north of forty percent in its high-growth years to the high teens. A new billable unit class is the cleanest available answer to a decelerating growth curve, and it is not a coincidence that the announcement arrived while the gateway was still in beta.

I am not calling that dishonest. Companies time announcements to narrative needs; that is what announcements are for. But a reader evaluating the product should understand that the cadence of disclosure is being driven by a quarterly reporting calendar, not by a release-engineering calendar.

The absence of pricing information is the largest single hole in the coverage. Without a price, there is no unit economics. Without unit economics, there is no way to evaluate whether the governance tax is worth paying — and the governance tax is not just latency, it is a per-agent, per-invocation cost structure that has to be justified against the risk it mitigates. A security control that costs more than the expected loss it prevents is a bad control, however elegant its protocol.

The evidence base is two vendors and a packaging company

The coverage's claim that the market is not waiting rests on a thin evidentiary foundation.

The ecosystem evidence: Aembit, described as the first third-party enforcement point, and TrueFoundry, integrated October 1, 2026. Two vendors. Both mid-sized. Both with plausible reasons beyond pure technical necessity to appear in an Okta press release.

And here is the part the narrative framework flattens: Aembit's product category is workload identity. Its entire value proposition is providing scoped, short-lived credentials to non-human workloads without routing them through a centralized human-oriented IdP. In the XAA model, Aembit is an enforcement point. In the competitive model, Aembit is the thing you buy instead of the gateway. Those two readings are not compatible, and the coverage adopts only the first.

The customer evidence: a single named reference, the IT director of MJS Packaging — a mid-sized packaging manufacturer. I have nothing against packaging manufacturers. But a low-regulatory-intensity manufacturing firm is the least demanding possible proof point for an enterprise governance architecture. The customers who would actually validate this product — a bank with DORA obligations, a hospital system with PHI exposure, a government agency with classification requirements — are absent. Their absence is itself a data point, and the coverage does not read it.

When a vendor launches a governance product and the only reference customer is in a low-compliance vertical, the correct inference is that the high-compliance logos are not yet signed. That is a normal state for a pre-GA product. It is an abnormal state for a product described as the emerging market standard.

The question the announcement does not ask

I want to flag a technical gap that is, in my assessment, the most serious omission in the coverage.

The de facto standard for agent tool invocation is converging rapidly on the Model Context Protocol. MCP has its own authorization model, built on OAuth 2.1 with Resource Indicators. It is already implemented across a wide and growing set of agent runtimes and tool servers.

ID-JAG and MCP authorization solve overlapping problems. Whether they are complementary, competitive, or mutually contradictory determines the entire trajectory of Okta's proposal, and the coverage does not mention MCP once.

This is not a small editorial oversight. It is the omission of the only question that matters for adoption. If MCP's native authorization path is sufficient for most tool invocations — and for the majority of low-stakes, read-only, internal tool calls, it very likely is — then the addressable surface for XAA shrinks to the high-stakes subset: writes, financial transactions, privileged operations, cross-domain delegation. That is a real market. It is not the market the announcement implies.

Worse, the two models may conflict at the protocol level. If an agent runtime is already carrying an MCP-scoped token, and the gateway wants to perform a token exchange to mint an ID-JAG, you now have two authorization layers with two token formats, two scope vocabularies, and two revocation paths. Layered authorization without a clear precedence rule is how you get confused-deputy vulnerabilities.

Nobody in the coverage asks which layer wins. That question has an answer, and the answer will be determined by whoever ships first at scale, not by whoever names the flow most memorably.

The on-chain mirror, and why crypto readers should care

I write primarily about distributed systems, and I want to draw the parallel explicitly because it is instructive in both directions.

On-chain agents — autonomous contracts, keeper bots, delegated trading agents, agentic payment flows — hit the identical problem two years earlier. A bot that needs to execute a swap needs authority to move funds. Giving it an unlimited ERC-20 approval is exactly the static-key antipattern: unbounded, indefinite, and revocable only by a human remembering to revoke it.

The crypto ecosystem's answer has been account abstraction and scoped session keys. A smart account issues a session key with a defined permission set — a spending cap, a contract allowlist, a time window, a specific function selector. The key is ephemeral. The permissions are enforced by the account contract, not by a central server. Revocation is a state change, not a support ticket.

That architecture solves what XAA solves, and it solves one thing XAA does not: it removes the trusted intermediary from the execution path. The permission check is a local state read against a contract the user controls. There is no round trip. There is no gateway availability term in the compounding equation. A session key with a 99.9% reliable chain does not decay at 0.999^60, because the chain's availability is the same availability the agent already depends on for everything else — the authorization layer adds no marginal failure surface.

What the crypto model does not solve is the audit problem. There is no unified delegation ledger. There is no cross-application policy plane. There is no human-readable chain of custody from a person to an agent to a tool. Reconstructing why an agent did something requires correlating events across contracts and logs that share no common schema.

So the two architectures are complements with inverted strengths. XAA buys auditability and policy centralization at the cost of an inline dependency. Session keys buy execution independence at the cost of governance visibility. The correct architecture for a serious enterprise is almost certainly both — scoped on-chain permissions for execution, an off-chain delegation ledger for accountability — and neither Okta's announcement nor the coverage acknowledges that the on-chain half exists.

That is a genuine blind spot, and it is characteristic of identity vendors: they model the world as identities and policies, and treat execution environments as opaque. Execution environments have their own identity primitives now. Ignoring them is how you end up with a governance plane that cannot see the half of your agent fleet that runs on a chain.

The gatekeeper paradox

Now the omission I consider disqualifying for any security buyer reading the coverage as due diligence.

In October 2023, Okta disclosed that an attacker had gained access to its support system, obtained credentials uploaded by customers to that system, and used them to access customer tenants. The incident followed an earlier 2022 compromise by a different actor. The company's response was substantial — and I am not disputing that — but the facts of the events are a matter of public record.

Here is the structural problem those facts create. XAA positions Okta's secure token service as the global trust anchor for every agent authorization decision in the enterprise. Compromise the STS, and you can mint valid ID-JAG tokens for any agent, with any scope, carrying any sub claim. The audit trail will look perfect. It will show a legitimate human subject delegating to a legitimate agent for a legitimate tool call. The forgery is in the anchor, not the record.

I have seen this pattern before. My 2021 provenance work on a digital art collection turned on tracing a deployer wallet to three previously flagged addresses. The collection's public story was immaculate. The ledger entries were internally consistent. The problem was the origin of the authority that signed them. Once you establish that the signer is compromised, every downstream record inherits the compromise, and the consistency of the records becomes a liability rather than an assurance — it makes the forgery harder to detect, not easier.

A company that has suffered a compromise of its own trust chain is now asking enterprises to route every agent authorization decision through that trust chain. That is not a fatal objection. It is a question that must be answered with architecture: gateway sharding, per-tenant isolation, hardware-backed key custody, blast-radius containment, independent attestation. The coverage raises none of it, and a security buyer who reads the coverage and not the threat model is making a decision on incomplete information.

The ledger does not lie, but it forgets. It forgets to ask who signed.

Authorization is not security

This is the categorical error, and it is the one I most want the reader to carry away.

The coverage frames identity governance as the solution to agent security. It is not. It is the solution to agent authorization, which is a strictly narrower problem.

Consider the canonical agent attack: prompt injection. An agent processes untrusted content — a web page, an email, a document, a tool response — and that content contains instructions. The agent, which cannot reliably distinguish instructions from data, follows them.

Now run that attack against a perfectly implemented XAA deployment. The agent has a valid ID-JAG token. The token is correctly downscoped to the current task. The audience binding is correct. The sub claim correctly identifies the human who initiated the session. The act claim correctly identifies the agent. Everything is valid. Everything is authorized.

The attacker does not need to forge a token. The attacker needs the agent to use its legitimate, correctly scoped, properly delegated token to do something the attacker wants — and because the agent's scope was defined by the task, and the task was defined by the user, the attacker simply has to make the malicious action look like part of the task. Send the email. Read the file. Call the refund API.

This is the confused deputy problem, and no amount of authorization rigor fixes it. It is an intent problem, not an identity problem. Authorization answers "may this principal do this?" It does not answer "does this principal's current action reflect the principal's actual intent?" Those are different questions and they require different controls — content provenance, instruction/data separation, output validation, human-in-the-loop checkpoints for irreversible operations.

What XAA genuinely mitigates, and I will credit it fully: credential leakage (no standing secret to steal), privilege creep (downscoping bounds each token), runaway agents (batch revocation and kill switch), and audit gaps (full delegation chain). Those are four real wins.

What it does not mitigate: prompt injection and confused deputy, agent supply chain compromise (a poisoned model or a malicious dependency in the agent's own code), data exfiltration within the token's legitimate scope (a read permission is a read permission), and multi-agent collusion or lateral movement amplified by agent-to-agent connection grants.

That last one deserves emphasis. Agent-to-Agent Connections is described as generally available. It is, by construction, a mechanism for granting one agent authority to invoke another. That is a lateral movement primitive. In a compromised environment, it is the edge in the graph an attacker traverses. The coverage describes it as a capability. It is a capability and an attack surface, and only one of those readings appears.

The governance tax and the audit ledger

Every control has a cost, and the coverage prices none of them.

The gateway records every interaction. Every tool call produces a token exchange event. Every token carries a delegation chain. Let me size the resulting ledger, using a mid-size deployment: five hundred agents, two thousand tool calls each per day. One million authorization events per day.

Each event, if it carries a full JWT with a nested act chain and the associated scope and audience metadata, plausibly lands between one and four kilobytes uncompressed. Call it two kilobytes. That is two gigabytes per day of raw authorization telemetry. Compressed at roughly 8:1, that is about 250 megabytes per day, or roughly 7.5 gigabytes per month, before retention policy, before indexing overhead, before the SIEM's own enrichment.

Scale to ten thousand agents at five thousand calls each: fifty million events per day, one hundred gigabytes raw, roughly twelve gigabytes compressed per day, three hundred sixty gigabytes per month. At a representative SIEM ingestion rate of two to three dollars per gigabyte, that is roughly seven hundred to eleven hundred dollars per month in ingestion alone, growing linearly with agent count and with retention. Add hot storage, add query compute, add the analyst hours to build detections against a telemetry shape nobody has written detections for yet.

None of this is prohibitive. All of it is real, and none of it appears in the announcement. Compare it to the human SSO baseline: a knowledge worker authenticates a handful of times per day. An agent authenticates thousands of times. The log volume ratio is three to four orders of magnitude. That is not an incremental change to the observability budget. It is a category change, and it is being sold as a feature.

There is a genuine secondary market here — Splunk, Datadog, Elastic, and the whole SIEM tier get a durable volume tailwind. That is worth noting for anyone tracking where the value from agent identity actually lands. Some of it lands in the identity vendor. A substantial fraction lands in the telemetry vendor, because the identity vendor's product is a log generator by design.

The regulatory tailwind nobody mentioned

The most conspicuous omission in the coverage is not a risk. It is an asset.

The European Union's AI Act imposes logging and human-oversight obligations on high-risk AI systems. The Digital Operational Resilience Act imposes ICT third-party risk management and incident-record obligations on financial entities. Sectoral regimes in health and government impose their own auditability requirements. All of them point in the same direction: demonstrable, reconstructable records of what an automated system did, on whose authority, with what oversight.

A cryptographically chained delegation record from a human subject through an agent to a tool call is, almost exactly, the artifact those regimes ask for. If XAA works, it is a compliance product as much as a security product, and the compliance buyer has a budget line and a deadline, which the security buyer often does not.

The coverage does not mention this. That is a strange omission for an announcement whose commercial thesis depends on expanding the billable identity base — because compliance is the fastest route to mandatory adoption, and mandatory adoption is the fastest route to seat expansion.

I will go further. If Okta is not positioning this as an EU AI Act Article 12 logging mechanism and a DORA third-party register artifact, it is leaving the strongest part of its own case unargued. The technical capability and the regulatory requirement are unusually well aligned here. The coverage treats the product as a security tool and misses that it is, potentially, a compliance ledger with a security use case attached.

Contrarian: What the Bulls Got Right

I have spent several thousand words on the structure's weaknesses. Intellectual honesty requires the other column, and it is not short.

The static key model is genuinely indefensible, and someone had to say so loudly. Every criticism I have made of the execution assumes the alternative is acceptable. It is not. Long-lived shared secrets in configuration files are the single largest cause of machine-identity breaches, and the industry has known this for a decade while doing remarkably little about it. A vendor that forces the conversation — even prematurely, even with a beta gateway — is performing a service. The direction of travel is correct. Short-lived, scoped, revocable, attributable credentials are where every serious architecture lands.

The composition is genuinely well-chosen. I called composition replicable, and it is. I did not call it easy. Getting sub and act nesting right, getting downscoping semantics right, getting audience binding right, and getting revocation to propagate in seconds across a distributed enforcement plane is difficult engineering with a lot of failure modes. Choosing RFC 8693 as the substrate rather than inventing a bespoke token format was the correct call, and it is the kind of restraint that vendors with weaker engineering cultures do not exercise.

The neutral-layer thesis has a real historical precedent. Okta's entire franchise was built on being the independent identity layer in a world where Microsoft bundled identity into Windows and Active Directory. That strategy worked once. It worked because large enterprises are genuinely heterogeneous — AWS and GCP and Azure, multiple model providers, multiple agent frameworks — and heterogeneity is exactly the condition under which a neutral layer beats a bundled one. The bull case is not fantasy. It is the same case that worked in 2015.

Naming a flow before the standard lands is rational, if cynical. Standards bodies move at the speed of consensus, and consensus is slow. A vendor that waits for an RFC to publish before shipping has ceded the vocabulary to whoever moved first. Salesforce did it with Agentforce. Every platform company does it. The naming gambit is a legitimate competitive move, and criticizing it as though it were deception mistakes tactics for ethics.

And the core insight — that infrastructure, not model quality, is the adoption bottleneck — is directionally right even if it is oversimplified. Yes, the coverage flattens a multi-causal problem (data quality, unclear ROI, process redesign, unclear accountability) into a single cause. But of the causes on that list, identity and authorization are among the most tractable and the most obviously underbuilt. A vendor is allowed to attack the part of the problem it can solve.

Where I part company with the bulls is on the inference from all of this. Every one of those points supports the conclusion that agent identity is a real and important category. None of them supports the conclusion that Okta wins it, or that the current announcement reflects a shipped product rather than a positioning move. Those are separate claims, and the coverage fuses them.

Takeaway

Strip the announcement to its verifiable core and this is what remains: a correct protocol composition, built on a published specification, executing through a component that was in beta at launch, sold on a billing model that was not disclosed, validated by two mid-sized partners and one packaging manufacturer, in a category where the largest competitor can bundle an equivalent capability into a subscription the customer already owns, from a company whose own trust anchor was compromised three years ago, in a market where the de facto tool-invocation standard has a different authorization model that the announcement does not address.

Every one of those clauses is survivable. Several are fixable within two quarters. The gateway will reach GA. Pricing will be published. The reference customers will arrive or the product will not. ID-JAG will either advance through the IETF or it will not, and the market will route around whichever outcome occurs.

What is not survivable is the framing. A market does not build around a standard. A market builds around a shipped control that a buyer can put in a contract, benchmark under load, and fail over from. Until the gateway publishes a p99 latency number and an availability commitment, until someone discloses what an agent identity costs per month, until a regulated-industry customer signs a reference agreement — until then, what exists is a well-argued design document with a press release attached.

I will be watching three numbers, and none of them are in the announcement. The gateway's p99 added latency, because that number determines whether XAA is infrastructure or decoration. The availability SLA, because 0.999^n is unforgiving and the exponent is set by agent complexity, not by the vendor. And the price per agent identity per month, because that number tells you whether this is a security control or a growth narrative wearing a security control's clothes.

When those three numbers publish, the ledger will balance or it will not. Until then, the entry reads: authorized, unverified.

The ledger does not lie, but it forgets. It forgets what was never entered. And the most important lines in this one — the latency, the SLA, the price — have not been entered yet.

Audit complete. Verdict pending, and the pending is the story.