WorkOS has written the best reading of Sierra’s MCP gateway field notes I have seen, and it is really a post about what an MCP gateway is. In The hard part of an MCP gateway is auth, Maria Paktiti takes Mihai Parparita’s account of Sierra’s internal gateway, where 89% of employees now connect agents to 45 different services from a single page, and separates the tip from the iceberg. The tip is the part that demos. The submerged mass is identity, per-tool scopes, consent, and audit. The two sentences that carry the piece: “The gateway was a feature. The authorization model was the product.” And the conclusion: “The iceberg is not an argument against building. It is an argument against every company rebuilding the same submerged mass in parallel.”
The 89% and 45 are Sierra’s numbers reported by WorkOS, and they are the least important thing in the post. What survives is the table. Seven primitives, each named as the thing Sierra built and the standard thing it corresponds to: per-tool scopes with org-scoped queries; an audit log event on every meaningful tool call; session-scoped, time-boxed, human-approved authorization for exceptions; agent credentials carrying an act claim naming the human who authorized them; least-privilege service accounts for scheduled work; pre-authorized workflows declaring their reach; and, for agents arriving from any client, Client ID Metadata Documents. That last row is the one worth reading twice. “The MCP 2026-07-28 spec deprecated DCR in favor of Client ID Metadata Documents, keeping DCR only for backward compatibility.” The post also describes the discovery chain: an unauthenticated call returns a WWW-Authenticate header pointing at protected resource metadata, which points at authorization server metadata, plus a generated auth.md written for an agent rather than a person.
The catalog can check WorkOS against its own table. The WorkOS provider page lists 41 API pages, and the primitives land on specific ones. The audit event on every tool call is the WorkOS Audit Logs API. Per-tool scopes and named permissions are the WorkOS Permissions API and the WorkOS Authorization API. The session that delivers user, org, role, and permissions to a tool is the WorkOS User Management.session Tokens API. The agentic access profile maps 172 operations, 96 of them acting and 96 flagged human-in-the-loop, which is what an identity platform’s surface should look like.
The Kin Score is 59.4, strong band, carried by contract quality at 68.6 and operational transparency at 65.8, with contract governance at 28.8. The Agent Readiness score is 59.7, agent-ready, the highest of the three providers profiled today, and the identity layer is lit end to end: delegated identity, which is the act claim; protected resource metadata, which is the WWW-Authenticate pointer; and dynamic client registration, which the post itself says the spec has now deprecated, so WorkOS is ahead of our rubric and the rubric owes it a Client ID Metadata Document check. Idempotency is lit. Two gaps hold the band at agent-ready. Consent identity is unlit, and that is the third row of WorkOS’s own table, the session-scoped human approval. Error semantics is unlit, which was the finding the last time this series wrote about WorkOS. The company has published the clearest map of the authorization iceberg. Its own record shows most of it above the waterline, and the same two rocks still under.