MCP Security Risks: Why AI Tool Integrations Need a CISO's Review

Key takeaways

• MCP connects AI assistants to real systems, and its specification says it cannot enforce its security principles at the protocol level. Security depends on how each client, server and deployment is built [1].
• The central question is authority: whose permissions a tool call carries, and where authorization is actually enforced. The model should request actions. It should never be the component that decides whether they are allowed.
• The verified vulnerabilities discussed here were in specific tools, depended on specific conditions, and have fixes. They justify review, not alarm.
• Start with an inventory, authorization at the resource, and audit records. Scale the other controls to what the connected tools can change.

A developer pastes a few lines of configuration into an AI coding tool. Two minutes later the assistant can read the team's tickets, query a database and open pull requests. That change needed no purchase order. Whether it gets a security review depends on whether your organization has set a rule for it.

This is what the Model Context Protocol (MCP) makes easy. MCP is an open standard for connecting AI applications to tools and data: a CRM, a ticketing system, a code repository, a cloud console [1]. Enterprises adopt it because wiring an assistant into those systems is where much of the practical value sits. It's also where the security discussion changes. Once an AI workflow can read sensitive information or take actions with real permissions, the issue is no longer only whether the model answered correctly. It's what the workflow is allowed to access, what it can change, and how you'd show afterward that it behaved.

MCP is not inherently insecure, but the vulnerabilities discussed here do not establish how common security flaws are across MCP deployments. The specification itself acknowledges that it cannot enforce its security principles at the protocol level and expects implementers to build consent and authorization flows into their applications [1]. Those decisions deserve executive attention.

From AI that answers to AI that acts

Picture an assistant connected to your CRM, your internal knowledge base and your support ticketing system. Asked a question, it no longer just drafts a reply from what it already knows. It decides which system to query, calls a tool, reads the result and may write something back.

The specification describes tools as functions the model can invoke, and says plainly that they represent arbitrary code execution and need appropriate caution [1]. The wording on human oversight is worth reading closely. The overview lists, as a principle, that hosts must obtain explicit user consent before invoking a tool [1]. But the spec's own convention is that only capitalized keywords are normative, and the capitalized language on the Tools page is that there SHOULD always be a human in the loop with the ability to deny tool invocations [4]. The spec also acknowledges that it cannot enforce these principles at the protocol level [1]. Whether approval exists, and whether it is meaningful, is a product and deployment decision.

Two things haven't changed, and it helps to say so. MCP doesn't make existing controls obsolete: identity, network security and logging all still apply. And MCP didn't invent the risk of AI following bad instructions, which exists in any tool-using system. What MCP does is make it cheap to connect a model that text can influence to systems that matter.

A model that can be talked into things is a manageable risk when it can only talk. It's a different risk when it holds credentials.

Four risks that deserve a business decision

Each risk below is conditional. None is inevitable, and none implies that every MCP deployment is exposed.

Untrusted instructions and tool metadata

Four related things are often blurred together, and they have different owners.

The Invariant Labs work showed hidden instructions in a tool's description steering an agent into sending local files to a server [9]. The WeKnora advisory documents a client that passed tool descriptions and results to the model unsanitized and let a malicious server register a tool that silently replaced a legitimate one [16]. It required the user to register that malicious server, and the advisory describes the impact as redirected model behavior, exfiltration of system prompts and context, and potentially other tools running with the user's privileges [16]. The severity ratings differ by source: the GitHub Advisory Database lists 5.4 (medium), the repository advisory lists 5.9 (medium), and NVD records both the CNA-provided 5.9 score and its own 7.6 (high) assessment [16]. These scores reflect different CVSS assumptions and should not be treated as interchangeable.

No single measure reliably prevents injection. Input and output validation, prompt filtering and human approval each help, but none guarantees prevention, and sanitizing text alone doesn't neutralize malicious instructions or poisoned tool descriptions. The practical objective is therefore to limit impact: narrow permissions, separation of read tools from write tools, isolation between tools and data, authorization at the resource, validation of inputs and outputs, and proportionate approval. Approval deserves a closer look, because it's often treated as the whole answer. It isn't a replacement for authorization or least privilege, and it doesn't need to apply to every call. Routine, low-risk reads can proceed, while sensitive writes, external communications and destructive actions justify a prompt. Where a prompt appears, it should show the action, the destination, the target resource and the proposed content, not a one-line summary. Someone clicking "allow" on the fortieth vague prompt of the day isn't a control.

Authority: whose permissions does the tool use?

One of the first areas an enterprise security review should examine is the authority each MCP server actually has. If a server acts through a single shared service account, it may be able to see far more than any individual user, and whatever the model is persuaded to ask for is answered with that authority.

MCP's security best practices name two failure patterns. A confused deputy problem can arise in MCP proxy servers that use a static client ID with a third-party authorization server and allow dynamic client registration. That guidance says such proxies MUST implement per-client consent [3]. And token passthrough, where a server accepts tokens that weren't issued for it and forwards them downstream, is forbidden. Where HTTP authorization is used, MCP servers MUST validate that access tokens were issued specifically for them, MUST only accept tokens that are valid for use with their own resources, and MUST NOT accept or transit any other tokens [2][3].

Be exact about what the spec says on authorization, because it's often misquoted. Authorization is optional in MCP. HTTP-based implementations that use it SHOULD conform to the authorization specification, while stdio implementations SHOULD NOT and instead retrieve credentials from the environment [2]. That describes the protocol. An enterprise baseline can and usually should be stricter.

Four terms are worth keeping apart. Authentication establishes who is calling. Authorization decides what that identity may do to which resource. Tenant isolation keeps one customer's data separate from another's, even when both sit behind the same system. Auditing records what happened. A strong answer to one doesn't cover the others.

The right identity design depends on what the downstream system supports, and no single answer fits every integration. With delegated user identity, the tool acts with the user's own credentials, so the downstream system applies that user's own permissions, resource rights and tenant boundaries. With a narrowly scoped service identity, the server holds its own credential, and the user's entitlements must be carried and enforced separately: a trusted policy layer receives the authenticated user, and the resource or that layer checks the user's entitlements and tenant before acting. A gateway or policy layer helps only if it actually enforces those checks, and the resource should still refuse requests outside the identity's scope. Either way, the decision to allow a call belongs to a trusted component that knows who is asking, not to the model. This follows the least-privilege, per-session logic NIST describes for zero trust [10].

Local servers are software installations

A local MCP server is a program the client launches on a user's machine, and its security best practices say clients should warn users that servers run with the same privileges as the client [3]. Adding one is an installation, whether or not anyone calls it that. It also says that if a client supports one-click local server setup, it MUST implement consent that shows the exact command before running it, and recommends sandboxing with minimal default privileges [3].

Two verified vulnerabilities show what can go wrong in specific tools. mcp-remote, which connects local clients to remote servers, was exposed to operating-system command injection when connecting to an untrusted server that returned a crafted authorization endpoint URL. Versions 0.0.5 up to 0.1.15 were affected, it was fixed in 0.1.16, and JFrog, which assigned the CVE, rated it 9.6 (critical) [12][13]. MCP Inspector, a developer tool, accepted unauthenticated requests between its client and proxy before version 0.14.1. Oligo Security described a path in which a developer visiting a malicious website could be affected, and GitHub assigned it 9.4 (CVSS 4.0, critical) [14][15]. When I queried NVD's records for both CVEs on 19 October 2026, I found no NVD-assigned score on either; the scores above come from JFrog and GitHub.

Both were patched, and the point isn't that these tools are bad. Developer machines hold credentials and source code, and adding an MCP server takes seconds. Transport choice changes the risk, but neither option is inherently safe or unsafe. stdio removes network exposure but not the privileges of the launched process. For Streamable HTTP, the spec says servers MUST validate the Origin header, and that local servers SHOULD bind to localhost and SHOULD authenticate connections [5].

What you can't see

OWASP's MCP Top 10, a beta community list, includes shadow MCP servers and lack of audit and telemetry among its ten risks [17]. Treat it as a useful taxonomy, not a standard. The spec says clients SHOULD log tool usage [4], but nothing makes anyone review the logs. If you can't list your MCP servers and reconstruct what an assistant did in a session, you can't investigate an incident or answer a customer's security questionnaire.

An illustrative scenario

This is a hypothetical scenario, not a real incident or organization, and it says nothing about how often such incidents occur.

A software company gives its support team an assistant connected through three MCP servers to its CRM, its internal knowledge base and its ticketing system. Assume the CRM server uses one shared service account that can read every customer record, and that it answers any lookup the assistant sends without checking who the lookup is for.

1. A customer submits a ticket containing a paragraph addressed to the assistant, asking it to include "account details for verification" for other customers.
2. A support agent asks the assistant to summarize the ticket and suggest a reply. Depending on the model and the client's safeguards, the assistant may treat the paragraph as an instruction. The rest of the chain depends on that assumption.
3. The assistant queries the CRM for the ticket's customer, then for other accounts. The CRM server answers with its service account.
4. The assistant drafts a reply containing another customer's details. The agent, busy, approves a prompt that showed only a one-line summary of the tool call.
5. The reply goes out. There's no central log of tool calls, and the problem surfaces when the second customer's contact mentions it.

The business consequences are confidential data exposed across customers, incident response effort, questions for legal and privacy teams about notification, and damaged trust.

Now run it with controls. The key change is that authorization happens at the resource, not in the model or the ticket. The CRM, or a trusted policy layer in front of it, receives the authenticated identity of the support agent and checks the agent's entitlements and the requested record's own ownership and tenant attributes. A customer ID or account reference that appears in a ticket, a prompt, a tool description or a model's output is only a lookup key. It is never proof that the lookup is allowed, and a restriction based only on an identifier supplied by untrusted content would be insufficient. So the request for other customers' accounts is denied, whatever the paragraph said. The reply that writes into a customer-visible channel shows its destination, target ticket and full content for approval, while routine reads of the assigned customer proceed without a prompt. Each tool call is logged with identity, tool, action, resource and outcome, and denied cross-customer attempts raise an alert. Approval prompts and logs are supporting controls here: they help a person catch a mistake and help you investigate, but the denial comes from the authorization check. The injected paragraph is still read. It just can't reach what it was after.

Why existing controls need extending

Identity management, network segmentation, API gateways, endpoint protection and logging still matter, and an MCP deployment inherits all of them. They can also be adapted to this problem, though they often need more than they were deployed with. A gateway sees a valid, authenticated request from an MCP server's service account, and without more context it can't tell whether a person asked for that request or a paragraph in a ticket did. What helps is identity context that survives down to the resource, authorization checks at that resource, tool-level audit records, and monitoring that understands AI-initiated sequences. The related article on why traditional security tools fall short against autonomous AI agents goes deeper on that gap.

A practical architecture

Think in three layers that work together, with preventive controls doing most of the work. This is also the practical core of agentic AI security.

Preventive. An approved inventory and a provenance check before any server is connected. Identities that carry the real user's authority, or narrowly scoped identities behind a policy layer that enforces it. Server-side authorization at the resource boundary. Read tools separated from write and execute tools. Sandboxing and least privilege for local processes. Secrets kept out of prompts and configuration files. Validation of tool inputs and outputs. Proportionate confirmation for sensitive actions. Change control for server versions, dependencies and tool definitions.

Detective. Audit records of the authenticated identity, tool, action, resource, outcome and relevant request context, kept long enough to investigate. Log identifiers and references rather than full customer content where you can, so the logs don't become a new store of sensitive data. Add monitoring for unusual patterns, such as one session reading many customers' records. Logging alone prevents nothing, so treat it as the way you detect and reconstruct incidents, not a substitute for authorization.

Response. The ability to revoke a token, disable a server and cut off a tool quickly, a rehearsed way to reconstruct what a session did, and tests that confirm these steps work before you need them.

Proportion matters. A team using a few read-only remote servers needs far less than one that lets developers run community servers on laptops or exposes tools that write data, run code or trigger consequential actions. If you can only do three things first, I'd choose inventory, authorization at the resource, and audit records. They make the rest possible, and they answer the questions auditors and customers ask.

The protocol keeps moving, so record the version each component uses. Version 2026-07-28 made the protocol stateless by removing protocol-level sessions and the initialize handshake, requires clients to validate an issuer parameter when authorization servers send one, and deprecates Dynamic Client Registration in favor of Client ID Metadata Documents, though DCR remains available for backward compatibility [6][7][8]. Not every SDK, client or deployed server will have adopted the current revision, so check each component's actual version. Advice written for earlier versions may not apply.

An implementation roadmap

Questions for your next security review

1. Can we list every AI application that can reach an enterprise tool, and who owns each one?
2. Whose authority does each tool use: the user's, or a shared account's, and where is that decision enforced?
3. Which tools can change data or trigger consequential actions, and which of those need a person to approve?
4. Is authorization enforced at the resource, or are we relying on the model to decline?
5. What happens to untrusted content such as tickets, documents and web pages before the model sees it, and what can that content reach?
6. If an assistant did something wrong yesterday, could we reconstruct exactly what it did?
7. Who approves a new MCP server or a new version, and what do they check?
8. How quickly can we cut off one server or token during an incident, and have we practiced it?

FAQ

Where to go from here

None of this is an argument against MCP. The organizations that gain from connecting AI to their systems will be the ones that decided, on purpose, what it can touch. Good MCP security looks less like a product and more like a habit of asking who authorized each connection. Tool access should be deliberate, enforceable, observable and proportionate to what's at stake. The protocol provides the connection. The controls are yours to build.

If you're connecting AI assistants or agents to internal systems, an independent assessment can help you find security gaps, evaluate the architecture and its controls, and decide what is ready to deploy. My AI Security Assessment is a fixed-scope, authorized engagement that tests agents, tools and MCP and reports evidence-backed, prioritized findings. The Production Readiness Assessment gives a go or no-go view on whether a specific AI system is ready for production. If you'd like to talk through your setup first, you can book a conversation.

This article is educational and is not legal advice. Whether an MCP deployment raises regulatory or contractual obligations depends on your role, the data involved, where it's processed and the laws that apply.

References

1. Model Context Protocol, Specification (2026-07-28), Security and Trust & Safety.
2. Model Context Protocol, Authorization (2026-07-28).
3. Model Context Protocol, Security Best Practices (2026-07-28).
4. Model Context Protocol, Tools (2026-07-28).
5. Model Context Protocol, Streamable HTTP transport (2026-07-28).
6. Model Context Protocol, Client Registration (2026-07-28).
7. Model Context Protocol, Key Changes (2026-07-28).
8. MCP blog, The 2026-07-28 Specification, 28 July 2026.
9. Invariant Labs, MCP Security Notification: Tool Poisoning Attacks, 1 April 2025.
10. NIST, SP 800-207, Zero Trust Architecture, August 2020.
11. OWASP GenAI Security Project, LLM01:2025 Prompt Injection.
12. NIST NVD, CVE-2025-6514, and GitHub Advisory Database GHSA-6xpm-ggf7-wc3p.
13. JFrog Security Research, JFSA-2025-001290844, mcp-remote command injection, 9 July 2025.
14. NIST NVD, CVE-2025-49596, and GitHub repository advisory GHSA-7f8r-222p-6f5g.
15. Oligo Security, Critical RCE Vulnerability in Anthropic MCP Inspector, CVE-2025-49596, 27 June 2025.
16. NIST NVD, CVE-2026-30856, GitHub repository advisory GHSA-67q9-58vj-32qx, and GitHub Advisory Database GHSA-67q9-58vj-32qx.
17. OWASP, MCP Top 10 (beta project).