MCP client policy is the set of rules a local client uses to decide what a plugin may do after installation. It governs tool access, sandboxing, and secret retrieval at runtime, which means the client becomes the practical enforcement point when the protocol itself does not define permissions.
Expanded Definition
MCP client policy is the local enforcement layer that determines what an installed plugin may do at runtime, including which tools it can invoke, where it can execute, and whether it may retrieve secrets. In Model Context Protocol environments, this policy matters because the protocol describes interaction patterns, but it does not fully define enterprise permission semantics. As a result, the client, not the server, often becomes the practical control point for approval, scoping, and containment.
Definitions vary across vendors, but the security intent is consistent: reduce the trust granted to newly installed integrations and constrain their behavior to the minimum required for the task. This is closely related to the concerns described in OWASP Top 10 for Agentic Applications 2026, where over-permissioned agents and unsafe tool use are treated as primary risk drivers. In practice, a strong MCP client policy separates installation from execution and treats runtime access as revocable, inspectable, and narrowly scoped.
The most common misapplication is assuming the server or protocol layer will enforce least privilege, which occurs when a team installs a plugin and then lets the client auto-grant broad tool and secret access.
Examples and Use Cases
Implementing MCP client policy rigorously often introduces friction for users, requiring organisations to balance automation speed against tighter runtime controls and more approval steps.
- A desktop AI client allows a notes plugin to read only a designated workspace folder, while blocking access to the password vault and system shell.
- An engineering assistant can call a build tool, but the client policy prevents secret retrieval unless a specific workflow context is present.
- A security team uses the policy to sandbox third-party plugins so they cannot open arbitrary network connections or reach internal APIs.
- A governance workflow requires manual approval before any newly installed MCP plugin can access sensitive tools, mirroring the lifecycle and audit concerns in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- Investigators compare client policy logs with protocol activity after anomalous behavior, using patterns similar to the breach analysis in Gemini CLI Breach — Silent Code Execution.
These controls are also shaped by broader identity guidance in Top 10 NHI Issues and the client-side trust assumptions discussed by NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
MCP client policy is critical because it governs the moment an NHI-like workload becomes operationally real: when a plugin, agent, or tool-binding identity can actually act. Without a strong client policy, installed components may overreach, retrieve secrets they do not need, or invoke tools outside their intended scope. That creates the same failure mode seen in broader agent security, where a software entity has execution authority without sufficient containment.
NHIMG research shows how quickly this becomes a governance issue: in The State of MCP Server Security 2025, only 18% of mcp server deployments implement any form of access scoping for tool permissions, which leaves most environments dependent on weak or inconsistent client-side enforcement. That is why client policy must be treated as part of NHI governance, not as a convenience feature. The policy should be reviewed alongside audit expectations and lifecycle controls in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives, especially where credential use and tool access can be reconstructed only after the fact. Organisations typically encounter the cost of weak client policy only after a plugin has already exfiltrated data or executed an unauthorised action, at which point the policy becomes operationally unavoidable to address.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic app risks include excessive tool access and unsafe plugin behavior. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret handling and access scoping are central to client policy enforcement. |
| NIST CSF 2.0 | PR.AC | Identity and access control principles apply directly to local client enforcement. |
| NIST Zero Trust (SP 800-207) | PL-2 | Zero trust requires explicit, continuous authorization for resource access. |
| NIST SP 800-63 | AAL2 | Assurance concepts inform how strongly client actions and secrets should be gated. |
Treat each plugin action as separately authorized rather than trust inherited installation status.
Related resources from NHI Mgmt Group
- Why do MCP tools need server-side policy checks instead of token-only controls?
- What is the difference between client identity and permission scope in MCP governance?
- How should security teams handle Dynamic Client Registration in remote MCP deployments?
- Who is accountable when an MCP client grants access too broadly?
