When any MCP server can be installed by default, organisations lose control over what tools touch internal data and systems. That creates shadow IT risk, inconsistent approvals, and a weaker audit trail. It also makes it harder to enforce access rules, because the problem starts at discovery rather than at execution.
Why This Matters for Security Teams
Default-install MCP behaviour turns tool choice into a security boundary, which is the wrong place to leave it. An mcp server can expose file systems, SaaS APIs, databases, and internal actions through a single developer-approved connection, so the question is not whether the tool is “useful” but whether it is authorised to exist in that environment. The risk is especially acute for agentic workflows, where the model can chain tools faster than humans review them.
Current guidance suggests treating MCP server installation like any other privileged software intake decision, not a convenience setting. The concern is visible in both operational telemetry and broader agent risk reporting: only 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance and breach-investigation blind spot, according to AI Agents: The New Attack Surface report by SailPoint. For tool-driven systems, that blind spot begins before execution, at discovery and trust assignment.
When developers can install arbitrary MCP servers by default, approval drifts from policy to preference, and the enterprise inherits whatever auth, logging, and secret-handling assumptions the server author made. In practice, many security teams encounter exposure only after a new connector has already been granted broad access, rather than through intentional intake control.
How It Works in Practice
The practical failure is that default installation short-circuits governance. Instead of routing every MCP server through a review path, teams allow direct adoption from repos, package registries, or local copies. That creates inconsistent trust levels: one server may use scoped OAuth and request-time checks, while another hard-codes tokens or requests broad filesystem and network access. The result is not just shadow IT, but shadow authority.
Best practice is evolving toward a controlled intake model with explicit allowlists, signed packages where available, and environment-specific policy checks. For agentic workloads, the safer pattern is to bind permissions to the workload and the request, not to the developer’s local install action. That aligns with OWASP Top 10 for Agentic Applications 2026 and the request-time control model in NIST SP 800-53 Rev 5 Security and Privacy Controls.
- Require approval before an MCP server is added to a developer or agent runtime.
- Map each server to an owner, purpose, data class, and logging requirement.
- Block servers that request broad scope when the use case only needs narrow tool access.
- Rotate and vault any secrets used by the server, and inspect configuration files for embedded credentials.
- Prefer runtime policy enforcement over static trust in the installation source.
NHIMG’s Analysis of Claude Code Security and AI Agents: The New Attack Surface report both reinforce the same operational lesson: tool access and data exposure must be governed as a runtime security decision, not a developer convenience. These controls tend to break down when MCP servers are installed on unmanaged endpoints because the organisation loses the ability to enforce consistent identity, logging, and revocation.
Common Variations and Edge Cases
Tighter MCP control often increases friction for developers, requiring organisations to balance speed against the risk of uncontrolled tool sprawl. That tradeoff is real, especially in fast-moving AI engineering teams where every restriction can feel like a productivity loss.
There is no universal standard for MCP server approval yet, so current guidance suggests a tiered model. Low-risk, read-only servers may be pre-approved with narrow scopes, while servers that can write data, invoke internal APIs, or handle secrets should require security review and explicit business ownership. A server that only formats text is materially different from one that can query customer records or trigger production actions.
Another edge case is local development versus production. A server that is acceptable on a sandboxed laptop may be unacceptable in a shared enterprise workspace if it can access synced credentials or internal datasets. The same applies when an agent can chain multiple “safe” servers into a risky workflow. That is why the install decision should be assessed alongside data classification, execution context, and downstream tool chaining, not in isolation.
When developers can install any MCP server by default, the organisation usually discovers the problem during incident response, audit, or data exfiltration review, not during code review or architecture approval.
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 | A03 | Untrusted tool installation expands agent attack paths and unsafe tool access. |
| CSA MAESTRO | TR-2 | MAESTRO addresses governance for autonomous tool use and agent execution boundaries. |
| NIST AI RMF | GOVERN | Default installs undermine accountable oversight of AI-enabled tool use. |
| OWASP Non-Human Identity Top 10 | NHI-05 | MCP servers often rely on secrets that become exposed through uncontrolled installation. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is broken when any server can be installed without review. |
Restrict agent tool intake, validate server trust, and block risky tool chaining before execution.
Related resources from NHI Mgmt Group
- What breaks when developers expose an MCP server publicly without lifecycle review?
- What breaks when teams rely only on default login theming for complex identity journeys?
- What breaks when application teams rely on default assumptions instead of testing parameter handling and class binding behaviour?
- What breaks when organisations cannot see MCP servers and agent connections across endpoints?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
