MCP Permissions in Teams: The Problem Nobody Solved Yet

I’ve been using Devin with our Slack workspace for a while now. It’s connected to GitHub, PagerDuty, Sentry, and a handful of other MCPs. Works great for individual productivity. But there’s a problem I keep running into that nobody seems to be talking about.

Anyone on the team can use any MCP with full access.

A new hire who’s still learning the codebase? They can ask Devin to create a PR on your production infrastructure repo. Someone outside of engineering who’s just curious about what Devin can do? They could accidentally trigger a PagerDuty incident. The person in #random testing prompts? Same access as your most senior engineers in #deployments.

Why This Matters More Than You’d Think

When you connect an MCP to something like Devin, you’re essentially giving that capability to everyone who can message the bot. There’s no “this user can only read from GitHub” or “this channel only gets access to documentation tools.”

It’s all or nothing.

For a solo developer, that’s fine. For a growing team with different roles and experience levels? It’s a disaster waiting to happen. I’ve already had to have conversations about “please don’t use the GitHub MCP unless you know what you’re doing.” That’s not a scalable solution.

What We Actually Need

The core problem is that MCPs don’t know anything about the context they’re being called from. They don’t know:

• Who is making the request (new hire vs. someone senior)
• Where the request came from (production channel vs. playground channel)
• What the user should be allowed to do (read-only vs. full access)

So the question becomes: where do we add that layer?

Idea 1: A Permission MCP

What if there was an MCP whose only job is answering “can this user do this thing?”

Before any other MCP executes, it checks with the permission MCP: “User alice in channel #deployments wants to use github.create_pull_request on repo infrastructure. Allow?”

The permission MCP consults some policy configuration and returns yes or no.

This keeps the actual MCPs unchanged. They don’t need to understand permissions. They just need to ask before doing anything destructive.

The tricky part: who enforces that check? The MCPs themselves don’t have an incentive to ask. You’d need the AI tool (Devin, Claude, etc.) to enforce it, which means waiting for them to build that feature.

Idea 2: A Proxy Gateway

Instead of connecting MCPs directly to your AI tool, route everything through a proxy. The proxy receives MCP calls, checks permissions, and either forwards the request or blocks it.

Devin → Proxy MCP → GitHub MCP
                  → PagerDuty MCP
                  → Sentry MCP

The proxy has all the context: it knows who made the Slack message, what channel it came from, what action is being requested. It can enforce whatever policy you want.

This is more work to set up, but it doesn’t require any changes to existing MCPs or to Devin itself. You’re just adding a layer in front.

The downside: you’re maintaining another piece of infrastructure. And every MCP call has extra latency.

Idea 3: Context-Aware MCP Servers

This one requires MCP server authors to do the work, but hear me out.

What if MCP servers could receive context about who’s calling them? The AI tool would pass along metadata: user ID, channel, role, whatever. The MCP server itself decides whether to allow the action.

This is probably the cleanest solution architecturally. GitHub MCP could have its own permissions: “user X can only read, user Y can create PRs on repos they own, user Z has full access.”

The problem: it requires buy-in from MCP authors. And it requires AI tools to pass that context consistently. The November 2025 MCP spec update added OAuth 2.1 support and better authentication flows, but that’s about proving who you are to an MCP server—not about differentiating permissions between teammates.

Idea 4: Just Run Multiple Instances

The hacky solution I’ve seen people actually do: run separate Devin instances with different MCP configurations.

• Instance A in #general — docs and read-only tools
• Instance B in #engineering — GitHub read, Sentry, logs
• Instance C in #platform — full access to everything

It works. It’s annoying. You lose the unified experience. But it’s something you can do today without waiting for anyone to build features.

What the Vendors Are Building

Slack recently announced they’re building their own MCP server with user-level permissions baked in. The idea is that their server enforces data access permissions for every request, so AI models only access what that specific user is authorized to see. Admins get control over which tools each AI assistant can access, plus logging to see exactly what happened.

Sounds great. It’s in closed beta though, with general availability sometime in early 2026. So not something you can use today.

IBM’s working on something similar with their MCP Context Forge project—multi-tenancy with user, team, and global scopes. Arcade.dev partnered with Anthropic to add OAuth authorization flows to MCP. The ecosystem is clearly moving in this direction.

But none of it is standardized. None of it works across vendors. And most of it isn’t production-ready yet.

What Might Actually Work Today?

I don’t think there’s one right answer yet. The ecosystem is clearly figuring this out.

If I had to bet, the proxy approach still feels most practical for teams right now. You control it. You don’t wait for vendors to ship features. You build exactly the policy layer you need.

The vendor solutions are coming. Slack’s MCP server looks promising. The OAuth 2.1 updates to the spec are a step in the right direction. But if you need something today, you’re either running multiple instances with different configs or building that proxy layer yourself.

For now, I’m thinking about building a janky proxy that at least adds some guardrails before someone accidentally pushes to main. By the time the “real” solutions ship, I’ll probably have learned enough to know exactly what I need from them.

The Conversation We Should Be Having

MCP is great for individual developers. But team adoption requires thinking about permissions, audit logs, rate limits, and all the other stuff that enterprise software deals with.

None of that exists in the MCP spec today. Maybe it should. Or maybe it should live in a layer above MCPs, in the AI tools themselves.

Either way, someone needs to solve it. Because “just trust everyone to be careful” doesn’t scale past about five people.