What breaks when teams rely on MCP authorization instead of identity governance?

Why Identity Governance Still Has to Sit Above MCP Authorization

MCP authorization can answer a narrow question: is this request allowed against this server right now? It cannot answer the governance questions that matter to security teams, such as who owns the agent, whether the agent is still sanctioned, or whether the access should end when a project closes. That gap is why identity governance must remain the control plane above protocol-level authorization.

This is the same pattern NHIMG has documented across NHI failures: control at the protocol layer does not substitute for lifecycle control, recertification, and accountable ownership. The Ultimate Guide to NHIs and the Top 10 NHI Issues both show that the hardest failures are usually governance failures, not pure authentication failures. That distinction matters because a server can accept a call from a valid agent while the organisation has already lost track of why the agent exists.

Current guidance from NIST Cybersecurity Framework 2.0 still points teams toward asset ownership, access oversight, and continuous risk management. In practice, many security teams discover missing ownership only after an automated workflow has already accumulated privileges and outlived the business purpose that justified it.

How the Failure Shows Up in Real MCP Deployments

When teams let MCP authorization carry the burden of identity governance, three things usually go wrong. First, approval becomes local to the server instead of tied to a central NHI record. Second, scope is treated as a technical permission rather than a business entitlement. Third, recertification gets skipped because the request is technically valid, even when the agent’s purpose has changed.

In agentic environments, that is especially dangerous because the agent is not a fixed human user with a stable pattern of access. It can chain tools, change tasks, and request new capabilities as it pursues a goal. That is why static IAM models break down for autonomous systems and why the emerging best practice is moving toward intent-based, runtime authorisation rather than pre-defined access alone. OWASP Agentic AI Top 10 and the OWASP Agentic Applications Top 10 both reinforce that agent behavior must be constrained by context, not just by a standing permission set.

• Use workload identity as the primary identity primitive, not a shared token hidden behind the MCP layer.
• Issue just-in-time, short-lived secrets per task and revoke them automatically on completion.
• Bind every agent to an owner, purpose, and expiry date in your NHI inventory.
• Evaluate policy at request time with full context, including task, data sensitivity, and environment.

For organisations building this stack, the practical model is simple: MCP can enforce a request boundary, but identity governance must enforce who the agent is, what it is allowed to become, and when it must lose access. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for that lifecycle view. These controls tend to break down when MCP servers are federated across multiple teams because ownership, recertification, and revocation become fragmented across silos.

Where Teams Get Tripped Up, and What to Do Instead

Tighter runtime controls often increase operational overhead, requiring organisations to balance speed against governance discipline. That tradeoff becomes visible when teams rely on MCP authorization as if it were an identity system. It is not. It is a protocol gate, and protocol gates rarely answer audit, approval, or entitlement questions on their own.

One common edge case is a long-running agent that keeps working after the original business request ends. Another is a shared service agent that serves multiple projects, making approval records ambiguous. Guidance is still evolving on how to model those cases cleanly, but current best practice is to separate access decisioning from lifecycle governance and to make both auditable. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a useful reminder that auditors will ask who approved the identity, not just whether the server accepted the call.

The strongest programs therefore combine central NHI governance, short-lived credentials, and continuous review. That aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for access review and privilege management, while still leaving room for protocol-specific checks at the MCP layer. A useful rule of thumb is that the protocol decides whether the request is syntactically acceptable, while governance decides whether the agent should still exist at all. In environments with fast-moving agent sprawl, the failure usually appears first as orphaned access and only later as a security incident.

Related resources from NHI Mgmt Group

• What breaks when teams rely on identity inventories instead of visibility?
• What breaks when identity teams rely on one-off access reviews instead of scheduled reporting?
• What are MCP Authorization Extensions and how do they help organizations?
• Why do AI agents make non-human identity governance harder?