Arcade.dev MCP Gateways give you a single URL that exposes a curated set of agent-optimized tools across any MCP client. Pick your tools, share the URL, and your agent can take real actions in GitHub, Linear, Slack, Salesforce, Google Workspace, and the rest of your stack. One gateway, every client, multi-user from the start. Anyone you share the gateway with gets that same allowed tool set, and runs every call under their own credentials.
The natural next question, once a gateway is working for a team, is how to put it in the hands of everyone in the business who could use it. Sales, support, finance, ops, engineering. Thousands of people across different departments, using different MCP clients. Giving each of them an Arcade account would mean handing thousands of users access to your administrative surface. You want the business to use your gateway, not manage it. And your security team wants users to access the gateway the same way they connect to any other internal app, with the standard corporate login they already have.
Arcade makes this easy. You connect your gateways to the identity provider your company already runs, so deploying an agent to ten people or ten thousand looks the same: your users open their MCP client, point it at the gateway URL, and sign in with the same SSO they use every day. Every tool call carries two identities, the agent’s permitted tool set defined by the gateway, and the user’s verified identity from your IdP. Arcade secures the agent access paired with the existing user identity from the enterprise IdP, so every call runs under the systems and policies your company already trusts.
How it works
From the MCP client’s perspective, the gateway is a standard OAuth 2.1 endpoint. Nothing to change on the client side. The user-facing login is delegated to whichever OIDC identity provider you already operate.
The gateway itself is a permission boundary on the agent. An agent connected to a gateway can only call the tools the gateway exposes, in the configuration your team set. Different teams can get different gateways with different tool sets, all assigned to users via applications in your enterprise IdP. The agent cannot reach past its own gateways.
You register your IdP connection once in the Arcade dashboard with three simple things: issuer URL, client ID, and client secret. From that point on, any gateway you stand up in the same project can use it. Configure once, reuse across any gateway you like. Or make many connections to separate your users for additional governance and control.
When a user connects an MCP client to the gateway, the gateway redirects them to your IdP. They authenticate using their normal corporate login via SSO. Then Arcade, building on that IdP access, issues access and refresh tokens scoped to the particular gateway, and the client uses those tokens for every subsequent tool call.
See it in action below:
What this enables for platform teams
One source of truth for identity. Your IdP already runs SSO, MFA, group policies, and provisioning. Users authenticated through a gateway inherit all of it. When someone changes roles or leaves the company, their access to every gateway updates with everything else. You don’t run a parallel directory for your AI tooling.
Two verified identities on every call. Every tool call carries the agent’s permitted tool set, defined by the gateway, and the user’s identity, carried as a cryptographically verified token rooted to your IdP. The effective permission for any action is the intersection of the two: the agent can only do what it’s allowed to do, on systems the user is allowed to touch. The audit trail names a real human, which is what your security and compliance teams need.
A clean separation between operators and users. The people configuring gateways are a small set of admins on your team. The people consuming them are everyone else. End users have no access to gateway configuration, project settings, or any administrative surface. The control plane stays yours.
One approved pattern for every rollout. You get your security team to bless the OIDC integration once. After that, every new gateway your team stands up can inherit the same auth model. New use cases are not new reviews.
What end users experience
If you’re one of the people using these agents day to day, this should be invisible.
Open Cursor, Claude Desktop, ChatGPT, GitHub Copilot, or any other MCP client. Add the gateway URL your team gave you. The OIDC flow opens your corporate login, the same one you sign into every morning. Sign in. Once you’re through, your agent has a curated, reliable set of tools waiting for it: the ability to act in GitHub, Linear, Slack, Salesforce, Google Workspace, and whatever else your team chose to put in the gateway, all under your real identity and scoped permissions. Tokens refresh in the background. Your agents can start actually doing things.
Get started
The gateway enhancement is now available and works with any OIDC identity provider you already run, including Entra ID, Okta, Auth0, Clerk, and Stytch.
Spin up a gateway, point it at your IdP, and roll it out to all of your users.
