Connecting a couple of MCP servers to your own editor is easy. Rolling MCP out to a team of ten, thirty, or a hundred people is a different problem entirely — and it is a governance problem, not a technical one. The question stops being “how do I connect this server?” and becomes “who is allowed to use which tools, and how do I prove it?”
Here is how to apply two well-worn security principles — least privilege and role-based access control — to MCP, without drowning in shared API keys and spreadsheets.
Why shared keys and per-app config break down
The default way people set up MCP — each person pasting servers and API keys into their own client config — falls apart the moment more than one person is involved:
- No attribution. A shared key means every action looks the same. When something goes wrong, you cannot tell who (or which agent) did it.
- No revocation. To cut off one person, you have to rotate the key for everyone.
- Everyone sees everything. If the whole team shares one configuration, the intern’s assistant has the same reach as the staff engineer’s.
Security guidance for Claude and Cursor deployments is now explicit about this: different teams should connect to role-scoped MCP configurations, not a single shared setup with universal tool access.
Least privilege for MCP
Least privilege means each person and each agent gets the minimum access needed to do the job — nothing more. In MCP terms: start read-only, expand to write access only when there is a concrete need, and keep destructive tools gated. “Allow all tools” is the opposite of least privilege, and it is where most incidents start.
Role-based access control (RBAC) for tools
RBAC groups people by role and grants access to roles, not individuals. Applied to MCP, this means building role-specific tool collections: the marketing team gets CRM and analytics tools; engineering gets Git, deployment, and monitoring; support gets the ticketing server — and none of them can reach the others’ tools.
This is far easier to reason about than per-person grants. When someone changes roles, you move them between groups instead of re-auditing a dozen individual permissions.
Per-client rules, not just per-person
A subtlety unique to AI tooling: the same person may use multiple clients with very different risk profiles. An autonomous agent running unattended should probably not have the same powers as the same engineer’s interactive editor session. Good MCP access control lets you set rules per client, not only per user — so Claude and Cursor, or an agent and a human, can carry different permissions.
Onboarding and offboarding
The real test of access control is the day someone joins or leaves. New hires should get exactly the tools their team uses on day one, without a manual scavenger hunt. When someone leaves, their access should disappear in a single action — not linger in a config file on a laptop or a shared key nobody wants to rotate.
The bottom line
MCP access control is not about slowing your team down — it is about making it safe to say yes. When every team has exactly the tools it needs and nothing it doesn’t, you can adopt more servers with less risk. Start with least privilege, organize with roles, and make onboarding and offboarding a single action.