For fifteen years the pattern for letting a tool talk to your identity provider was the same: mint a machine-to-machine credential with every scope you might need, drop it in an environment variable, and promise yourself you’d rotate it. You didn’t. Nobody did.
The Auth0 MCP Server is a chance to not do that again — and I’m genuinely surprised how many people are about to do it again anyway, just with an LLM in the loop this time.
Here’s what’s actually on the table. Auth0 published guidance on pairing Claude Code with their MCP Server so the agent can hit the Management API from your terminal. Model Context Protocol is the plumbing: a standard way for an LLM client to discover and call external tools. The MCP server is a small local process that advertises a set of operations — list applications, read a resource server, create a client grant — and brokers them against Auth0 using an access token you authorised. Claude doesn’t get your dashboard. It gets a defined menu, and only the items you let onto the menu.
That distinction is the whole story. So let me hand the mic to the colleague who’s been glaring at me since I said “AI” and “Management API” in the same sentence.
“You want to give a chatbot write access to my tenant.”
No. I want to give it read access to the three object types it needs for the task in front of it, scoped to a token that dies in an hour, and I want every call it makes stamped in your logs. That’s a different proposition from “a chatbot.”
The setup is a device-authorisation flow, not a static secret. You run:
The token is stored in the system keychain, not a plaintext file, and it carries only the scopes you consented to during that browser step. If you want the belt-and-braces version, provision a dedicated M2M application yourself in Applications → Applications → Create → Machine to Machine, authorise it against the Auth0 Management API, and tick scopes by hand. For a config auditor, that list is short and boring on purpose:
read:clientsandread:client_keysread:resource_serversread:connectionsread:client_grantsread:logs(so the agent can explain its own footprint)
Then shorten the token lifetime on the resource server. Default M2M tokens live 86,400 seconds — a full day. For an agent session, drop it:
“Scopes on a token. Groundbreaking. We’ve had RBAC for a decade.”
We have, and that’s exactly my point — this isn’t new, it’s the return of something we abandoned the moment it got inconvenient. The industry’s actual practice drifted toward one over-privileged service account per integration because requesting granular scopes was annoying and nobody audited the result. MCP doesn’t invent least privilege. It just moves the enforcement point back to where it belongs and makes the lazy path slightly harder than the correct one.
And there’s a control the old pattern never had: Claude Code asks before it acts. Every tool invocation surfaces in the terminal as a confirmation prompt — the operation, the arguments — and waits for you. A cron job with an admin token doesn’t do that. A human copy-pasting curl commands at 11pm certainly doesn’t.
“The agent will still do something dumb and I’ll find out in six months.”
You’ll find out in about four seconds, because Management API calls land in your tenant logs. Go to Monitoring → Logs and filter by event type. Every successful operation is sapi (Success API Operation); failures are fapi. Pin it to the agent’s application and you have a clean, attributable trail:
Or in the dashboard search bar: type:"sapi" AND client_name:"Claude MCP". Each entry shows the operation, timestamp, source IP and the token’s client. This is the part people skip, and it’s the part that makes the whole arrangement defensible to an auditor. If you can’t answer “what did the agent touch,” you haven’t deployed an integration, you’ve deployed a liability.
What a session actually looks like
Say you want to know which applications are still signing ID tokens with HS256 — the shared-secret algorithm that turns one leaked client secret into token forgery. Old way: click through every application in the dashboard, or write the pagination loop yourself. New way:
That ran entirely on read:clients. Claude could not have flipped those apps to RS256 even if it decided to be helpful, because update:clients was never on the token. If you do want it scaffolding a new M2M app, you grant create:clients and create:client_grants deliberately, for that session, and you watch the confirmation prompts. Then you revoke them.
Which brings me to the list you should tape to your monitor. Never put these on an agent token, no matter how convenient the demo is:
delete:users— one hallucinated loop and your directory is a craterupdate:tenant_settings— session timeouts, MFA policy, the whole tenant’s posturedelete:clients/delete:resource_servers— irreversible, and the blast radius is everything downstreamcreate:client_grantsleft on permanently — that’s privilege escalation with extra steps
Honest caveats, because the vendor post is light on them: the MCP ecosystem is young and the server is evolving fast, so pin your version and read the changelog before you let it near production. The token sits in your local keychain, which means your developer workstation is now part of the identity trust boundary — treat it accordingly. And the human-approval prompts are only a control if humans actually read them instead of mashing y.
The real shift isn’t “AI can call Auth0 now.” It’s that the cheapest way to let software touch your identity plane has finally moved from a god-mode secret in a file to a short-lived, scoped, logged token. We spent a decade knowing we should work that way. It took an LLM to make the right thing the default thing. Don’t waste that by handing it the keys anyway.