MCP permission management

The control gap

Permission models implemented separately in every MCP server become inconsistent, while connection-level credentials often expose more tools than a particular agent requires.

Represent permissions as relationships that can be reviewed: client to server, agent to tool, delegator to task, and action to resource. A connection-level OAuth scope may remain necessary for transport, but it should not be the only expression of authority. Version service-owner rules separately from organization-wide minimums so one team cannot accidentally weaken a baseline deny.

Permission reviews should combine advertised tools, published policy, and observed invocations. An advertised but never used destructive tool may need removal at the server. A commonly denied tool may reveal an unapproved client or broken mapping. An allowed tool used against only one repository is a candidate for resource narrowing, subject to simulation and owner review.

What good looks like

A shared policy vocabulary manages client-to-tool and agent-to-resource permissions while server-native authorization remains the hard downstream boundary.

• Per-tool policy
• Client and agent separation
• Environment baselines
• Observed-use reviews

A production workflow

1. Inventory servers and tools
2. Assign stable identities
3. Publish baseline access rules
4. Review observed exceptions

Evidence to require

• Advertised and invoked tools
• Policy coverage by server
• Denied unknown tools
• Unused permission candidates

Buyer checklist

• Can the product enforce a decision before the external tool executes?
• Can policy distinguish the agent, delegated user, tool, resource, and environment?
• Can reviewers see the exact requested action and approve it without broadening future access?
• Does every allow, deny, and approval retain the policy version and reason?