Should organisations standardise on MCP for all AI agents?

Why This Matters for Security Teams

Standardising on MCP for every AI agent sounds tidy, but it can blur a critical line: whether the agent is acting on behalf of multiple users and systems, or simply assisting a single operator in a tightly scoped local workflow. That distinction changes the identity model, the audit burden, and the access-control design. Current guidance suggests MCP is most valuable when the agent needs governed tool access across shared environments, not as a universal default.

Security teams should also treat MCP as an exposure surface, not just an integration layer. NHIMG research on the State of MCP Server Security 2025 shows how quickly configuration mistakes and weak scoping can turn a convenience protocol into a credential and data-access problem. The broader agent risk picture is already visible in the AI Agents: The New Attack Surface report, where most organisations report agent behaviour beyond intended scope.

That matters because autonomous systems do not follow the neat, predictable access patterns that traditional IAM assumes. In practice, many security teams discover overbroad agent access only after an agent has already chained tools, touched sensitive systems, or leaked secrets.

How It Works in Practice

The practical decision is not “MCP or no MCP,” but “what governance boundary does the agent need?” If the agent acts for a user across shared data, shared tools, or enterprise systems, MCP can provide a standard interface for tool invocation and policy enforcement. If the task remains local and operator-bound, a CLI or direct workflow may be simpler and safer because it keeps authority close to the human session.

For governed agent deployments, the best pattern is usually:

• Issue workload identity to the agent so the system can prove what the agent is, not just which static secret it holds.
• Use just-in-time credentials with short TTLs, scoped to the task and revoked on completion.
• Evaluate authorisation at request time using policy-as-code, rather than predefining broad role mappings that assume stable behaviour.
• Separate tool access by environment and sensitivity so the agent cannot reuse a development permission set in production.

This aligns with the direction of the OWASP Agentic AI Top 10, the CSA MAESTRO agentic AI threat modeling framework, and the NIST AI Risk Management Framework, all of which emphasise context, accountability, and lifecycle controls over static trust. NHIMG’s Ultimate Guide to NHIs — Standards also reinforces that identity controls must match the workload’s real operating model, not just its deployment label.

Where teams go wrong is assuming MCP automatically solves governance. It does not. It only becomes safer when paired with short-lived secrets, explicit scoping, and runtime policy decisions that reflect the agent’s current intent. These controls tend to break down when an organisation reuses a single MCP server across many teams and environments because permission boundaries become ambiguous and exceptions accumulate.

Common Variations and Edge Cases

Tighter MCP governance often increases operational overhead, requiring organisations to balance standardisation benefits against developer friction and service complexity. That tradeoff is real, especially in local development, data-science notebooks, and one-off automation tasks where full enterprise controls can slow delivery more than they reduce risk.

There is no universal standard for this yet, but current guidance suggests three common exceptions. First, local-only agent workflows often do not justify MCP at all if the agent never leaves a single operator’s trust boundary. Second, highly regulated environments may require MCP plus additional approval, logging, and credential brokering because shared tools create stronger audit obligations. Third, multi-agent systems can need different policies per agent, since one agent may browse knowledge sources while another can execute production actions.

Another edge case is vendor-managed agent platforms that hide the underlying credential flow. In those environments, teams should verify whether the agent uses ephemeral workload identity, whether tool permissions are scoped per invocation, and whether logs can reconstruct what action was authorised and why. The NIST AI Risk Management Framework is useful here because it keeps attention on governable outcomes rather than protocol preference alone.

For most organisations, the safest rule is simple: standardise on MCP where the agent needs enterprise-grade shared access, and keep lighter tools for tightly bound local use cases. NHIMG’s analysis of the Analysis of Claude Code Security shows why workflow context matters as much as the protocol itself.

Related resources from NHI Mgmt Group

• How can organisations reduce risk when AI agents use MCP servers?
• How should teams govern AI agents that use MCP?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?