AI & MCP
MCP authorization: Roll out AI to every team, safely
Tiago Zien-Mendes
April 17, 2026 - 6 min read
For most companies, MCP is currently beyond the control of IT. Developers install servers on their own laptops. Teams wire up connections in whichever client they happen to use. Security has no visibility into what is being accessed, and IT has no mechanism to enforce policy on any of it. The result is the AI equivalent of shadow IT, rolled out at the pace of every new agent someone decides to try.
Today Speakeasy ships the layer that puts IT back in charge. MCP authorization lets you define roles, assign them to people, and scope access to specific MCP servers. Paired with the Speakeasy MCP registry, it lets IT stand up a single, sanctioned directory of MCP servers for the whole company and trust that it is correctly configured for every person who connects to it.
Why an IdP isn’t enough on its own
The first instinct for any team rolling out MCP is to federate it with the existing identity provider. It is the right instinct. It also does not finish the job.
The MCP spec’s vision is elegant. The identity provider mints a token scoped to exactly what the user is allowed to do. The MCP server validates the token. The downstream service honors the scopes. That model works for GitHub, Google Workspace, and a handful of other first-class providers, which together cover maybe 5% of what an enterprise actually connects to.
The other 95% are internal REST services and legacy systems. Most of them operate with a single static API key per account and no concept of “this user” at all.
So the IdP issues a token that says the user can read_invoice but not approve_payment. The MCP server validates it. Then the server turns around and calls the billing API using the one key it has, a key that can do anything. The fine-grained authorization evaporates the moment the call leaves the MCP server.
This is why authorization has to sit at the gateway. It is the only layer that can enforce user-aware policy against systems that were never designed to enforce it themselves: tool-level gating, request shaping, response filtering, and centralized audit, all at the point where the gateway already knows who the caller is and what the downstream API is about to do.
The IdP knows who the user is. The downstream APIs don’t. The gateway is where that gap gets closed.
Every tool call, authorized per user.
The checkpoint.
How it works
Four concepts to know.
System roles. Speakeasy ships with two default roles that cover the common cases out of the box: admin & member. Admins can do everything. Members can utilize the organization MCP servers that are permitted for their account. Most orgs start here, and for most teams the defaults are enough on day one.
Custom roles. As rollouts mature, the defaults can be adjusted and extended. An admin can define a new role, pick the exact permissions it grants, and assign it to specific people. Permissions are expressed as scopes like mcp:read, mcp:connect, mcp:write, build:read, build:write, and org:admin, so roles can be composed precisely. An “E-commerce MCP user” role, for example, can be limited to connecting to a single server and nothing else.
Per-server scoping. When you grant a permission like mcp:connect, you do not have to grant it across every MCP server in the organization. You pick the servers. That is what makes it safe to run an HR assistant and a production database MCP side by side in the same registry. The people with access to one are not automatically on the other.
Per-tool scoping. Access does not stop at the server. Inside each MCP server, a role can be narrowed to the specific tools it is allowed to call. Roles that only need to look things up get the read and list tools. Roles that need to act get write tools too. Tool lists can be composed by name or by tag, so a new read-only tool added to a server picks up the read-only policy automatically without an admin touching every role.
The effect is a directory that fits how real organizations work. Engineering gets broad access. Product gets the analytics and customer research servers. Sales gets the CRM. Security gets visibility into all of it through the audit log. Nobody sees what they should not.
Read-only access for the whole company
The most common ask from IT and security teams right now is to give every employee access to MCP while keeping them out of anything that writes. Per-tool scoping makes that the default pattern.
A “read-only” role can be assigned to the entire org on day one. Everyone gets the ability to query Salesforce, pull tickets from Jira, search the company wiki, and look up analytics through whichever AI agent they prefer. Nobody can close a ticket, create a record, update a CRM field, or post a message without an explicit role that grants those tools. The safe default is in place immediately, and admins can widen access for specific teams or individuals as trust grows.
The same pattern scales to more targeted roles. A support team can resolve tickets in Zendesk but cannot issue refunds in Stripe. A finance analyst can read from the data warehouse but cannot mutate it. An engineering on-call can execute runbooks in production while product managers on the same server are capped at read. All of it lives in one place, auditable, and synced from your identity provider.
Identity provider sync
Roles and permissions are only useful if they stay in sync with the rest of your identity infrastructure. Speakeasy plugs in directly.
Single sign-on and SCIM-based provisioning from your identity provider are both supported. Group membership in Okta, Entra, or whichever IdP you use flows through to Speakeasy roles automatically. Employee joins a team, the right access shows up. Employee leaves, it disappears. No wiki. No manual cleanup.
Get started
MCP authorization is rolling out to all organizations this week. Existing members are migrated into the default system roles, so nothing breaks. From there, admins can define custom roles, scope them to specific servers in the registry, and assign them to the right people.
The fastest path is to sign in, head to the Roles & permissions page in your org settings, and create your first custom role.
Planning an org-wide AI rollout? Book time with our team and we’ll walk through it with you.