MCP servers can trigger real tool actions, so the risk is not only authentication but what an authenticated caller can do next. Platform-level controls are needed because the specification leaves enforcement to the runtime. Without that layer, the server becomes an ungoverned execution boundary.
Why MCP servers need controls at the platform layer
MCP servers are not passive documentation endpoints, they can invoke tools, reach data, and trigger side effects. That means the security question is not just whether a caller authenticated, but whether the runtime can constrain what that caller is allowed to do next. Platform-level identity and authorisation controls turn the server from an open execution boundary into something the organisation can govern.
That distinction matters because the MCP specification intentionally leaves enforcement to the host platform or runtime. If the server accepts a valid caller and then inherits broad local access, the effective trust boundary shifts from the protocol to the deployment environment. In practice, the strongest control point is the one that can evaluate identity, context, and permission at the moment a tool action is requested.
Controls at this layer are especially important when the same server can serve multiple users, agents, or workflows. Without centralised enforcement, one authenticated session can become a shortcut into overbroad tools, shared credentials, or data paths that were never meant to be exposed to every caller. This is why platform policy, not just per-server logic, has to define the real operating boundary. MCP Security Guide frames the authorisation problem directly, while the Model Context Protocol: Authorization specification shows how HTTP transports treat the server as an OAuth resource server rather than a blind token sink.
Where the platform layer changes the security model
The platform layer changes the answer whenever the server can do more than inspect input. If the server can read files, call upstream systems, access internal APIs, or launch workflows, then the real question becomes whether each action is separately bounded. Authentication establishes who is at the door; authorisation decides which tools, resources, and scopes that caller can actually reach.
This is also where least privilege becomes operational instead of theoretical. A runtime that can map callers to specific permissions, audiences, or task scopes can prevent a generic authenticated session from becoming a universal execution token. That is the difference between a managed integration point and an ungoverned control plane. Authorisation Models Guide is useful here because MCP deployments often need policy decisions that go beyond static roles, especially when the same server serves different tasks or tool sets.
Identity also matters because the server may be acting on behalf of a human, an agent, or another workload. A well-designed platform can bind the caller, the session, and the allowed action together so that delegated access is traceable and revocable. If the platform cannot do that, the server tends to accumulate ambient authority, which is the opposite of what secure tool execution requires. For that reason, NHI Authentication Guide and AI Agent Authorisation Guide are both relevant to understanding how machine and agent callers should be constrained before they can reach tools.
What goes wrong when MCP enforcement is left to the server alone
When the server itself is the only enforcement point, it often inherits too much trust from its deployment context. A token that proves a caller can reach the server does not automatically prove that the caller should be able to invoke every tool, access every backing system, or operate across environments. The most common failure is confused-deputy behaviour, where a legitimate caller causes a trusted server to perform an action with broader authority than the caller should have had.
That failure mode becomes more serious when secrets, long-lived tokens, or shared credentials are present in the server environment. An attacker does not need to break the protocol if they can ride the runtime’s default trust path. This is why platform-level identity should be paired with strict authorisation boundaries, short-lived credentials, and explicit audience scoping, not just transport security. The Top 10 NHI Issues and Ultimate Guide to NHIs, Key Challenges and Risks both map closely to this overprivilege and credential-sprawl problem.
Another practical risk is that the server becomes an uncontrolled aggregation point for permissions across tools, tenants, or environments. Once that happens, a single weak policy or overly broad secret can create a large blast radius. Platform-level controls are the mechanism that keep those permissions separable, reviewable, and revocable. The NHI Lifecycle Management Guide is relevant because the same lifecycle discipline that applies to machine credentials also applies to MCP server access paths and tool entitlements.
Risk and Threat Considerations
Leaving enforcement inside the server creates a high-value abuse path: any weakness in the server’s own logic can translate directly into tool misuse, data exposure, or unwanted downstream actions. The risk is not only unauthorized access, but over-authorised access that is technically valid and therefore harder to detect until after impact.
Failure mechanism: the caller authenticates to the server, but the server lacks a separate policy layer to constrain tool invocation, resource scope, or delegated authority, so the server executes requests with broader privilege than intended.
Impact: attackers or misconfigured clients can reach sensitive data, trigger privileged actions, or reuse the server as a trusted execution bridge across systems, increasing blast radius and reducing containment options.
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 Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP servers can execute agent-like tool actions with excessive authority. |
| Recommendation — Enforce per-action authorization and least privilege before tool execution. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Platform-level control is needed when server identities can overreach their intended scope. |
| NHI-07 — Long-Lived Secrets | MCP servers often depend on tokens or secrets that should not become ambient trust. | |
| Recommendation — Reduce server and workload privilege to the minimum required scope. Replace long-lived secrets with short-lived, tightly scoped credentials. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP servers and tool backends often authenticate as services or workloads. |
| AC-6 — Least Privilege | The answer is fundamentally about limiting what authenticated callers can do next. | |
| AC-3 — Access Enforcement | Platform-level controls must enforce which tool actions are permitted. | |
| Recommendation — Use service authentication that binds identity to the runtime and peer service. Limit each MCP caller and server component to the minimum required permissions. Enforce authorisation centrally at the runtime boundary before executing tools. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | MCP deployments need centralised control over who can invoke what actions. |
| Recommendation — Centralise access decisions and remove standing permissions that are too broad. | ||
Practitioner Guidance
What to prioritise: treat MCP authorisation as a platform control, not a server implementation detail. The first decision is whether the runtime can enforce per-tool, per-resource, and per-session policy before the server acts on a request.
What to verify: confirm that the server cannot rely on inherited cloud, host, or container permissions to satisfy user requests. If the platform cannot show which identity approved which action, the control is too weak to trust.
Common mistake: teams often secure the transport and assume the protocol is therefore safe. For MCP, that is insufficient if the runtime still has broad access to tools or back-end systems.
Practitioner takeaway: the control objective is not merely to admit a caller, but to ensure every meaningful tool action is authorised at the point of execution and bounded to the minimum authority needed.
Related resources from NHI Mgmt Group
- What breaks when MCP servers are exposed without identity controls?
- How should security teams combine content inspection with identity controls for AI agent access to MCP servers?
- Why do MCP servers need identity controls if telemetry already shows every request?
- What is the difference between code scanning and runtime identity monitoring?
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 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org