They should treat MCP access as three separate controls: admission through the IdP, downstream delegation for the server’s own credentials, and runtime authorisation for each tool call. That separation gives each control a clear owner and prevents one valid login from being mistaken for end-to-end safety.
Why This Matters for Security Teams
MCP changes the old “one login equals safe use” assumption. An IAM team may admit a user through SSO, but the MCP server still needs its own delegated credentials, and each runtime tool call still needs its own decision. That separation matters because compromise can happen at any layer: a legitimate user can reach an unsafe server, a server can over-reach with its own secrets, or an agent can invoke tools in ways the original login never implied. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces that governance, access control, and monitoring are distinct operational functions, not a single control event.
NHIMG’s research on MCP server security found that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly server-side trust can be overstated when credentials are embedded in configuration rather than governed as a separate asset class. IAM teams that only secure the front door often miss the fact that the server and the runtime both carry their own blast radius. In practice, many teams discover this only after a valid SSO session has already been used to trigger an unintended downstream action.
How It Works in Practice
Governance works best when MCP access is modeled as three control planes. First, SSO admission decides whether a human or workload may reach the MCP surface at all. Second, server delegation governs what credentials the MCP server may use on behalf of that session, including scope, TTL, and revocation. Third, runtime authorisation evaluates every tool call against context such as the user, the server, the tool, the requested data, and the current policy state. That layered model aligns well with the OWASP Non-Human Identity Top 10 because the main failure mode is not authentication alone, but unmanaged downstream privilege.
- Use the IdP for admission and session binding, not for blanket trust in tool execution.
- Issue server credentials separately from user SSO, preferably as short-lived workload tokens rather than static secrets.
- Apply runtime policy checks to each MCP method, not just to the initial connection.
- Log the identity chain so operators can see which principal requested, delegated, and executed each action.
For agentic and tool-using systems, the OWASP Agentic AI Top 10 is relevant because tool abuse, excessive action scope, and confused delegation are core risks once an assistant can chain actions across systems. The practical takeaway is that MCP servers should not be treated as passive API gateways; they are active delegation brokers with their own identity and policy obligations. These controls tend to break down in hybrid deployments where legacy SSO, hard-coded server secrets, and ad hoc tool registration all coexist because no single team owns the full request path.
Common Variations and Edge Cases
Tighter MCP governance often increases integration overhead, requiring organisations to balance developer velocity against stronger delegation controls. That tradeoff is real, especially when teams want one seamless login to cover both humans and autonomous workflows. Current guidance suggests that single-sign-on should remain the user entry point, but there is no universal standard for how MCP servers should present downstream identity to every tool backend yet.
One common edge case is server-to-server chaining. If an MCP server calls another service with its own long-lived secret, the runtime control can look correct while the delegation layer is already too broad. Another edge case is high-frequency tool use, where per-call authorisation must stay fast enough for production. In those environments, coarse access lists often linger because teams fear latency, but that usually recreates the same blind spot in a different form. The better pattern is short-lived credentials, policy-as-code, and selective caching of low-risk decisions, not permanent broad grants.
NHIMG’s NHI research shows why this matters operationally: 88.5% of organisations say their non-human IAM lags human IAM, which explains why MCP often inherits weak secret handling and vague ownership. For teams formalising the model, the NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for mapping discrete controls to access enforcement, auditing, and least privilege. The hardest cases are highly autonomous agents with broad tool chains, because a single request can traverse multiple servers before any human notices the path.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Covers tool abuse and excessive action scope in agentic workflows. |
| CSA MAESTRO | Addresses trust boundaries and delegated action in agentic systems. | |
| NIST AI RMF | Supports governance of autonomous AI behaviour and accountability. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Relates to credential sprawl and weak secret management for servers. |
| NIST CSF 2.0 | PR.AC-4 | Maps to least-privilege access enforcement for users and services. |
Separate user admission, server delegation, and runtime enforcement across the MCP path.
