MCP security is the work of controlling what AI agents can reach through the Model Context Protocol: which MCP servers are allowed, what each tool can do, whose authority it acts on, and what record it leaves. MCP is the open protocol that lets an AI application such as Claude, ChatGPT, Cursor or Copilot call tools and read data through a standard interface. Each MCP server a team connects is a new route from a language model to a file system, a database, a SaaS tenant or a production API.
That route is useful because it lets agents act. It is a security problem for the same reason. A model that can call a tool can be talked into calling it, and the protocol leaves most of the controls to the people who build and run the servers. This guide sets out the MCP-specific threats, the controls the protocol's own security guidance asks for, and a checklist your team can use before approving a server. For the wider question of securing AI agents, see our guide to agentic AI security.
What is MCP, and why does it change the attack surface?
The Model Context Protocol defines how an MCP client (the AI application) talks to an MCP server (a wrapper around a tool or data source). A server advertises tools, each with a name, a description and an input schema. The model reads those descriptions, decides which tool to call and with what arguments, and the server carries out the call with whatever credentials it holds.
Three things make this different from an ordinary API integration.
- The model chooses the call. In a normal integration a developer writes the request. With MCP, the model decides at run time which tool to call and with what parameters, based on text it has read. Anything that can put text in front of the model can influence that choice.
- Tool descriptions are instructions. The description of a tool is written for the model, not the user. Most clients show the user a short name, while the model reads the whole description.
- Servers run with real authority. A local server runs with the privileges of the user's machine. A remote server acts with an OAuth token or API key. Either way, the tool call happens with an identity your security team may never have approved for that purpose.
A 2026 review of MCP in ACM Transactions on Software Engineering and Methodology maps threats across the MCP server lifecycle. It lists log audit, centralised log aggregation and integrity-protected storage as safeguards the operator has to add, not features the protocol provides (Hou et al., 2026). Our comparison of what Claude Code, Cursor, OpenAI, Copilot and MCP servers log shows the same gap from the logging side: an MCP server logs whatever its author chose to log.
What are the main MCP security risks?
The risks fall into two groups: attacks on what the model reads, and attacks on the authority the server holds.
Attacks on what the model reads
Tool poisoning. Instructions hidden in a tool description are invisible to the user but read by the model. Invariant Labs demonstrated in April 2025 that a poisoned description can tell the model to read a sensitive file and pass it to the attacker as a tool argument, while the user sees an ordinary tool.
Rug pulls and shadowing. The same research showed that a server can change a tool's description after a user has approved it, and that a malicious server can add instructions that change how the model uses a trusted server's tools. Approval at install time is not approval of what the tool says next week.
Indirect prompt injection through tool output. A web page, ticket, email, README or database row returned by a tool can carry instructions the model follows as if the user had written them. Greshake and colleagues showed this class of attack against real LLM-integrated applications (Greshake et al., 2023), and a 2026 review of prompt injection in agent systems finds that MCP has widened the attack surface, adding vulnerabilities such as tool poisoning and credential theft (Gulyamov et al., 2026). OWASP ranks it first in its Top 10 for LLM applications as LLM01.
Attacks on the authority the server holds
The MCP project's own security best practices name these attacks and their mitigations.
- Token passthrough. A server accepts a token that was not issued to it and forwards it to a downstream API. The authorisation specification explicitly forbids this, because it bypasses controls such as rate limiting and audience checks, and breaks the audit trail.
- Confused deputy. A proxy server using a static client ID with a third-party authorisation server can be tricked into granting an attacker access on a user's behalf if it skips per-client consent.
- Excessive scope. A server that requests every scope up front gives a stolen token a wide blast radius. The guidance asks for a minimal initial scope and step-up requests when a privileged tool is first used. OWASP lists the general pattern as LLM06, Excessive Agency.
- Local server compromise. A local server is a program running on the user's machine. A malicious start-up command in a client configuration, a malicious package, or an insecure local server reachable through DNS rebinding can all lead to arbitrary code execution with the user's privileges.
- Server-side request forgery and session hijacking. A server that fetches URLs supplied during authorisation, or that trusts a session identifier without binding it to the user, can be turned against internal systems or other users.
The supply-chain risk underneath
Most MCP servers are open-source packages installed by developers. That puts them in the same place as any other dependency: typosquatting, compromised maintainers and unpinned versions all apply. OWASP lists this as LLM03, Supply Chain. The difference is that an MCP server is a dependency the model can be persuaded to use.
How do you secure MCP?
The controls divide between the people who build servers, the people who run them, and the security team that has to answer for them.
For server builders, the protocol guidance is specific: validate that every token was issued to your server, never pass tokens through, apply per-client consent on proxies, keep scopes minimal and step up for privileged tools, bind sessions to users, and sandbox anything that runs locally. The UK NCSC's guidelines for secure AI system development set the broader expectation that security is designed in across design, development, deployment and operation.
For platform teams running MCP, the controls are the ones you would apply to any privileged integration, applied to a new kind of client:
- Approve servers explicitly. Keep an allow-list of servers and versions, and block the rest at the client or gateway.
- Pin and re-review. Pin each server to a version and a hash of its tool descriptions. Treat a changed description as a new approval.
- Give each server its own identity. One service identity per server, with scopes that match what its tools actually do.
- Require a human for consequential tools. Anything that deletes, pays, sends, deploys or changes access should need an approval step outside the model.
- Separate untrusted content. Keep tools that read untrusted content (web, email, tickets) apart from tools that can act, or require approval when output from one feeds the other.
- Log the whole chain. Record the prompt context, the tool call, the identity used, the network destination and the change in the target system, and keep it long enough to investigate.
For the security team, the harder question is visibility. Shadow MCP is real: a developer can wire a server into Cursor or Claude Code on a Friday afternoon, and no central system records it unless you look for it. Start with an inventory of which AI clients are in use, which servers they connect to, which OAuth grants those servers hold and who owns each one.
The MCP security checklist
Use this before approving an MCP server, and again when it changes. Each check names the evidence to ask for, so the answer is a record rather than an assurance.
| # | Check | Why it matters | Evidence to ask for | Reference |
|---|---|---|---|---|
| 1 | The server is on an approved list, with a named owner | Unapproved servers are the most common route in | Allow-list entry, owner, business purpose | NCSC secure AI guidelines |
| 2 | The version and tool descriptions are pinned | Descriptions can change after approval (rug pull) | Version, package hash, hash of tool descriptions | Invariant Labs, 2025 |
| 3 | Tool descriptions have been read in full by a person | Hidden instructions target the model, not the user | Review record of every description | OWASP LLM01 |
| 4 | The server validates the token audience and never passes tokens through | Token passthrough is forbidden by the specification | Code review or vendor statement on audience checks | MCP security best practices |
| 5 | Scopes are minimal, with step-up for privileged tools | A stolen broad token has a wide blast radius | Scope list per tool, step-up flow | MCP security best practices; OWASP LLM06 |
| 6 | The server runs under its own identity, not a user's | Shared identities break attribution and revocation | Service principal or client ID per server | NIST AI RMF, Govern |
| 7 | Proxy servers obtain per-client consent | Static client IDs enable confused-deputy attacks | Consent flow design | MCP security best practices |
| 8 | Local servers are sandboxed and start-up commands are reviewed | A local server runs with the user's privileges | Sandbox configuration, reviewed client config | MCP security best practices |
| 9 | Consequential tools need human approval outside the model | The model can be persuaded to call any tool it holds | Approval policy per tool, approver names | OWASP LLM06 |
| 10 | Untrusted-content tools are separated from action tools | Indirect prompt injection turns reading into acting | Tool pairing rules, approval on crossover | Greshake et al., 2023 |
| 11 | Tool calls are logged with identity, parameters and destination | The protocol does not require a call log | Sample log record joined to identity | Hou et al., 2026 |
| 12 | Logs are retained centrally and protected from change | Local logs vanish with the laptop | Retention period, storage location, integrity control | Hou et al., 2026 |
| 13 | You can revoke the server's access in one step | Incidents need fast containment | Revocation runbook, last test date | NCSC secure AI guidelines |
| 14 | You can reconstruct and reverse one real tool call end to end | Proof is the only test that counts | A worked reconstruction from prompt to target-system change | NIST AI RMF, Manage |
Checks 11 to 14 are where most organisations fail, because the evidence sits in different places: the AI provider holds the session, the identity provider holds the token, the MCP server holds whatever it logged, the network holds the destination and the target system holds the change. Our guide on why provider logs can't prove what your AI agent did walks through that chain.
How MCP security maps to the frameworks
MCP does not have its own compliance regime, but the controls above map onto the frameworks your auditors already use.
| Framework | Where MCP controls fit |
|---|---|
| OWASP Top 10 for LLM applications (2025) | LLM01 Prompt Injection (checks 3, 10), LLM03 Supply Chain (checks 1, 2), LLM06 Excessive Agency (checks 5, 9) |
| NIST AI Risk Management Framework | Govern (owners, approvals), Map (inventory of servers and tools), Measure (logging and testing), Manage (revocation and reversal) |
| UK NCSC secure AI system development | Secure design (scopes, separation), secure deployment (sandboxing, pinning), secure operation (logging, incident response) |
| ISO/IEC 42001 | AI system inventory, roles and responsibilities, operational controls and records; see our AI governance framework mapping |
Where SenseOn fits
SenseOn's Security for AI is built for the part of MCP security that sits outside any single server: knowing what your AI can do, proving what it did and reversing what went wrong.
- Find the servers you did not approve. SenseOn's 7-day AI-use inventory maps AI use from sign-ins to AI services, OAuth grants to agents and MCP tools, and the accounts behind them. You get a human-reviewed list of who owns each AI system, agent or MCP tool acting in your estate, and which actions lack an approval gate. Day one needs nothing installed.
- Join the chain. An MCP tool call leaves pieces of evidence in the provider, the identity system, the network and the target system. SenseOn connects provider, identity, tool, network and target-system evidence into one chain, so checks 11 and 14 have an answer.
- Hold the authority. The Agent Control Plane holds identity, tool scopes, policy, approval, timeout and escalation for every agent that acts, including agents you did not build. Containment and rollback run under policy you set, with named approvers.
- Keep the record. For SenseOn's own agents, Decision Trace records the task, the evidence, the agent's contribution and the human decision.
Server hardening, checks 4 to 8, stays with the teams that build and run each MCP server. SenseOn gives the security team the estate-wide record that tells them which servers exist, what they touched and whether it can be undone. See Security for AI for the full picture.
Frequently asked questions
What is MCP security?
MCP security is the set of controls that govern what AI agents can do through the Model Context Protocol: which servers are approved, what each tool can reach, whose identity it acts with, when a person must approve, and what record the call leaves. It covers the servers themselves and the estate around them.
Is MCP secure?
The protocol defines an authorisation model based on OAuth and publishes security best practices, but it leaves most controls to implementers. It does not require servers to log calls, pin tool descriptions or sandbox local processes. A deployment is as secure as the servers you allow and the controls you add around them.
What is MCP tool poisoning?
Tool poisoning hides instructions in a tool's description. The model reads the full description and may follow those instructions, for example by reading a sensitive file and sending it as a tool argument, while the user sees only the tool's name. Pinning and reviewing descriptions, and treating a changed description as a new approval, are the main defences.
How do you find shadow MCP servers?
Look at OAuth grants and service principals created for AI tools in your identity provider, at agent and MCP processes and configuration files on developer machines, and at network traffic to AI providers and remote MCP endpoints. Then give each one an owner or remove it.
Should MCP tool calls go to the SIEM?
Yes, but a tool call on its own answers little. To investigate or prove what happened, the call has to be joined to the prompt context, the identity, the network destination and the change in the target system, and kept long enough to be useful.
Sources
- Hou, X. et al. (2026). Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions. ACM Transactions on Software Engineering and Methodology.
- Greshake, K. et al. (2023). Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. ACM Workshop on Artificial Intelligence and Security.
- Gulyamov, S. et al. (2026). Prompt Injection Attacks in Large Language Models and AI Agent Systems: A Comprehensive Review. Information, 17(1), 54.
- Model Context Protocol. Security best practices.
- Model Context Protocol. Authorization specification.
- OWASP. Top 10 for LLM Applications.
- OWASP. Agentic AI: Threats and Mitigations.
- NCSC. Guidelines for secure AI system development.
- NIST (2023). AI Risk Management Framework 1.0.
- Invariant Labs (2025). MCP security notification: tool poisoning attacks.
How SenseOn writes, checks and corrects its content: editorial standards.
