WorkOS MCP Auth: OAuth and Managed-Server Acceptance Matrix

WorkOS MCP can mean two different products. AuthKit can serve as the OAuth authorization server for an MCP resource server that your team builds. WorkOS also operates a remote MCP server that lets an agent manage a WorkOS workspace with the connected dashboard user's authority. The first path delegates token issuance and discovery while your application retains tool authorization. The second exposes selected WorkOS administration actions through a managed server.

TL;DR

• AuthKit for MCP issues OAuth access tokens for a resource server you operate; your server still verifies tokens and authorizes each resource or tool.
• The WorkOS managed MCP server inherits the connected dashboard role, uses one environment at a time and offers team controls for production and write access.
• Approve the two paths separately with tests for token audience, user identity, environment scope, destructive actions, secret handling and revocation.
• MCP transport and tool execution remain outside DeepInspect; only a separate authenticated HTTP call to an LLM enters its boundary when deliberately routed there.

WorkOS MCP has two distinct deployment paths

The AuthKit MCP guide is for application developers securing their own MCP server. It assigns AuthKit the authorization-server role and leaves the customer's MCP endpoint as the resource server. AuthKit supplies OAuth endpoints and tokens. The resource server publishes protected-resource metadata, verifies the token issuer and audience, then populates request context for its own authorization logic.

The WorkOS MCP server documentation describes a different route. WorkOS operates a remote server at mcp.workos.com/mcp that can read and change selected workspace data through the WorkOS API. Clients connect over streamable HTTP and authenticate with OAuth using WorkOS Connect. The agent acts as the connected dashboard account.

Draw them as separate systems. I would use blue for the MCP server your team operates and orange for the WorkOS-managed endpoint. A diagram that labels both boxes "WorkOS MCP" hides who owns token verification, tool authorization, runtime logs and rollback.

The MCP server authorization patterns guide provides the resource-level tests that sit after OAuth.

AuthKit delegates OAuth while your server keeps authority

AuthKit's documentation says the MCP server needs to verify access tokens and direct clients to AuthKit through standardized metadata. The example validates the issuer and the MCP server URL as the audience. It also returns a WWW-Authenticate challenge with the protected-resource metadata URL so clients can discover the authorization server after a 401 response.

That flow authenticates and scopes a token to a resource. Your MCP server still decides what the subject can do with each tool or resource. Build an acceptance matrix with the client identity, token subject, audience, expiration and requested resource, then add the application role, target object, tool effect and final decision.

Test a valid token against the correct server. Audience mismatch must fail closed. Replay the token against a second MCP endpoint, then try an expired token and a token from another issuer. Use a valid low-privilege user to request a write tool. The first three tests validate OAuth plumbing. The last test validates application authorization.

AuthKit supports literal and wildcard Resource Indicators. The guide says a wildcard can cover dynamic subdomains or trailing gateway paths and that a matching token receives the concrete requested URI as its audience. Treat wildcard registration as a scope-expansion decision. Enumerate every matching host or path pattern and deny an adjacent tenant route during acceptance.

Compatibility settings can widen the accepted route

AuthKit's Client ID Metadata Document support is off by default, according to the guide, while Dynamic Client Registration can remain available for older clients. The documentation also allows a default Resource Indicator for clients that omit the resource parameter. Old grants survive that change. Existing refresh-token authorizations keep their original audience after a default is set.

Record which registration mechanism each approved client uses. Capture the metadata document and redirect URIs, plus the requested resource and token audience. When a default resource is configured, test a client that omits the parameter and verify the exact audience it receives. Revoke prior refresh tokens or document their original audience before treating a configuration change as complete.

AuthKit describes an option where an MCP server proxies authorization-server metadata for clients that fetch the older location. Pin AuthKit as the upstream issuer and verify that the proxy cannot be redirected to an attacker-controlled metadata source.

The MCP security best-practices guide covers the surrounding client, server and transport inventory.

The managed WorkOS server inherits dashboard authority

WorkOS says its managed MCP server acts as the connected user and runs every operation through the dashboard's access controls. A read-only role cannot make changes, and an account without administrator rights cannot invoke admin-only actions. The server operates against one environment at a time, defaults to sandbox and reaches production only when directed and permitted.

Test that inheritance with dedicated accounts. Give one account read-only access and another narrowly scoped administrative rights. Ask both agents to read a known sandbox organization, then attempt a write and a production action. Capture the MCP response and the WorkOS audit event, along with the affected object. Switch the admin account back to sandbox and confirm that an old production context cannot carry into the next action.

WorkOS also documents three team controls, all enabled by default: MCP enablement, production access and write access. Toggle each control independently during the test. Existing sessions should lose the prohibited capability promptly. Record the delay and the user-facing error, then restore only the approved state.

The managed server requires explicit confirmation for documented irreversible operations such as deleting an organization, connection or directory. Run the test on a disposable sandbox object. Preserve the initial description and the confirmation step, then cancel once and confirm once. A confirmation screen is an interaction control; the underlying role and environment checks still need to pass.

Secrets and excluded actions define the ceiling

WorkOS says values such as API keys and client secrets are stripped from responses before they reach the agent, although the agent can set a secret supplied by the user. Test both directions with a disposable value. Existing secrets should be absent from returned tool output and chat context. A newly supplied secret should reach the intended field without appearing in the response or logs available to the agent.

The managed server intentionally omits several capabilities. The documentation says it cannot impersonate users, alter its own MCP access settings, mint or rotate credentials, or delete the WorkOS team. Add those exclusions to a negative test pack rather than assuming an undisclosed tool is absent. Save the discovered tool list and compare it after each release.

The MCP tool-call authorization guide provides the adjacent evidence fields for caller, tool, arguments, target authority and result. Use a stable correlation identifier where the client and WorkOS records expose one.

Keep DeepInspect allocation narrow

MCP OAuth, streamable HTTP sessions, resource discovery, tool invocation and WorkOS API mutations sit outside DeepInspect's model-request boundary. AuthKit tokens can prove identity and audience for an MCP server, but that token record says nothing about a separate prompt sent to an LLM. The managed WorkOS server's confirmation also says nothing about model-call policy.

If an agent separately calls an LLM through DeepInspect, the application can supply trusted identity context and a correlation identifier. DeepInspect can evaluate that authenticated HTTP model request and preserve the policy decision. The MCP server remains authoritative for tool permissions and destination writes.

Run a joined test with two events. First, deny a model request based on prompt policy and confirm that no downstream tool is called. Second, permit a harmless model request but deny the subsequent MCP write through the resource server. The resulting records should show two independent decisions rather than one blended green status.

DeepInspect

Route an agent's separate LLM call through DeepInspect when that request needs identity-bound prompt policy. DeepInspect evaluates supplied identity, prompt classification and model destination before forwarding an allowed call, then records the decision.

The customer's MCP server retains tool authority, while WorkOS controls its managed server and API operations. Correlation identifiers can connect those records to the model-call decision without treating one as proof for another. Book a technical deep dive at deepinspect.ai.