It fails when organisations keep using application-level RBAC for tool actions that need narrower control. A user may need read access to one function but no export capability, even if both functions touch the same API. Without function-level scopes, AI tool access becomes broader than the task requires.
Why function-level authorisation breaks down in enterprise MCP use
Function-level authorisation fails when the control point stays at the application or API wrapper instead of the individual tool action. In enterprise MCP, that means one broad role or token can still unlock multiple functions inside the same integration, even when the user only needs one narrow action. The gap appears when task intent, tool scope, and enforcement scope do not match.
In practice, the failure is usually caused by reused roles, coarse scopes, or a gateway that treats the MCP server as a single protected resource. That works for basic access, but not for authorising one function to read and a different function to export, approve, or write. The result is not broken login, it is broken granularity.
That distinction matters because enterprise MCP often sits between a human request and an AI tool chain, so the authorisation decision needs to track the exact operation, not just the session. For a useful complement on the broader model choices behind this, see Authorisation Models Guide and AI Agent Authorisation Guide.
Where the control boundary gets too coarse
MCP implementations commonly expose several tools through one server, one client registration, or one delegated token path. If the enterprise maps access at that level, every tool behind that boundary inherits the same authority. That is acceptable only when all functions have the same sensitivity and the same business meaning, which is rarely true.
The practical failure mode is over-broad entitlement. A user can be correctly allowed into the workflow, but still receive capabilities that exceed the task. Read-only retrieval, record export, ticket closure, admin lookup, and data mutation should not be treated as equivalent just because they are reachable through the same MCP endpoint.
This is why function-level control is closer to fine-grained authorisation than to ordinary role assignment. It asks what the caller may do at the action level, not merely whether the caller may enter the system. Enterprise teams often discover the gap only after the first tool set grows beyond the original use case.
For MCP-specific enforcement details, the Model Context Protocol: Authorization specification is the clearest reference for keeping tokens audience-bound and avoiding token passthrough.
What needs to change in enterprise design
The answer is to authorise by function, not just by application or session. That usually means separate policy decisions for distinct tools, distinct actions, or distinct data effects. If the same user can view a record but not export it, the policy must express that difference explicitly, rather than inheriting a broad application role.
Enterprise MCP designs also need a clean separation between authentication and authorisation. Authentication proves who or what is calling; authorisation decides which tool action is allowed in that moment. If those layers are blurred, teams tend to over-trust the presence of a valid token and under-specify the action scope.
Good design also avoids assuming that one server-wide policy can safely cover every future tool. As tool catalogs expand, the policy model must be able to distinguish read, write, approve, delete, and bulk-export style operations. The more reusable the MCP server becomes, the more dangerous a one-size-fits-all permission model becomes.
That is why the wider MCP security pattern matters here, and why the MCP Security Guide is useful alongside the protocol specification when you are designing a real enterprise deployment.
Risk and Threat Considerations
Coarse authorisation in MCP creates privilege creep at the tool layer. The immediate risk is overreach, where a valid user or agent can trigger a sensitive function that was never intended for that task. The deeper risk is that one exposed function often becomes an easy path to data exfiltration, destructive actions, or lateral misuse across other tools.
Failure mechanism: A broad role, shared scope, or server-level token is reused across multiple MCP functions, so the access check never distinguishes between low-risk and high-risk actions. Once that happens, any tool that shares the same boundary inherits the highest privilege in the set.
Impact: A seemingly ordinary request can result in unauthorized export, modification, or delegated misuse, and the weakness is especially attractive when the same AI workflow can chain several functions together without a fresh decision point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tool actions need per-function enforcement, not broad app roles. |
| API1 — Broken Object Level Authorization | Tool calls often expose record-level access when function scope is too broad. | |
| Recommendation — Map each MCP tool action to a distinct authorization check and deny shared server-wide privilege. Enforce object-level checks on every MCP request that touches sensitive records. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Enterprise MCP authorisation should limit tool authority to the task needed. |
| IA-5 — Authenticator Management | MCP deployments rely on token and credential handling to separate access paths. | |
| Recommendation — Restrict each tool and action to the minimum privilege required for the request. Manage tokens and secrets so they cannot be reused beyond the intended scope. | ||
| NIST Zero Trust (SP 800-207) | none — Least privilege access | MCP access should be verified and constrained at each tool decision point. |
| Recommendation — Apply per-request verification and narrow permissions to each MCP action. | ||
| OWASP ASVS | V8 — Authorization | Tool-level decisions in MCP are an authorization problem requiring granular checks. |
| Recommendation — Verify that each protected action has its own authorization rule and test it directly. | ||
Practitioner Guidance
What to verify: Confirm that each sensitive MCP tool has its own policy decision or equivalent control point, and that the decision evaluates the action being requested, not just the caller’s general role. If two functions have different business impact, they should not depend on the same broad allow rule.
Decision rule: If a tool can change state, move data out of scope, or trigger downstream actions, treat it as a separate authorisation class. If a function only reads non-sensitive context, it can remain simpler, but it still should not inherit permissions from unrelated actions by default.
What practitioners underestimate: The hardest part is not proving that the user is legitimate, it is preventing legitimate access from becoming unintended authority. In MCP environments, the safest operating assumption is that every tool with a distinct consequence needs a distinct authorisation story.
Practitioner takeaway: Function-level authorisation fails when teams confuse “allowed into the MCP server” with “allowed to perform this specific action,” so the control must be attached to the tool effect, not the integration as a whole.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org