What are the signs that MCP authorisation is too coarse?

How MCP authorisation becomes too coarse

MCP authorisation is too coarse when one approval or token quietly authorises far more than the current tool call needs. That usually means the policy is attached to a session, client, or broad role instead of the request itself. The result is not just excess access, but a loss of meaningful control over which action is being requested at that moment.

In a healthy design, the policy decision should track the tool, the target resource, the requested action, and the current context. If the same authorisation decision is reused across different tools, different scopes, or different users of the same agent, then the boundary has moved too far away from the actual operation. That is where coarse authorisation starts to create hidden privilege.

Another sign is when approvals are effectively binary, “is the agent signed in or not”, rather than conditional, “is this specific action acceptable right now”. In practice, that shows up as bearer tokens or delegated credentials that work across too many internal services, or as permissions that survive long after the immediate task should have ended. The MCP authorization specification is useful here because it frames authorisation around audience-bound tokens and avoids token passthrough for exactly this reason.

What the weak signals look like in logs and runtime behaviour

Coarse authorisation is often easiest to spot in the audit trail. If logs only show that a session existed, but not which tool was approved, which object was targeted, or why the decision was made, the control is too blunt to support investigation or review. A usable model should leave behind per-action evidence, not just login or connection events.

Runtime behaviour can also expose the problem. If an authenticated agent can pivot from one tool to another without a fresh policy check, the policy boundary is probably too broad. That is especially risky when the same credentials are accepted by internal services that were never meant to share equivalent trust. For a broader control perspective, OWASP API Security Top 10 helps frame the same pattern as broken authorisation at the interface boundary.

Another warning sign is when policy logic ignores request context that clearly matters, such as the target repository, tenant, environment, data sensitivity, or whether the action is read-only versus destructive. Once the policy stops distinguishing those cases, it is no longer protecting the operation, only the identity behind the session.

Why broad MCP scopes create hidden blast radius

The practical danger of coarse authorisation is blast radius. One overly broad scope can let a compromised agent, a malicious tool response, or an overtrusted integration reach many downstream services without additional checks. The issue is not only compromise, but also misrouting: the agent may do the wrong thing with valid credentials because nothing forces a new decision at the point of use.

That is why the most useful design shift is toward narrower, request-level decisions. The AI Agent Authorisation Guide is relevant because it treats least privilege as task-scoped and per-action, which is the right mental model for MCP tool access as well. Similarly, the Authorisation Models Guide is useful when you need to decide whether roles, attributes, or relationships are giving you enough precision for a given tool call.

Coarse scope also makes exception handling dangerous. Once broad access is accepted as normal, teams tend to add more tools behind the same privilege set instead of rethinking the policy shape. Over time that creates a default trust lane where very different actions look identical to the authoriser.

Risk and Threat Considerations

Coarse MCP authorisation increases the chance that a single compromised session, token, or delegated credential can be used across too many tools and services. That raises the impact of token theft, tool abuse, confused-deputy behaviour, and accidental misuse because the control no longer constrains the actual operation tightly enough.

Failure mechanism: A broad bearer token, shared scope, or session-level approval is reused for multiple actions, so an attacker or faulty agent can move from a low-risk request to a higher-impact one without meeting a fresh policy boundary.

Impact: The compromise or mistake spreads further than intended, making exfiltration, destructive actions, and internal lateral movement easier to achieve and harder to attribute.

Practitioner Guidance

What to verify: Check whether each tool call is evaluated against the specific resource, action, and context it touches. If the answer is “the token already allows it”, the policy is probably too coarse for MCP.

Decision rule: If a permission would still look reasonable after the agent changes task, target, or environment, it is too broad. Tighten the scope until a laterally reused credential no longer buys the same outcome across unrelated actions.

What good looks like: Each meaningful tool invocation produces a distinct authorisation decision, a distinct audit record, and a clear reason why that request was allowed. That is the minimum standard for detecting overreach before it becomes an incident.

Practitioner takeaway: In MCP, coarse authorisation is usually a sign that the control is protecting the session instead of the action, and that is the point where hidden privilege starts to accumulate.

Related resources from NHI Mgmt Group

• What are the signs that agent authorisation is too coarse?
• How can organizations secure their MCP server credentials?
• Why is OAuth considered a better alternative for MCP servers?
• Why is it crucial to adopt new authentication methods in MCP usage?