Risk increases when MCP access depends on raw tokens, local configuration files, or broad server-level permissions that hide which tool actually performed the action. At that point, the integration layer improves connectivity but weakens accountability. The turning point is when access cannot be revoked, logged, and attributed without manual intervention.
Why This Matters for Security Teams
MCP becomes a governance problem when it turns into a convenient abstraction over uncontrolled access. The protocol itself is not the issue; the issue is when teams treat the connector as proof of control while the actual action still depends on broad tokens, shared secrets, or opaque server permissions. At that point, the organisation can see connectivity but not accountability.
That matters because agentic and tool-using workloads do not behave like human users with stable job roles. Their access patterns change by task, by prompt, and by chain of tool calls. When those actions are not individually attributable, incident response, audit evidence, and revocation all degrade at the same time. NHI Management Group’s research on AI Agents: The New Attack Surface report found that only 52% of companies can track and audit the data their AI agents access, leaving 48% blind for compliance and breach investigation.
This is why MCP can remove risk in well-governed deployments, but increase it when it becomes a hidden privilege broker. In practice, many security teams discover that the control gap only appears after a tool has already been overused, misused, or chained into something far broader than the original approval model allowed.
How It Works in Practice
MCP improves integration by standardising how agents discover and call tools, but governance depends on what sits around the protocol. If an agent authenticates with a long-lived bearer token, inherits broad server-level rights, or stores credentials in local config files, the organisation has simply moved the trust boundary. The access path may be cleaner, but the control plane is often weaker.
Current guidance from the OWASP Agentic AI Top 10 and NIST Cybersecurity Framework 2.0 points toward three practical safeguards:
- Use workload identity so the agent proves what it is, not just what secret it has.
- Issue JIT credentials that are task-scoped, short-lived, and automatically revoked after completion.
- Evaluate policy at request time so tool use is approved based on context, not just pre-defined role membership.
That model aligns with the risk patterns described in Top 10 NHI Issues and the broader lifecycle guidance in the Ultimate Guide to NHIs, especially where secrets, rotation, and revocation are concerned. The practical test is simple: if you cannot identify which tool acted, under which context, and with which expiration window, MCP is not reducing governance risk. These controls tend to break down in multi-agent pipelines and shared MCP servers because one agent’s approved action can become another agent’s unintended privilege path.
Common Variations and Edge Cases
Tighter MCP governance often increases operational overhead, requiring organisations to balance developer convenience against auditability and blast-radius reduction. That tradeoff is especially sharp in research sandboxes, rapid prototyping environments, and internal copilots where teams want low-friction access to many tools.
Best practice is evolving, but there is no universal standard for this yet. Some organisations accept broader MCP access in low-risk environments if the server is isolated and heavily logged. Others require per-tool authorisation, separate identities for each agent, and explicit human approval for sensitive actions. The right answer depends on whether the tool can read data, change state, or invoke another system with persistent side effects.
MCP also becomes riskier when it is used as a bypass around established identity controls. If the platform team cannot map each tool call back to a specific workload identity, then incident responders inherit a blind spot. That is why The 2024 ESG Report: Managing Non-Human Identities matters here: compromised NHIs already produce repeated incidents, so adding opaque protocol layers without revocation and telemetry only compounds the problem. In environments with shared services, high trust between agents, or weak secret hygiene, MCP tends to amplify existing governance gaps rather than close them.
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 excessive agent authority and unsafe tool use in MCP-connected systems. |
| CSA MAESTRO | IAM-02 | Maps to identity and access controls for autonomous agent tool access. |
| NIST AI RMF | Supports governance of autonomous behaviour, accountability, and risk monitoring. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret rotation and revocation failures common in MCP deployments. |
| NIST CSF 2.0 | PR.AC-4 | Directly relates to least-privilege access and controlled remote access. |
Document agent purpose, monitor tool use, and assign ownership for every MCP-enabled action.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
