They create a large gap because the model often trusts the server path once it is connected, even if the server has not been deeply vetted. That makes the integration layer a hidden access channel for tool misuse, output manipulation, and exfiltration. The problem is delegated trust without equivalent identity and lifecycle controls.
Why This Matters for Security Teams
Malicious MCP servers matter because they turn a protocol integration into a trust shortcut. Once an agent is pointed at a server, the server can influence tool calls, shape outputs, and potentially steer the agent toward actions that were never approved at design time. That is especially dangerous in agentic workflows where the system is expected to act, not just answer. Guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both point to the same operational problem: the integration layer becomes a hidden control plane if it is not governed like a high-risk workload boundary.
This is not just a prompt-injection issue. MCP servers may proxy credentials, return poisoned context, or expose tools that expand the agent’s reach far beyond what a human reviewer would expect. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks treats delegated trust as a lifecycle problem: if identity, scope, and revocation are not explicit, the server path becomes an open invitation for misuse. In practice, many security teams encounter this only after an agent has already chained tools through an unvetted server and touched data that was never meant to leave its original boundary.
How It Works in Practice
The security gap forms when an MCP client assumes the server is legitimate because the connection succeeded. That assumption is too weak for autonomous systems. A malicious server can advertise harmless tools, then return crafted instructions, misleading metadata, or manipulated results that influence the model’s next action. In effect, the server is not just a data source. It is a policy-shaping input to an agent with execution authority.
Current guidance suggests treating MCP endpoints as untrusted workload peers, not as passive integrations. That means binding every session to explicit workload identity, evaluating policy at request time, and using short-lived credentials that are issued only for the task at hand. In mature designs, the agent should present cryptographic proof of what it is, while the server is limited to a narrowly scoped function and a short TTL. The operational model should align with zero standing privilege, with secret exposure minimized by design and revoked automatically after completion.
Security teams should also separate the server’s ability to answer from its ability to act. That usually requires:
- request-time authorization for each tool invocation, not just at onboarding
- ephemeral tokens or JIT credentials with tight scope and expiration
- allowlists for tools, data domains, and outbound destinations
- logging that preserves the exact server response that influenced the action
- policy-as-code checks at runtime, not only static integration review
NHIMG’s research on The State of MCP Server Security 2025 is a useful reminder that weak scoping is still common in real deployments. The broader agent-risk picture in AI Agents: The New Attack Surface report shows why this matters: if the agent can act beyond intended scope, the server path becomes part of the attack path. These controls tend to break down when MCP servers are embedded in fast-moving CI/CD pipelines because integration speed often outruns identity review, tool scoping, and revocation plumbing.
Common Variations and Edge Cases
Tighter MCP controls often increase operational overhead, requiring organisations to balance integration speed against containment and auditability. That tradeoff is real, especially where teams want to experiment quickly with new tools or internal servers. Best practice is evolving, but there is no universal standard for how much trust an MCP server should receive by default.
One common edge case is the internal server that is treated as safe simply because it is hosted inside the perimeter. That assumption fails when the server itself is compromised, misconfigured, or connected to sensitive systems. Another is multi-agent workflows, where one agent’s trusted tool output becomes another agent’s input. In that scenario, a single malicious server can propagate influence across the pipeline.
Security teams should also be careful with credential handling. If the MCP server can read static secrets from config files or environment variables, the protocol layer can become a secret distribution layer. NHIMG’s MCP research and the OWASP Top 10 for Agentic Applications 2026 both reinforce the same point: trust must be continuously verified, not inherited from connectivity. The gap is largest when long-lived credentials, broad tool permissions, and unattended autonomous execution all exist in the same environment.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Malicious MCP servers exploit agent trust and tool misuse. |
| CSA MAESTRO | GOV-03 | Covers governance for agent-to-tool trust boundaries and approvals. |
| NIST AI RMF | GOVERN | Addresses accountability, oversight, and risk management for autonomous systems. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers excessive trust in non-human identities and delegated access. |
| NIST Zero Trust (SP 800-207) | PR.AC-3 | Supports continuous verification instead of implicit trust in server connectivity. |
Restrict tool authority at runtime and validate every agent action before execution.
