MCP servers expand risk because they let an AI tool launch commands or connect to remote services through user-approved configurations. If attackers can influence the installation flow, they may gain code execution, credential access, or persistence. This is especially dangerous on developer workstations that already hold SSH keys, API tokens, cloud credentials, and source code.
Why This Matters for Security Teams
MCP servers change agentic ai from a read-only assistant into a component that can invoke tools, reach services, and act on behalf of a user or workflow. That shifts the risk from model output quality into execution authority, which is where compromise becomes operational. The concern is not just prompt injection. It also includes malicious server discovery, unsafe tool registration, overbroad permissions, and credential exposure on endpoints that were never hardened for autonomous tool use. Guidance from the NIST AI Risk Management Framework is clear that AI systems should be governed as sociotechnical systems, not isolated prompts.
Security teams often miss this because MCP looks like integration plumbing, while the actual attack path is identity and execution abuse. If a server can read files, call APIs, or launch commands, then the AI client becomes a broker for privilege rather than a simple interface. In practice, many security teams encounter MCP abuse only after a trusted workstation has already been used to stage access into source code, cloud credentials, or internal services, rather than through intentional monitoring.
How It Works in Practice
MCP servers increase attack surface by adding more software, more trust relationships, and more places where the AI client can be misled. A server may expose tools, data sources, or actions that the agent can invoke automatically. If installation, discovery, or approval workflows are weak, an attacker can insert a malicious server, alter an existing one, or trick the operator into granting broader scope than intended. That is why the agentic AI control problem now overlaps with software supply chain security and runtime authorization, as reflected in the OWASP Agentic AI Top 10 and MITRE ATLAS adversarial AI threat matrix.
Common failure paths include:
- tool poisoning, where a server exposes unsafe actions or misleading metadata
- prompt injection that causes the agent to call a higher-risk tool than intended
- credential harvesting from developer environments that already contain tokens and keys
- persistence through startup hooks, config files, or approved integrations
- lateral movement from a local agent session into internal systems or SaaS APIs
Operationally, the right response is to treat MCP servers as privileged dependencies. That means allowlisting trusted servers, validating provenance, pinning versions, restricting file and network access, separating dev and production identities, and logging every tool invocation with sufficient context for review. Mapping these controls back to NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams translate agent activity into enforceable policy. These controls tend to break down when personal developer laptops are used as the primary execution environment because local credentials, broad filesystem access, and ad hoc approvals collapse the boundary between user intent and tool authority.
Common Variations and Edge Cases
Tighter MCP controls often increase friction for developers, requiring organisations to balance agent autonomy against operational speed. That tradeoff is real, and best practice is still evolving for how much approval a safe agent should need. The current guidance suggests that higher-risk tools should require explicit human review, while low-risk read operations may be automated if provenance and logging are strong.
Not every MCP deployment carries the same exposure. A read-only server used for documentation search is not equivalent to a server that can modify infrastructure, run shell commands, or access secrets stores. Risk also rises sharply when MCP is chained with other agent capabilities, because a seemingly harmless data lookup can become a stepping stone to code execution or exfiltration. The CISA cyber threat advisories and the MITRE ATT&CK Enterprise Matrix are useful for thinking about the downstream techniques once the agent boundary is crossed.
For environments with regulated data or production access, the safest pattern is to split identity, isolate execution, and require separate approvals for installation, network reach, and command execution. Where this breaks down is in fast-moving teams that permit self-serve MCP server installs without central inventory, because there is then no reliable way to distinguish legitimate automation from quietly introduced remote control.
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 MITRE ATLAS 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 |
|---|---|---|
| NIST AI RMF | AI risk governance is needed when agents can trigger tools and actions. | |
| OWASP Agentic AI Top 10 | Agentic app risks include tool misuse, prompt injection, and unsafe action scopes. | |
| MITRE ATLAS | ATLAS maps adversarial techniques used against AI-enabled workflows and integrations. | |
| NIST CSF 2.0 | PR.AC-4 | MCP access must be limited so agents only reach approved resources and actions. |
Establish governance, accountability, and monitoring for agent actions that extend beyond model output.
Related resources from NHI Mgmt Group
- Why do public MCP servers increase risk in developer environments using local AI tools?
- Why does Agentic AI make NHI attack surface expand so significantly?
- Why do non-human identities increase attack surface in cloud environments?
- Why do MCP environments increase identity governance complexity for AI agents?
