MCP threats are security risks that arise when AI agents use the Model Context Protocol to reach tools, data, or actions. They include prompt injection, unauthorized tool calls, data leakage, privilege abuse, and malicious or compromised endpoints. Because MCP extends agent access, identity controls, authorization, and logging must be tightly enforced.
What MCP Threats Look Like
MCP threats arise when an AI agent uses the Model Context Protocol to reach tools, data, or actions in ways the organisation did not intend. The protocol can become a powerful extension point, but that same reach also expands the blast radius of bad prompts, bad endpoints, and bad authorisation.
At a practical level, the main danger is not the protocol itself, but the trust it creates between an agent and the systems it can call. If that trust is too broad, an attacker can steer the agent into revealing data, invoking actions, or reusing privileges that should never have been exposed in the first place.
Why MCP Becomes a Security Boundary
MCP changes the security model because it lets an agent move from text generation into action. That shift makes the protocol a boundary for both authorisation and accountability, especially when tools can read files, query internal systems, or trigger workflows.
The most important design question is which actions are permitted, under what identity, and with what scope. When those decisions are weak, MCP can turn a normal assistant into a high-impact intermediary that can touch far more than the user intended.
Common MCP Threat Patterns
Several threat patterns recur across MCP deployments. Prompt injection can redirect the agent toward unsafe tool usage, while compromised or malicious endpoints can present legitimate-looking responses that shape the agent’s next action. Data leakage and privilege abuse become more likely when tool outputs are treated as trusted inputs.
Another common failure mode is overreach through token reuse or overly broad delegation. The agent may be granted access that is technically convenient but operationally excessive, which makes a single compromised conversation, connector, or server far more dangerous than it should be.
That is why a practical MCP review should treat tool scope, endpoint trust, and logging as linked controls rather than separate concerns, as reflected in MCP Security Guide and MCP Gateway and MCP Server Governance Guide.
How Teams Reduce MCP Exposure
Good mcp security starts with minimising trust. That means constraining tool permissions, separating high-risk tools from low-risk ones, and making sure the agent cannot silently inherit broader rights than it needs for the task at hand.
It also means reviewing the broader identity model around the agent and its connectors. Short-lived credentials, explicit authorisation boundaries, and strong inventory of exposed servers help reduce the chance that a single compromised integration becomes a persistent access path. For a deeper read on agent-side identity and credential handling, see AI Agent Identity Security: The 2026 Deployment Guide and the agentic AI applications guide.
Detection matters as much as prevention. Teams should log tool calls, authorisation decisions, unusual endpoint selection, and sensitive data movement so they can review whether an agent was manipulated, over-permitted, or used after compromise. The relevant attack mechanics are also covered in the broader OWASP Agentic Applications Top 10 and the breach-focused The State of NHI & AI Agent Breach Report 2026.
Threat Modelling and Monitoring for MCP
MCP threat modelling works best when it focuses on abuse paths, not just implementation bugs. Ask how a hostile prompt, a rogue connector, or a compromised endpoint could cause unauthorised action, data exposure, or escalation through a trusted tool chain.
Monitoring should look for behaviour that does not fit the normal task pattern, such as unexpected tool selection, unusual authority use, repeated failed calls, or access to data outside the task’s likely scope. Those signals often reveal manipulation earlier than a post-incident review does.
For external reference points, the protocol’s authorisation model is described in the Model Context Protocol: Authorization specification, while adversarial technique mapping is helped by the MITRE ATLAS adversarial AI threat matrix and the OWASP Agentic AI Top 10.
Risk and Threat Considerations
MCP increases exposure because it gives an agent a direct path from language to action. If that path is abused, the consequence is often not just bad output, but unauthorised tool execution, sensitive data disclosure, or privilege misuse across connected systems.
Failure mechanism: An attacker injects instructions, compromises an endpoint, or exploits weak authorisation so the agent performs actions or reveals data outside its intended scope.
Impact: The result can be credential exposure, unauthorised system changes, lateral movement through trusted integrations, or persistent misuse of agent-held access.
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 Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP threats center on unsafe tool use by agents. |
| ASI03 — Identity & Privilege Abuse | MCP expands delegated authority, making privilege abuse central. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | Compromised MCP endpoints and connectors create supply-chain exposure. | |
| Recommendation — Constrain agent tool permissions and verify every high-risk tool invocation. Limit delegated authority and bind agent actions to narrowly scoped identities. Assess connector provenance and block untrusted or altered tool endpoints. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | MCP agents and connectors often operate with excess privilege. |
| NHI-02 — Secret Leakage | MCP failures can expose tokens, keys, and other secret material. | |
| Recommendation — Reduce agent and connector privileges to the minimum required scope. Protect secrets from tool outputs and rotate any exposed credentials immediately. | ||
Practitioner Guidance
Why practitioners should care: MCP security is mostly about controlling delegated authority, not just filtering prompts. If the agent can reach a tool, the real question is whether that reach is deliberately bounded, auditable, and revocable.
Governance implication: Treat every mcp server, connector, and tool as part of the access layer. Ownership should be explicit, approval should be deliberate, and logging should be sufficient to explain what the agent did and why.
Practitioner takeaway: The safest MCP deployments are the ones where the protocol can only do narrowly defined work, with narrow credentials, visible decisions, and a clear path to disable or rotate trust quickly.
Related resources from NHI Mgmt Group
- How do software teams decide whether to treat AI agent and MCP-layer threats as an AppSec issue or an identity issue?
- What is the Model Context Protocol (MCP) and why does it matter for security?
- What is MCP Step-Up Authorisation and how does it implement least privilege for agents?
- What are MCP Authorisation Extensions and why do they matter for enterprise governance?