The Model Context Protocol is an open standard defining how AI agents communicate with external tools, data sources, and services. It has three components: MCP Host, MCP Client, and MCP Server. For NHI security practitioners, MCP matters because every MCP client is a Non-Human Identity that authenticates, requests permissions, accesses resources, and operates autonomously. Ungoverned MCP clients are ungoverned NHIs.
Why MCP Changes the Security Model
Model Context Protocol is not just another integration layer. It turns an AI system into an active workload that can request tools, read data, and trigger actions with real business impact. That means MCP clients are not passive software components; they are Non-Human Identities with identity, permissions, telemetry, and misuse potential. Security teams that treat MCP as “just plumbing” miss the point that the agent can act autonomously and at scale.
The risk is visible in current research. In OWASP Agentic Applications Top 10 and the OWASP Agentic AI Top 10, the emerging consensus is that tool-using agents expand the attack surface because they chain actions across systems, not because they simply “use AI.” NHIMG research also shows how quickly this becomes operationally dangerous: the Analysis of Claude Code Security demonstrates why code-executing assistants need guardrails, not trust by default. In practice, many security teams encounter MCP abuse only after a client has already overreached its intended scope, rather than through intentional design.
How MCP Should Be Governed in Practice
MCP security starts with identity, not tooling. Each MCP client should be treated as a workload identity with a defined trust boundary, a purpose, and runtime policy checks. That is where static role-based access often fails: an autonomous agent does not behave like a human user with a stable pattern of activity. It may invoke a tool once, then pivot to another system based on the task outcome. Best practice is evolving toward intent-based authorisation, where the decision is made at request time using context such as task purpose, data sensitivity, tool scope, and current risk.
For implementation, many practitioners are moving toward short-lived, just-in-time credentials and ephemeral secrets rather than long-lived static tokens. This aligns with broader NHI governance in the Ultimate Guide to NHIs — What are Non-Human Identities. In an MCP environment, that usually means:
- Issuing credentials per task or session, not per application lifecycle.
- Binding tool access to workload identity, such as SPIFFE or OIDC-backed attestation where available.
- Evaluating policy at runtime with policy-as-code rather than relying on pre-approved static roles.
- Logging every tool request, data touch, and permission escalation path for audit and incident response.
This approach is consistent with the direction of OWASP Top 10 for Agentic Applications 2026 and the governance emphasis in NIST AI risk guidance. It also aligns with the real-world lessons in the Schneider Electric credentials breach, where exposed secrets can turn ordinary access into broad compromise. These controls tend to break down when MCP servers are allowed direct access to production credentials because the agent can then inherit excessive privilege instantly.
Common MCP Edge Cases Security Teams Miss
Tighter control often increases integration overhead, requiring organisations to balance safety against delivery speed. That tradeoff becomes more visible in multi-agent systems, where one agent may call another and each hop needs its own identity, scope, and revocation path. There is no universal standard for this yet, so current guidance suggests designing for the worst-case assumption that an agent can deviate from the intended plan.
Two edge cases matter most. First, “trusted internal” MCP servers are still risky if they can access hard-coded secrets or broad internal APIs, because the agent may retrieve data beyond the original task. Second, permissive tool catalogs can create accidental privilege escalation: a harmless lookup tool may become the first step in lateral movement. This is why the security model must cover both the client and the server side of the protocol. The OWASP Agentic Applications Top 10 and NIST AI governance guidance both point toward continuous evaluation, not one-time approval.
Current guidance also supports separating duty between orchestration, policy, and execution. In practice, that means using one control plane to decide whether the agent may act, another to mint a short-lived credential, and a third to execute and observe the action. This separation reduces blast radius, but it still depends on tight secrets hygiene and clear ownership. Where that model breaks down is in legacy environments with flat network access, shared service accounts, and no reliable workload attestation, because the agent cannot be isolated from the privileges of the surrounding system.
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 | Agentic tool use and autonomous action expand the attack surface MCP introduces. | |
| CSA MAESTRO | MAESTRO addresses orchestration, identity, and governance for multi-agent systems. | |
| NIST AI RMF | AI RMF fits autonomous decision-making, accountability, and ongoing risk management. |
Apply agentic app controls to every MCP tool path, with runtime checks and least privilege.
Related resources from NHI Mgmt Group
- What are MCP Authorisation Extensions and why do they matter for enterprise governance?
- Why has identity replaced the network perimeter as the primary security boundary?
- What is phishing-resistant authentication and how does it relate to NHI security?
- What is the first step in building a modern NHI security programme?
