What is MCP security and what to check in a pull request

How does an MCP server get into a repository?

This post looks at the configuration a pull request brings for a coding agent. In the hooks post we covered the commands an agent runs on its own at set points, and in the post on reviewing AI-generated code the code the agent writes. The subject here is the file that gives the agent a new tool.

MCP (Model Context Protocol), as the specification itself defines it, is an open protocol that connects AI applications to external data sources and tools. The agent sits on one side and an MCP server on the other. The server defines the tools the model can call: reading an issue, opening a browser, querying a database. As of 18 October 2026, the latest revision of the specification is dated 2026-07-28.

Most of the time the server is a program running on your own machine. The coding tool starts it from the command and args lines of the configuration file and talks to it over the program’s standard input and output; the specification calls this stdio. For a remote server, the file holds an address (url) instead of a command. The file is committed with the code: Claude Code’s documentation recommends putting .mcp.json under version control so that everyone on the team uses the same tools. Each tool looks at a different file:

Source: each tool’s own MCP documentation, 18 October 2026. Copilot CLI does not read VS Code’s .vscode/mcp.json. In Antigravity CLI, the repository’s file is .agents/mcp_config.json.

The MCP specification says what this means in one sentence: “Tools represent arbitrary code execution and must be treated with appropriate caution.” The specification’s security guide also asks clients to warn the user that MCP servers run with the same privileges as the client. So a line added to .mcp.json is the name of a program that will run on the machine of everyone on the team, with their permissions.

What is tool poisoning?

The model decides when and how to call a tool by looking at the tool’s name and description. Invariant Labs described the gap this leaves in a post dated 1 April 2025: the model reads the whole description, while the user usually sees a simplified version of it in the interface. Tool poisoning means hiding instructions in that description that the model reads and the user does not see. Invariant’s example is a tool that adds two numbers:

The server’s code does nothing harmful: it adds two numbers. The model does the harm. It follows the instruction in the description, reads two files and sends their contents to the server in the sidenote argument. The instruction also tells it not to mention this to the user. Invariant tried the tool with Cursor and showed the agent leaking the user’s mcp.json file. The MCP specification asks clients to show tool inputs to the user before calling the server, so that data does not leak out.

Invariant points out two more things. The first is the rug pull: a malicious server can change a tool’s description after the client has approved it. The specification, too, says a server’s list of tools may change over time. The second is the measure they recommend: pinning the version of the server and its tools.

The MCP specification does not use the name “tool poisoning”, but it looks at the problem from the same angle: descriptions of a tool’s behaviour should be treated as untrusted unless they come from a trusted server. Microsoft’s security blog says the same thing: a change to a tool’s description can redirect the agent’s behaviour as effectively as a change to its system prompt.

There is also a study that measures how often this attack works. MCPTox built 1,348 poisoned test cases on 353 tools from 45 real MCP servers and ran them against 20 model settings. The average attack success was 36.5%; the highest rate, 72.8%, was with o1-mini. The model that refused the attack most often was Claude-3.7-Sonnet, and even its refusal rate was below 3%. These are the models of 2025, when the first version of the paper was written; today’s models were not measured in this study.

In OWASP’s MCP Top 10, which is in beta, the third item (MCP03) is Tool Poisoning. The item’s detail page says such a description can be spotted by reading it before installation, and lists five signs. The “server’s own code” question in the checklist below comes from these signs.

Why would an agent do the wrong thing while reading an issue?

The second route runs through the content the server brings back. The tool’s description may be clean; but if the tool fetches an issue, a web page or a chat message, that text enters the model’s context too, and any instruction in it is read as well. This is called indirect prompt injection.

An example from Invariant Labs dated 26 May 2025 showed this with GitHub’s official MCP server. An attacker opens an issue in a public repository. When the user asks the agent to look at the open issues, the agent reads that issue, pulls information from the user’s private repositories into its context, and writes it into a pull request it opens itself in the public repository. The authors write that this is not a bug in the GitHub MCP server’s code: the problem lies in the architecture of the agent system.

The danger is not in any one capability but in having them together: the same agent can read text from outside, reach private data and write somewhere everyone can see. Invariant recommends limiting the agent to one repository per session. Approving every tool call is not enough on its own either; according to the authors, many users switch on “Always Allow” and stop following each action. Claude Code’s documentation gives the same warning: “Servers that fetch external content can expose you to prompt injection risk.”

The same route can lead to the agent writing its own MCP configuration. According to NVD’s record CVE-2025-54135, in Cursor before 1.3.9, if .cursor/mcp.json did not exist yet, an indirect prompt injection could steer the agent into writing that file, and code could run without the user’s approval. Today Claude Code counts .mcp.json among its protected files and never auto-approves a write to it, except in the mode that skips every permission prompt. Cursor does not let the agent change configuration files without approval either. If a pull request opened by an agent touches the MCP file, check who asked for that change.

The server’s own code has to hold up against that text too. According to the MCP specification, tools are called by the model, which means the model also writes their arguments. If a text the model reads can steer it, that text can decide an argument as well. The NVD records published for the reference Git MCP server (mcp-server-git) show two bugs to look for in such code:

Source: NVD records, 18 October 2026. NVD published the first two records on 17 December 2025.

The fixes also tell you what to look for: rejecting an argument that starts with -, resolving the requested path with symbolic links followed, and checking that it stays inside the allowed folder.

When do the tools start an MCP server from the repository?

Each tool lets a server that comes with the repository in through a different door. The table below is what we read in each tool’s own documentation on 18 October 2026:

Source: each tool’s own documentation, 18 October 2026. “Not stated in the documentation”: in the pages we read that day, we found no sentence that describes this case. Nor does the documentation say what happens to the repository’s servers in Gemini CLI while folder trust is off. Check Point writes that since version 1.3 Cursor asks again on every change; Cursor’s documentation has no such sentence.

The word that comes up most in the table is trust. Most tools open the repository’s servers not one by one, but together with the trust you give a folder or a workspace. That is why VS Code’s documentation tells you to look at the MCP configuration before you trust a repository: local MCP servers can run code on your machine.

How many clicks it takes to get past the trust question matters too. Adversa AI writes in its TrustFall post of 7 May 2026 that the four CLIs it tested (Claude Code, Gemini CLI, Cursor CLI and Copilot CLI) could run the MCP servers defined in a repository the moment folder trust was accepted, and that in all four the default option was “Yes/Trust”. According to the post, what made this possible in Claude Code 2.1.129 were the enableAllProjectMcpServers and enabledMcpjsonServers settings committed to the repository. Claude Code’s current documentation says these settings are ignored when they come from the repository and the folder is untrusted; what happens after you trust the folder is not stated in the documentation.

On 18 June 2026, Google stopped serving Gemini CLI to free users and to Google AI Pro and Ultra subscribers and pointed them to Antigravity CLI; with a paid API key or a company licence you can keep using Gemini CLI. We read Antigravity CLI’s documentation on 28 October 2026. According to its MCP page, a repository’s servers live in .agents/mcp_config.json and the user’s in ~/.gemini/config/mcp_config.json; the first is the file to watch for in a pull request. By default, an MCP tool that your permission rules do not mention asks for approval before it is called. The CLI also asks whether you trust the folder. The documentation does not say whether the repository’s servers wait for that answer, or whether the CLI asks again when the configuration changes.

What happens if the server changes after approval?

Approval is given once, while the server keeps changing. The vulnerability Check Point Research named MCPoison showed where that can lead: Cursor tied trust to the server’s name and did not check whether the command or the arguments had changed. According to the NVD record (CVE-2025-54136), in Cursor 1.2.4 and earlier, anyone who could write to a shared repository could swap a harmless server that a teammate had approved once for a malicious command, without any warning or new approval prompt.

Check Point reported the vulnerability to Cursor on 16 July 2025, and Cursor fixed it on 29 July 2025 with version 1.3. According to Check Point, any change to the configuration, even an added space, now asks for approval again. We found no sentence describing this behaviour in Cursor’s own documentation.

The other tools’ documentation either gives this question a different answer or does not touch it. VS Code is explicit: in a workspace you trust, the servers in .vscode/mcp.json and in the root .mcp.json can start without a separate MCP approval prompt, “including after their configuration changes”. In Claude Code, the approval list (enabledMcpjsonServers) holds the servers’ names; whether it asks again when the command changes under the same name is not stated in the documentation. The MCP documentation of Cursor, Codex and Gemini CLI has no sentence on this either.

For comparison, Codex and Gemini CLI do answer the same question for hooks. Codex asks you to review and trust the exact definition of a hook that comes from the repository before it runs. Gemini CLI treats a hook whose name or command has changed as a new, untrusted hook and warns you before running it. Neither documentation has a similar sentence for MCP servers.

A server’s tools can also change while it runs. The server announces this with a notification (list_changed); in an interactive session, Claude Code fetches the tool list again when that notification arrives. Whether the changed descriptions are shown to the user is not stated in the documentation.

In short, the approval on your laptop saw the server as it first was. Even if the name stays the same, the place where you can see its later versions is the pull request’s diff.

Does an agent running in CI load the repository’s MCP servers?

In a non-interactive run there is nobody to give approval. Claude Code’s documentation says so plainly: in claude -p runs, Agent SDK sessions and cloud sessions, Claude Code cannot show the approval prompt and loads project servers without asking. The table in the permissions documentation takes a claude -p run in a folder that was never trusted, and describes its .mcp.json servers in one sentence: “Connected without asking, approved or not.”

Before you run claude -p in a repository you didn’t write, Claude Code’s documentation points to these options:

• --setting-sources user: reads neither the project’s settings files nor its .mcp.json.
• --bare: reads no hooks, skills, subagents, plugins or .mcp.json servers from the project; the project’s env block still applies.
• --strict-mcp-config: uses only the servers you pass with --mcp-config.
• disabledMcpjsonServers: blocks a server by name, in every permission mode.

The other tools behave differently. The prompt mode of Copilot CLI (copilot -p) loads project servers on its own if the folder is already trusted, and skips them if it is not. In Cursor CLI, the --approve-mcps flag approves every MCP server automatically, and --trust trusts the workspace without asking in headless mode. If a workflow file adds one of these flags, read it as an MCP change too. The documentation of Codex and Gemini CLI does not say what happens to a repository’s server in a non-interactive run.

On the side of the GitHub Action that runs on pull requests, there is one more distinction. The security documentation of claude-code-action says that when the action runs on a pull request, it restores a fixed list of Claude’s configuration paths (8 paths, .mcp.json among them) from the base branch before Claude starts; the versions the pull request brings are kept in a separate folder, for reference only. The rest of the working tree stays as it is in the pull request. The lower-level claude-code-base-action, on the other hand, does not do this restore. Adversa’s TrustFall post had written that with the official action’s default setup the trust prompt never appears, and that the attack runs against pull request branches without anyone touching anything; the action’s current documentation describes the restore above.

In GitHub Copilot’s cloud agent, the MCP configuration is not a file in the repository: it is entered in the repository’s settings on GitHub.com, and Copilot code review uses the same configuration. So it does not show up in the pull request’s diff. According to the documentation, the agent uses these tools without asking for approval, which is why GitHub recommends allowlisting specific read-only tools one by one.

What is on OWASP’s MCP risk list?

OWASP’s MCP Top 10 groups the risks specific to MCP under 10 headings. The page itself says the list is in beta. On 18 October 2026, the headings on owasp.org read as follows:

Source: owasp.org, 18 October 2026. The project’s GitHub repository gives MCP06 as “Intent Flow Subversion” and lists the next release as October 2026; the names may change.

Use the list as a shared vocabulary rather than a standard: it helps you put a name to a finding. Most of the questions below map to MCP01, MCP03, MCP04, MCP05 and MCP06.

What should you check in a pull request that changes an MCP file?

Everything so far leads to one conclusion: the approval screen saw the server as it first was, and you can read every later change in the pull request. The example below shows three things a pull request can change in an MCP file, all in one place:

The first change is the easiest to miss: the name docs stayed the same, but a different program now runs, and that program is a script in the repository. The script can change in this pull request or in later ones; what the server does now depends on that file being reviewed. The second server will download whatever version of the package is current each time it starts, and will take a token from the environment.

In a diff like this, go through these questions in order:

• The command, the arguments and the address. MCP’s security guide asks clients that set up a server in one click to show the command that will run, with its arguments and without truncating it. In a pull request these lines are already in front of you; if the command runs a script in the repository, read that script too. For a remote server, check who the address belongs to and whether it uses https. The guide also explains, separately, that an OAuth address supplied by a malicious server can go as far as running code on the client.
• The version. @latest, or a package name with no version, can bring different code each time the server starts. Invariant recommends pinning the version of the server and its tools; on OWASP’s list, the supply chain is an item of its own (MCP04).
• A server that changes under the same name. MCPoison came from exactly this line. If approval is tied to a name, a new command can stand behind the old approval for as long as the name stays the same. Read such a change as a new server.
• Approvals that come with the pull request. Claude Code writes the enableAllProjectMcpServers and enabledMcpjsonServers settings to .claude/settings.local.json when you give approval; they record a personal choice. Seeing them in the shared .claude/settings.json means one person’s approval is being handed out to everyone. In Gemini CLI, "trust": true skips every confirmation for that server, and the documentation recommends it only for servers you fully control; whether it applies when written in the project file is not stated in the documentation.
• Secrets. Check which variable goes into the env and headers fields, and what that token can reach. Claude Code and Cursor support reading a key from an environment variable instead of writing it into the file; that takes the secret out of the file, but does not stop it from reaching the server. Gemini CLI does not pass sensitive variables from the base environment to the server, but it treats a variable written explicitly in the env field as the user’s informed consent and does not redact it. The person who reads that line in the pull request is the one giving that consent.
• Helper commands. Claude Code runs headersHelper as an “arbitrary shell command”; in Codex, http_headers_helper is a local command too. Read them as you would read the server itself.
• Tools that read outside text. If a server that reads issues, web pages or chats is added next to a server that reaches private data, look at the two together. The GitHub example came from exactly this pair.
• The server’s own code. If the code is in the pull request, look for arguments that start with - and paths that lead outside the repository (the Git MCP records above). In the tools’ descriptions, look for the signs OWASP MCP03 lists: imperative sentences aimed at the model, sensitive file paths such as ~/.ssh or .env, sentences that say “send” to an address, zero-width characters, and instructions hidden in HTML comments.
• CI. Does the workflow run the agent on the pull request’s branch with the project settings loaded? For Claude Code, check whether --setting-sources user or --strict-mcp-config is there; for Cursor CLI, whether the --approve-mcps flag is.

Writing these questions into a rules file is not enough on its own: a change is only read in review. The same review applies to the hooks in .claude/settings.json, which we looked at separately in the hooks post. As Claude Code’s security documentation points out, reading .mcp.json does not show every server a session can load: there are also servers that come from user settings and plugins.

A code review bot is not outside this problem either: it, too, is a model reading text written by the pull request’s author. In diffox, at the step that decides whether a finding is dropped on the grounds that “the author did this on purpose”, the pull request description is placed between tags, and the model is told that it is data, not an instruction; a tag written inside the description is neutralised as well. The Security Agent, which runs on every review, hunts injection, broken authentication and authorisation, secret leakage, SSRF and unsafe deserialisation or path handling (we described how diffox works in a separate post).

Frequently asked questions

What is MCP tool poisoning?

Tool poisoning is hiding instructions in an MCP tool’s description that the model reads and the user does not see. In Invariant Labs’ example, the description of a tool that adds two numbers asks the model to read the user’s SSH key, send it to the server in an argument and not tell the user. It is the third item (MCP03) in the OWASP MCP Top 10. You can spot it by reading the description: imperative sentences aimed at the model, sensitive file paths and invisible characters are the best-known signs.

What is the OWASP MCP Top 10, and what is its latest version?

It is OWASP’s list of 10 risks specific to MCP. As of 18 October 2026, the list on owasp.org is in beta and its items are numbered in the form “MCP01:2025”; it runs from Token Mismanagement & Secret Exposure to Context Injection & Over-Sharing. The project’s GitHub repository lists the next release as October 2026, and one item has a different name there than on the site. When you cite an item, give its date as well.

Should .mcp.json be committed to the repository?

Claude Code’s documentation recommends it, so that everyone on the team uses the same tools. Once you commit it, the file is part of the code and should be reviewed like code: the command, the version, the environment variables and the approval settings. Personal approvals (such as enabledMcpjsonServers) belong in .claude/settings.local.json, which is where Claude Code itself writes them.

Does Claude Code run a repository’s MCP servers without asking?

Not in an interactive session: it asks for approval for each server in .mcp.json separately, and in an untrusted folder it ignores approval settings committed to the repository. In claude -p runs, Agent SDK sessions and cloud sessions, though, it cannot show the approval prompt, so it loads project servers without asking. To prevent this, you can use --setting-sources user, --bare, --strict-mcp-config or disabledMcpjsonServers.

How do you turn off a repository’s MCP servers when running a coding agent in CI?

In Claude Code, --setting-sources user reads neither the project settings nor .mcp.json; --strict-mcp-config uses only the servers you pass. On pull requests, claude-code-action restores .mcp.json from the base branch. The -p mode of Copilot CLI skips project servers in an untrusted folder. In Cursor CLI, --approve-mcps approves every server; don’t use this flag in a job that runs on the pull request’s branch. The documentation of Codex and Gemini CLI does not describe this case.

Does an AI code review tool catch an MCP change?

It depends on the tool. diffox reads the pull request’s diff, and the Security Agent runs on every review: it hunts injection, broken authentication and authorisation, secret leakage, SSRF and unsafe deserialisation or path handling. It has no separate rule specific to MCP; the questions in this post are asked by the person doing the review. When you choose a code review tool, also ask how it reads the pull request description: in diffox, the step that checks whether a finding was intended reads the description as data, not as an instruction.