MCP turns model-tool interaction into a repeatable identity event, which means access, logging, and approvals must work at the capability level rather than at the application level. That complicates governance because the same tool may be reused across many workflows, making privilege review and audit trails harder to standardise.
Why This Matters for Security Teams
MCP changes identity governance because it turns a one-time model-to-tool connection into a repeatable, runtime identity event. The governance problem is no longer just “who can use the application,” but “what exact capability can this agent invoke, under what context, and with what approval trail.” That shift makes static app-level access reviews too coarse for autonomous workflows and pushes teams toward capability-level controls, as reflected in current guidance from the OWASP Agentic AI Top 10.
The risk is amplified when one MCP server exposes several tools that are reused across many agents, environments, and business processes. In that model, a single entitlement can quietly become shared infrastructure for multiple actions, which complicates segregation of duties, auditability, and revocation. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, a pattern that becomes harder to spot when tool access is abstracted through MCP.
In practice, many security teams encounter over-privileged MCP tool paths only after an agent has already used them in a production workflow, rather than through intentional entitlement design.
How It Works in Practice
Governance for MCP environments has to operate at three layers: the agent identity, the MCP server identity, and the specific tool or capability being invoked. A model may authenticate successfully, but that does not mean it should be authorised to call every tool exposed by the server. The security decision needs to happen at request time, with context such as task intent, data sensitivity, tenant boundary, and whether the action is read-only or mutating. That is why policy engines and runtime controls matter more here than broad RBAC alone.
Practitioners are increasingly aligning MCP with workload identity and short-lived credentials. Instead of giving an agent a durable secret that can be reused across sessions, teams issue ephemeral access for a specific task and revoke it automatically when the task completes. This is consistent with the direction of the NIST AI Risk Management Framework, which emphasises continuous monitoring and risk treatment rather than one-time approval.
- Bind each agent to a workload identity rather than a shared service account.
- Expose MCP tools as discrete capabilities with their own policy and logging.
- Evaluate authorisation at runtime, not only during onboarding or initial registration.
- Use short-lived tokens and automatic revocation for sensitive tool paths.
- Log tool selection, parameters, and downstream side effects for auditability.
This model is also reflected in NHIMG research on agentic risk, especially AI Agents: The New Attack Surface report, where 80% of organisations reported agents acting beyond intended scope. That matters for MCP because reuse is a feature: the same tool may serve many workflows, but governance has to prove each use was legitimate. These controls tend to break down when MCP is connected to legacy services that only support long-lived service accounts and coarse application-level permissions.
Common Variations and Edge Cases
Tighter MCP governance often increases operational overhead, requiring organisations to balance faster agent enablement against stronger approval, logging, and revocation controls. That tradeoff is especially visible in shared MCP servers, where a single service may support development, support, and production agents with different risk levels.
There is no universal standard for this yet. Best practice is evolving toward capability-based policy, but many environments still depend on app-level entitlements because their identity stack cannot express tool-level constraints cleanly. In those cases, teams should treat MCP as a control boundary and add compensating controls such as per-tool allowlists, separate server instances for high-risk capabilities, and tighter session TTLs for write actions.
Edge cases also appear when an MCP tool can chain into other systems. A benign-looking read operation may become a privilege escalation path if the downstream system trusts the MCP caller too broadly. The CSA MAESTRO agentic AI threat modeling framework is useful here because it pushes teams to model cross-tool interactions, not just isolated permissions. For broader NHI lifecycle controls, the Ultimate Guide to NHIs reinforces that revocation, rotation, and visibility must remain continuous, even when access is mediated by an AI layer.
Where MCP is layered over third-party tools, audits can also become fragmented because the identity evidence is split across the agent, the broker, and the target system. That is the point at which governance becomes a correlation problem rather than a pure access-control problem.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic tools and runtime authority are the core MCP governance problem. |
| CSA MAESTRO | TRM-01 | MAESTRO models tool chaining and cross-boundary agent risk in MCP flows. |
| NIST AI RMF | AI RMF supports continuous monitoring and governance for autonomous agent decisions. |
Apply AI RMF to define ownership, monitor runtime use, and review agent actions continuously.
