MCP approval scope: what changes when the command changes?

TL;DR: Claude Code records project MCP approval by server name, so a later .mcp.json change that keeps the same name but swaps the command can run silently at the next startup under the user’s privileges, according to Repello AI. That turns a trust click into a standing grant and makes reviewed definition, not just server label, the security boundary.

Editorial analysis by NHI Mgmt Group, based on content published by Repello AI: “A Trusted Name Is Not a Trusted Command: MCP Approvals in Claude Code”.

Key questions

Q: What breaks when an MCP approval is tied to server name instead of command definition?

A: The approval no longer guarantees that the reviewed code is the code that runs.

Q: Why do agentic developer tools make standing trust grants riskier than traditional approvals?

A: Because the tool can act at runtime without a new user decision, so a durable grant can authorize future behaviour the user never saw.

Q: How should security teams evaluate MCP trust in shared repositories?

A: They should treat the configuration file as an execution surface and assume any collaborator with commit access can alter what runs under an already approved name.

Practitioner guidance

• Prefer the narrow MCP grant Approve only the specific server in front of you instead of the standing project-wide option when the toolchain supports it.
• Inspect .mcp.json on every change Review the repository file on each pull, merge, or branch switch, because a server-name-preserving edit can still replace the command that will run at startup.
• Reset project approvals when trust changes Clear stored project choices before re-opening a repo you did not author, inherited, or have not reviewed in a while.

Bottom line: The central risk is not a hidden exploit but a trust model that authorizes future commands under an old approval.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →