Aembit has become the first third-party enforcement point for Okta’s Cross App Access (XAA) protocol, the agent identity standard Okta formalized at Oktane in September 2026. XAA is the open protocol Okta led that became the official Enterprise-Managed Authorization (EMA) extension for MCP. Aembit’s implementation provides enforcement capabilities that Okta’s own platform does not ship – specifically, runtime policy enforcement for agent-to-API access decisions. This is the XAA ecosystem forming: Okta defines the standard, third parties build enforcement layers on top.
The ecosystem is forming faster than the MCP ecosystem did. Okta defined the standard, and within weeks a third-party enforcement layer appeared. This mirrors the early MCP adoption pattern but compressed – identity is moving faster than tool integration because enterprises already know they need identity governance before they deploy agents.
Aembit’s approach is structurally distinct from other identity providers entering the agent space. Rather than building a standalone identity product, Aembit brokers what it calls “blended identity” – the ability to translate between XAA’s agent-native identity model and the legacy authentication systems most enterprises actually run. This is the integration problem that matters: enterprises cannot rip out their existing SSO, OAuth, and service-account infrastructure to deploy agents. They need a translation layer.
The Okta XAA ecosystem now includes partners beyond Aembit: Cloudflare, Keycloak, Scalekit, WorkOS, and Zuplo. Early adopters of the protocol include Anthropic, Zoom, Slack, and Microsoft. The breadth of the partner list suggests XAA is not a single-vendor play but an emerging standard with cross-vendor support – the kind of adoption curve that makes protocols sticky.
The connection to the broader agent infrastructure commoditization pattern is direct. When Okta, Microsoft, and Snowflake all ship agent identity within the same quarter, identity becomes table stakes. The enforcement layer – the runtime policy decisions about what an agent can actually do once authenticated – is where the differentiated value lives. Aembit’s XAA implementation is a bet that enforcement, not authentication, is the real moat.
This extends the harness pattern coverage Forkast has tracked since August. The architecture is consolidating: identity (Okta XAA, SSOJet, multiple MCP auth mechanisms), events (MCP Events from DevDay), sandboxes (Cloudflare, Vercel, OpenClaw), and governance (NVIDIA OASP, OpenClaw). Each layer is commoditizing. The enforcement decision – which APIs an agent calls, which data it touches, which actions it takes – is the layer that cannot be standardized away.
The timing matters. Enterprises deploying agents face a structural choice: authenticate agents at the perimeter (Okta’s native XAA support) or enforce agent behavior at runtime (Aembit’s enforcement point). Most will need both. The question is which layer captures the governance premium. If enforcement proves to be the binding constraint on agent deployment – the layer that determines whether agents can actually execute in production – then Aembit’s early position as the first third-party enforcement point gives it a structural advantage as the ecosystem scales.