Because they turn agent connectivity into a reusable access layer that can expose databases, APIs, and internal systems through a single protocol. If permissions are broad or audit trails are weak, the identity programme loses control over who or what acted, what data moved, and whether the action was authorised.
Why This Matters for Security Teams
MCP changes the risk profile because it makes one protocol capable of reaching many systems, so identity controls that were acceptable for a single app can become dangerous when an agent can chain tools, reuse tokens, and act without a human in the loop. That is why NHI governance has to treat MCP servers as privileged access infrastructure, not just integration plumbing. The issue is not only authentication, but also authorisation scope, secrets handling, and traceability across workloads.
Current guidance from OWASP Agentic AI Top 10 and NIST Cybersecurity Framework 2.0 points in the same direction: if the access layer is reusable, then the control plane must assume misuse, not trust intent by default. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs both show how fast blast radius grows once secrets, service accounts, and machine permissions are reused across workflows. In practice, many security teams only discover the control gap after an MCP-connected agent has already touched production data or internal APIs.
How It Works in Practice
An MCP server can sit between an AI agent and multiple enterprise systems, which means it often becomes the de facto workload identity broker. That is useful for scale, but risky if the server issues broad, long-lived access or stores Secrets in configuration files. In the 2025 State of MCP Server Security 2025, Astrix Security reported that 53% of MCP servers expose credentials through hard-coded values in configuration files, which is a clear warning sign for NHI and IAM programmes.
The practical answer is to separate authentication from authorisation and make both runtime-aware. For autonomous workloads, static RBAC is often too blunt because the agent’s next action is not fully known in advance. Better patterns include:
- Workload identity for the agent or service, rather than shared human credentials.
- JIT credential provisioning so access is issued per task and revoked on completion.
- Short-lived tokens and ephemeral Secrets instead of persistent API keys.
- Intent-based or context-aware authorisation that evaluates what the agent is trying to do right now.
- Policy-as-code with real-time evaluation, aligned to OWASP Top 10 for Agentic Applications 2026 and the NIST Cybersecurity Framework 2.0.
That model works best when MCP is treated as a controlled mediation layer, with tight scope per tool, per model, and per environment. It also helps to map the server into broader agent governance under OWASP NHI Top 10 and OWASP Agentic Applications Top 10, because the same control weaknesses recur across tool use, prompt-driven execution, and secret exposure. These controls tend to break down when MCP servers are deployed as shared, high-trust gateways across many teams, because permissions drift faster than reviews can keep up.
Common Variations and Edge Cases
Tighter access control often increases integration overhead, so organisations have to balance developer velocity against containment and auditability. That tradeoff becomes sharper when MCP is used for internal automation, where teams want broad utility but security needs narrow, context-specific permissions.
There is no universal standard for this yet, but current guidance suggests three common edge cases matter most. First, shared MCP servers used by multiple agents usually need stronger segregation than single-purpose deployments, because one weak tool permission can expose unrelated systems. Second, tool calls that trigger write actions need stronger approval logic than read-only queries, especially where data movement can occur outside the original intent. Third, environments with legacy IAM often struggle because their controls were designed for human sessions, not autonomous and goal-driven behaviour. That is where 52 NHI Breaches Analysis and Cisco DevHub NHI breach are especially relevant: they show how machine identities and exposed access paths become incident multipliers once trust is too broad.
For governance, CSA-MAESTRO and NIST AI RMF both support the same practical stance: treat MCP as part of the control surface for autonomous systems, not as a neutral transport. The right question is not whether the agent can connect, but whether every action is bounded, attributable, and revocable.
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 | OA-03 | MCP risk is driven by agent tool abuse and uncontrolled action scope. |
| CSA MAESTRO | MAESTRO covers agentic orchestration, identity, and tool trust boundaries. | |
| NIST AI RMF | AI RMF addresses governance, accountability, and runtime risk for autonomous systems. |
Use AI RMF to assign ownership, monitor behavior, and review MCP-enabled agent risk continuously.
