No. The safer model is to allow only explicitly approved servers, because dynamic tool discovery without a server allowlist makes it too easy for an agent to act on unvetted capabilities. Organisations should constrain server selection, separate trusted from untrusted sources, and require human approval for high-risk tool paths or privileged actions.
Why unrestricted MCP server connections change the risk profile
Allowing an agentic app to connect to any mcp server turns the server into a live capability source, not just a data source. Once the agent can discover and invoke tools dynamically, the organisation no longer knows in advance which actions are reachable, which makes abuse, overreach, and unsafe delegation much harder to prevent.
That risk is not theoretical. A permissive model also weakens review discipline: teams may approve the app while failing to evaluate the individual servers, tool scopes, auth model, or trust boundary each server introduces.
What should be allowed, and what should stay constrained
The practical control is a server allowlist, backed by trust tiering. Explicitly approved servers should be separated from untrusted or experimental sources, and the agent should only see the servers it is meant to use for that environment or business function.
Where the server can trigger privileged actions, access sensitive systems, or reach production data, the connection should be treated as a controlled integration rather than a convenience feature. That means the organisation decides which servers are available, what each server may expose, and which tool paths require additional approval before execution.
That approach is consistent with the MCP authorization model, which treats servers as resource servers with explicit authorization boundaries rather than universally trusted endpoints.
It also fits the broader pattern of least privilege for agents: the app should only inherit the minimum tool access needed for the task, and not a general right to discover whatever a new server happens to offer. NHIMG’s AI Agent Authorisation Guide is useful here because it frames agent access as per-action, task-scoped, and approval-aware rather than ambient.
Where this fails in practice, and how to keep the control real
The common failure mode is implicit trust in “just another server.” If discovery is open-ended, an agent can be pointed at a server whose tools were never reviewed for safety, and the first sign of trouble may be a harmful action rather than a policy violation. That is especially dangerous when the server can proxy credentials, reach internal resources, or hide a more powerful downstream integration.
As soon as the server can influence data movement, write actions, or privilege-bearing requests, the organisation should require human approval for the riskiest paths and log which server, tool, and decision led to the action. NHIMG’s AI Agent Observability, Audit and Incident Response Guide supports that operational model by focusing on attribution, audit trails, and kill-switch readiness.
The other hidden failure is identity confusion. If the agent can use many servers with different trust levels, teams can lose track of which principal is acting, on whose behalf, and under what authority. NHIMG’s Zero Trust for AI Agents is relevant because it treats every request as something to verify, not something to inherit by default.
Risk and Threat Considerations
Open server discovery increases the chance of tool abuse, confused-deputy behaviour, and unsafe privilege expansion. A malicious or poorly governed server can expose capabilities the agent was never meant to see, while a compromised trusted server can become a path for silent overreach or data exposure.
Failure mechanism: The agent accepts dynamically discovered tools from servers that were not pre-approved, which lets unvetted capabilities enter the decision path and bypass the organisation’s normal review of trust, scope, and privilege.
Impact: Attackers or careless integrations can drive unauthorized actions, expose sensitive data, or trigger destructive workflows through a server that looked operationally legitimate but was not controlled as a trusted capability source.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-to-server trust expansion can turn into unauthorized privilege use. |
| Recommendation — Restrict agent server access and require approval for privileged tool paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Allowlisting MCP servers operationalizes minimum necessary access for agents. |
| IA-2 — Identification and Authentication (Organizational Users) | Approved servers still need explicit authentication and verified trust boundaries. | |
| AU-2 — Event Logging | Server and tool actions need traceability for review and incident response. | |
| Recommendation — Limit each agent to approved servers and the minimum tool scope needed. Authenticate the server and the calling principal before enabling tool access. Log server selection, tool invocation, and approval outcomes for each high-risk action. | ||
| NIST Zero Trust (SP 800-207) | 3.2 — Zero Trust Principles | The question is fundamentally about not trusting discovered tools by default. |
| Recommendation — Verify every server and request before granting agent access or action rights. | ||
Practitioner Guidance
What to verify: Check that each MCP server has an owner, a documented purpose, an explicit trust tier, and a reviewed tool inventory before the agent can discover it. If the server can reach production systems, treat that as a separate approval gate.
Decision rule: If a tool path can modify data, issue credentials, invoke privileged workflows, or cross a trust boundary, keep it behind human approval until the surrounding policy, logging, and rollback path are proven.
What good looks like: The agent sees only the servers it is allowed to use, the available tools are predictable, and every high-risk action is attributable to a specific server and policy decision.
Practitioner takeaway: The control objective is not to ban MCP, but to prevent dynamic discovery from becoming dynamic trust; approved capability lists and approval gates should define the agent’s real authority.
Related resources from NHI Mgmt Group
- How should organisations implement an AI gateway when agentic systems connect to models, tools, MCP servers, and internal data sources?
- What are MCP Authorization Extensions and how do they help organizations?
- What is MCP in the context of AI security?
- What are the core risks identified by the OWASP Agentic Top 10?