Arbitrary MCP connections expand trust to external servers that may be malicious, compromised, or impersonating legitimate tools. Once an agent can call those servers, attacker-controlled inputs can shape downstream actions, shadow legitimate tools, or leak data through tool parameters and outputs. The risk rises sharply when the agent reaches sensitive systems such as Slack, GitHub, or internal APIs.
Why arbitrary MCP links magnify prompt-injection exposure
Arbitrary MCP connections are risky because they widen the agent’s trusted tool surface beyond servers you have explicitly reviewed. That matters when the model can treat tool output as actionable context, because prompt injection is then no longer just a text problem, it becomes a control problem over what the agent will execute, forward, or expose.
In practice, an arbitrary connection can let a malicious or compromised server shape the agent’s next step, not just its interpretation of a message. The server can present instructions, return crafted data, or imitate a normal tool response, and the agent may not distinguish legitimate guidance from hostile content once the connection is admitted into the workflow.
Arbitrary MCP also undermines the assumption that “one tool equals one trust boundary.” If the agent can discover and call multiple external servers, an attacker only needs one weak or impersonated endpoint to create a path into a broader workflow. That is why the question is not simply about integration count, but about whether the connection is governed, scoped, and intentionally selected.
How tool abuse happens once the connection exists
Tool abuse usually starts when the agent passes attacker-influenced input into a tool call that was never meant to receive it. A malicious server can exploit that by steering parameters, returning misleading results, or causing the agent to select the wrong tool when several are available. The danger is especially high when the tool can reach sensitive systems or act on the user’s behalf.
The practical failure mode is confused authority. Once the agent has permission to invoke a tool, the server may be able to act as a hidden intermediary between the model and the target system, shaping requests, responses, and context in ways that bypass human review. In other words, the abuse is not limited to a single bad prompt, it can cascade through the toolchain.
Arbitrary MCP connections also make shadow tool behavior more plausible. A server can expose a name, schema, or capability that looks legitimate enough to the agent, while performing a different action behind the scenes. That is how seemingly routine tool use turns into unintended data movement, unauthorized API calls, or workflow manipulation.
Why the blast radius grows around Slack, GitHub, and internal APIs
The risk becomes materially worse when the connected tools can reach collaboration systems, source control, ticketing, or internal APIs. Those targets tend to carry real business authority, so a single bad tool invocation can publish messages, alter code, move tickets, or query data that should never have been exposed to an untrusted server.
This is why MCP governance cannot stop at whether a server “works.” The real question is what the server can reach, what identity or token it uses, and whether its outputs are allowed to influence downstream decisions. If those answers are vague, the connection should be treated as a trust expansion, not a convenience feature.
For agent builders, the core design issue is keeping tool scope narrow enough that one untrusted connection cannot become a general-purpose bridge into production systems. The strongest controls are still the boring ones: explicit allowlisting, least privilege, response validation, and clear separation between read-only context retrieval and action-bearing tool calls.
Risk and Threat Considerations
Arbitrary MCP connections create a classic trust-boundary problem, where the agent begins treating outside servers as if they were part of its own execution environment. That exposes organisations to prompt injection, tool poisoning, data leakage, and unauthorised actions whenever the connected server is malicious, compromised, or simply over-privileged.
Failure mechanism: The agent accepts attacker-controlled content or tool metadata from an external server, then uses that material to select tools, populate parameters, or act on sensitive systems without adequate provenance or policy checks.
Impact: Attackers can redirect workflows, exfiltrate data through tool parameters or outputs, trigger unauthorized Slack or GitHub activity, and turn a single compromised MCP endpoint into broader operational compromise.
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 API Security Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Arbitrary MCP links can be abused to steer agent tool use. |
| ASI03 — Identity & Privilege Abuse | Untrusted MCP servers can expand agent authority into sensitive systems. | |
| ASI01 — Agent Goal Hijack | Prompt injection via MCP can redirect the agent from its intended task. | |
| Recommendation — Constrain tool invocation paths and validate tool inputs before execution. Restrict agent privileges and isolate credentials from untrusted tool servers. Check that external tool content cannot override the agent’s task objective. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tool access can expose functions the caller should not invoke. |
| API2 — Broken Authentication | Arbitrary servers may be impersonated or trusted without strong verification. | |
| Recommendation — Enforce function-level authorization on every exposed tool action. Require strong server authentication before any tool trust is granted. | ||
Practitioner Guidance
What to prioritise: Treat MCP server admission as an access-control decision, not a developer convenience choice. If a server can influence actions or reach business systems, it needs explicit approval, documented scope, and a clear owner.
What to verify: Confirm that each server’s capabilities, identity, and outbound reach are known before it is exposed to an agent. Verify that tool outputs are not being treated as trusted instructions, especially when the server is remote or third-party controlled.
Decision rule: If the connection can touch sensitive systems, or if you cannot explain how it is isolated from untrusted content, do not treat it as a harmless connector. Limit it to the smallest required function, or remove it entirely.
Practitioner takeaway: The key control is not eliminating all MCP connectivity, it is ensuring that no arbitrary server can become a stealth authority path into tools, data, or production actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
