Because MCP turns tool access into machine-readable delegation, which can expand the number of systems an agent can reach without a person actively navigating each step. If those permissions are broad or inherited, the agent becomes a powerful execution path. Security teams need to design for action scope, not only for authentication events.
Why MCP Changes the Authorization Problem
MCP changes the authorization problem because it turns scattered tool access into a standardised delegation layer. The question is no longer just whether a user or agent can log in, but which tools, systems, and scopes that delegated execution path can reach. That shift makes permission design, not just session establishment, the control point that determines blast radius.
In practice, MCP makes the boundary between “can authenticate” and “can act” much more important. A narrowly scoped tool call may be low risk, but once the protocol allows the agent to chain actions across multiple services, inherited permissions can become an enterprise-wide execution path. That is why MCP security has to be read through a least-privilege lens, not a connectivity lens. See MCP Security Guide for the protocol-specific controls, and compare delegation patterns with AI Agent Authorisation Guide when you need task-scoped, per-action policy decisions.
MCP also raises the importance of how authorisation is expressed. Coarse roles, inherited entitlements, and broad bearer tokens can be perfectly valid from an authentication standpoint while still being too permissive for agentic execution. The same protocol can therefore be safe or unsafe depending on whether the organisation externalises authorisation and evaluates each action against the current task context, the target resource, and the intended tool chain. The underlying model is easier to govern when teams compare RBAC, ABAC, ReBAC, and policy-based controls explicitly, as laid out in Authorisation Models Guide.
Where MCP Authorization Breaks Down
The common failure mode is over-scoped delegation. If a client or gateway passes through a token that was never meant to represent the full downstream action set, the agent can inherit more authority than the user intended. That becomes more dangerous when tools are composed, because one apparently narrow request can unlock adjacent systems, write operations, or administrative APIs.
Another break point is hidden trust in the local or remote MCP server itself. If the server is treated as a simple transport adapter, teams may skip audience binding, resource-specific tokens, and clear server-side enforcement. In that case, a compromised or misconfigured server can become a confused deputy that relays authority farther than it should. The protocol draft matters here, because the Model Context Protocol: Authorization specification sets expectations for OAuth-based resource-server behaviour, and RFC 9728 matters where resource metadata is used to discover those protected endpoints.
Tool-routing mistakes also matter because MCP shifts the control plane closer to the action plane. If a gateway, registry, or broker approves access without understanding the target operation, the result is not just a login problem. It is an authorisation failure that may permit data exposure, destructive writes, or cross-system movement under the guise of normal automation.
What Security Teams Should Design For
Design for action scope, not just identity proof. The useful question is not “did the agent authenticate?” but “what exact action on which resource was authorised, for how long, and under which policy conditions?” That is why short-lived, task-scoped, and auditable delegation is more defensible than standing entitlements or reusable secrets. For machine-to-machine delegation patterns, the OAuth primitives in RFC 6749 and client assertion patterns in RFC 7523 are useful references when shared secrets are too blunt for the trust boundary.
Practitioners should also separate user intent from agent capability. If an agent can act on behalf of a person, the policy should describe which actions are allowed directly, which require step-up approval, and which must be blocked even when the user is entitled to the underlying application. That distinction is central to enterprise software because the same agent may touch ticketing, code, infrastructure, and data systems in one workflow. The risk is not only excess privilege, but also privilege that is valid in one system and dangerous in combination with another.
For teams standardising these controls, the most useful pattern is to pair protocol-level authorisation with policy-level governance. The right implementation is usually a narrow gateway plus explicit policy decisions at each sensitive tool boundary, rather than trusting the agent to stay “well behaved” once it has been authenticated. The protocol gives you delegation mechanics; the enterprise still has to define the permission model. For broader governance patterns, IAM and IGA Basics helps anchor the access-governance side of that decision.
Risk and Threat Considerations
MCP creates risk when delegated authority becomes broader, longer-lived, or less visible than the human owner expects. That can expose sensitive systems to unintended writes, privilege chaining, and lateral movement through trusted tools, especially when tokens or server permissions are reused across contexts.
Failure mechanism: An agent or MCP server inherits authorisation that was valid for one request but too broad for subsequent tool calls, or the protocol implementation fails to enforce audience-bound, resource-specific access.
Impact: Attackers or mistakes can turn a legitimate automation path into a high-trust execution path, leading to data exposure, destructive actions, or misuse of downstream systems without a clear human checkpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP delegates tool actions to agents, so privilege abuse is a direct risk. |
| ASI02 — Tool Misuse | MCP tool access can be misrouted or overused through delegated execution paths. | |
| Recommendation — Enforce per-action authorization for agent tool use and restrict delegated privileges. Gate each tool invocation with policy checks and limit what tools an agent can invoke. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP exposes callable functions, making function-level authorization central to risk. |
| API2 — Broken Authentication | MCP still depends on correct client and server authentication before authorization can work. | |
| Recommendation — Authorize each callable function separately and deny excess capability by default. Require strong client authentication and validate token audience before granting access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about broad delegated access and limiting action scope. |
| IA-9 — Service Identification and Authentication | MCP often involves services, agents, and servers authenticating to one another. | |
| AC-3 — Access Enforcement | MCP requires enforcement of action permissions at the resource boundary. | |
| Recommendation — Reduce delegated permissions to the minimum set needed for each task. Authenticate services and workloads explicitly before allowing tool access. Enforce authorisation at the point of action, not only at login. | ||
Practitioner Guidance
What to verify: Confirm that every sensitive MCP tool call is authorised against the target resource and action, not just the authenticated caller. If the same token can reach multiple systems, assume the blast radius is already too broad until proven otherwise.
Decision rule: If a permission cannot be described as “this agent may do this one action on this one resource for this one task,” treat it as overbroad. If approval is only checked at login time, the design is incomplete for agentic workloads.
Practitioner takeaway: The security boundary in MCP is the delegated action, not the connection itself, so authorisation must be explicit, scoped, and continuously enforceable at the point of use.