MCP access governance: who can use which tools and data

What MCP access governance means

The Model Context Protocol (MCP) lets AI clients such as Claude Code, Cursor or Codex connect to company systems through servers that offer tools: search a ticket queue, read a document, update a customer record. Each tool request reaches a system on someone’s behalf.

Access governance asks the questions your identity team already asks about any application, applied to those requests. Who can use this connection? Which tools and data does each person need? Who agreed to that access, and how quickly does it end when their role changes?

One difference matters. An agent chooses which tool to call and what to send, often based on content it has just read. A person may be entitled to a tool without intending every request an agent could make with it. That makes narrow permissions, and a clear record of each request, more important than usual.

Access is decided in layers

A single tool request passes several access decisions. Writing them down shows which system enforces each one and where gaps remain.

The upstream system’s own permissions are the outer limit. A gateway rule can narrow what someone may do through it, but it cannot grant permissions that their credential lacks.

Tie every request to a person

Shared API keys are a common place for access governance to break down. When everyone’s agent uses one token, the upstream system sees a single user, revoking it affects everybody, and the records cannot show who asked for what.

Prefer each person’s own authorization to the upstream system, usually through OAuth, and have them sign in to any gateway with your normal identity provider. The MCP authorization specification builds on OAuth 2.1. It expects a server to accept only tokens issued for it, and it forbids passing a client’s token straight through to another service.

Some work suits a service identity, such as a scheduled job with no person present. Give that identity an accountable owner, the narrowest permissions that work and its own records, so its activity is never mistaken for a person’s.

Grant access through teams

Assigning connections to people one at a time is hard to review and easy to forget. Assign them to teams instead, ideally groups that come from your identity provider, so new joiners receive the right access and leavers lose it when the directory changes.

Start narrow. Make a sensitive connection available to the team that needs it rather than the whole organization, then add conditions for particular tools or resources. In an illustrative finance team, everyone might read invoices in one folder while a smaller group can update payment details.

Watch for access that arrives indirectly. Someone in two teams may reach a connection through either one, so removing them from one team does not necessarily remove their access.

Keep agent access to what the work needs

OWASP lists excessive agency among the main risks for applications built on large language models. An agent given more functions, permissions or autonomy than its task requires can cause harm when it is misled or simply wrong. Prompt injection, where text the agent reads tries to redirect it, is one way that happens.

Least privilege for MCP works at three levels. Enable only the tools a workflow needs. Limit those tools to the resources the work involves. Request only the OAuth scopes the enabled tools require, because a connection’s token is generally available to every tool on that connection. The MCP security guidance recommends starting with minimal scopes and asking for more only when needed.

Reading deserves care as well as changing. A tool that can only read customer records can still expose them. A practical pattern is to give a pilot group read-only access, confirm that the boundaries hold, and allow changes once the team understands how the agent behaves.

Review access and test revocation

Access drifts. Projects end, people change teams and temporary exceptions become permanent. Include MCP connections in the access reviews you already run, with each connection’s owner confirming who should keep access. A useful review covers the points below.

Then test revocation directly. Remove a test member and repeat a request from a client that is already signed in. The request should be refused, and an earlier approval should not bring the access back.

• Who can use each connection today, and through which team or exception.
• Which tools and resources are enabled, and whether each is still needed.
• Whose credentials the connection uses and which scopes they grant.
• Which client sessions remain active, especially for people who have left.
• What was used during the period compared with what is allowed.

Separate requesting from approving

For actions with serious consequences, such as sending a payment, deleting records or emailing customers, access alone may not be enough. Another person can review the proposed action before it runs. That reviewer should not be the requester, and the decision should cover the specific action rather than grant open-ended permission.

Keep this review proportionate. Requiring review for every small action creates fatigue and makes the important requests harder to spot. Choose the actions that need review based on how much harm a mistake could cause.

Keep evidence of access and use

Two kinds of evidence answer different questions. Current access shows who could use a connection today and why. Request records show who did use it, what was decided and what happened next. An access review needs both.

Keep records proportionate. Decision records rarely need full prompts or responses, and storing those creates privacy obligations of its own. Records also cover only the routes they observe; requests that bypass the gateway need their own controls.

Where Durin fits

Durin applies access governance to MCP requests routed through its gateway. Each request must pass current identity, membership, team, connection, credential, reviewed tool, resource and inspection checks before the team’s rules apply. Connections can be scoped to teams, and team rules can add conditions for particular tools, resources or people.

People sign in to their own Durin endpoint, and upstream requests use the provider credential configured for that connection; Durin does not pass its own token to the provider. Revoking a membership or client session applies to later requests, and an earlier approval cannot restore access. Enterprise organizations can sync users and groups from their identity provider; local users, groups and invitations are available on every package.

Reviewed requests can proceed by default after those checks. Administrators can choose to deny tool access by default or require another administrator to review proposed changes. Access Graph shows who can use a connection today and why, while Audit shows the decisions recorded when requests ran. Requests that do not pass through Durin need their own controls.