Clerk's agent and MCP auth push: CIMD, custom scopes and the device flow

When Clerk raised a $50 million Series C in October 2025, led by Menlo Ventures and Anthropic's Anthology Fund, it said the money would build a new product line around agent identity. In its announcement, Clerk wrote that "agents need a new authentication solution: one that lets them act on behalf of humans with fine-grained permissions."

Eleven months later, that work is now in the product. Between late July and late September 2026, Clerk shipped a run of OAuth features. Most are aimed at one use case: letting an AI client, such as Claude, Cursor or a coding agent, connect to your MCP server and act as a signed-in user.

Here is what shipped, in order, and what it means. For the rest of Clerk's recent releases, see What's new at Clerk: August–September 2026.

The timeline

Client ID Metadata Documents: sign-in without registering first

The hard part of OAuth for MCP is that your server does not know the client ahead of time. Traditional OAuth expects every app to be registered first and given a client ID and secret. That works for a handful of partners. It does not work when any user can point any AI tool at your server.

Client ID Metadata Documents (CIMD) fix this by making the client ID an HTTPS URL. The client publishes a small metadata document at that URL, and Clerk reads it to check the client's details and allowed redirect URIs. Clerk says this gives MCP and other public OAuth clients "a stable identity without a pre-issued client ID, client secret, or Dynamic Client Registration."

CIMD entered beta on 6 August and became generally available on 21 September. Clerk says it is now available in every application, but it stays off until you turn it on:

1. Open the OAuth applications settings in the Clerk Dashboard.
2. Under Client onboarding, turn on Publish CIMD support, which advertises it in your authorization server metadata.
3. If you want to approve clients one at a time, set Client admission to "Pre-registered clients only" and allow trusted client URLs yourself.

The third step is the important one. With open admission, any client that publishes valid metadata can start an OAuth flow. Your users still have to consent, but you have not approved the client in advance.

Custom OAuth scopes: permissions that fit your tools

Before 21 August, scopes were mostly about identity: profile, email and so on. Custom OAuth scopes let you define names that match your API, with Clerk's examples being messages:read, tools:execute, resources/files:read and mcp_all. You choose which scopes each OAuth application may request and which ones appear in your OAuth metadata.

Clerk is explicit about one thing: your API has to enforce them. Clerk issues a token that lists the granted scopes, and your server must verify the token and check the scopes before it runs a tool. If you skip that step, a messages:read token can do anything.

Device Authorization Grant: agents in the terminal

On 8 September Clerk added the OAuth Device Authorization Grant (RFC 8628). This is the familiar "go to this URL and enter this code" flow. The device or CLI shows a short code, the user approves it in a browser on another device, and the client polls until it gets a token. Clerk's Account Portal shows the approval screen, including the app, the requested permissions and, if needed, which organization to use. Approve and deny buttons get equal weight on that screen.

It works with both public clients (client ID only) and confidential ones (ID and secret). It does not need PKCE or redirect URIs. For agents this matters because many run in a terminal or on a server with no browser of their own.

Clerk's own MCP server, in one command

The 22 July release is aimed at developers who use Clerk rather than their end users. clerk mcp install detects which AI clients are on your machine and registers Clerk's MCP server in them. Clerk lists ten: Claude Code, Cursor, GitHub Copilot (VS Code), Windsurf, Gemini CLI, Codex, opencode, OpenClaw, Warp and Hermes Agent. It uses a stdio-to-HTTP bridge built into the CLI instead of npx mcp-remote, and a new clerk doctor command checks the connection. This builds on the Clerk CLI that launched in April.

What it means for developers

• If you run an MCP server, Clerk now covers most of the authorization server side: discovery metadata, self-describing clients through CIMD, scopes and consent. What you still own is checking the token and its scopes on every request.
• Decide your admission policy on purpose. "Anyone with valid metadata" suits a public tool. "Pre-registered clients only" suits anything that touches customer data.
• Agents add a new way for things to fail. When Clerk's OAuth endpoints are degraded, your human users may already have sessions, but every agent trying to connect or refresh a token hits the problem at once. Clerk's scheduled database maintenance on 19 September listed OAuth endpoints among the operations that would be rejected for a few minutes. Our review of Clerk's summer incidents has more on what degrades and when.

If your agents suddenly can't authenticate, check Clerk's live status first. If your MCP server also runs on a platform we monitor, such as Vercel or Cloudflare, check that too before you start debugging your own code.

---

Sources

• Committing to Agent Identity: Clerk raises $50m Series C from Menlo and Anthropic's Anthology Fund (Clerk)
• Connect your AI tools to Clerk MCP with one command (Clerk changelog)
• Configurable default OAuth scopes (Clerk changelog)
• Connect OAuth clients with Client ID Metadata Documents (Clerk changelog)
• Custom OAuth scopes (Clerk changelog)
• OAuth Device Authorization Grant (Clerk changelog)
• Client ID Metadata Documents are now generally available (Clerk changelog)
• Scheduled database maintenance, 19 September 2026 (Clerk status page)