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.
At a glance
What this is: Claude Code’s project MCP approvals are name-keyed, which lets a changed server command run later without a fresh prompt once a standing grant has been given.
Why it matters: IAM and security teams need to treat agentic developer-tool trust as an execution boundary, because a label-based approval can outlive the code it was meant to authorise.
Context
The core issue is trust scope, not a single product defect: a user may believe they are approving one reviewed command, while the system later treats a name as permission for future commands under that same label. In an agentic development workflow, that mismatch turns repository changes into execution events, which is why MCP security needs to account for definition drift as well as initial approval.
MCP server approval is only safe when the approval object and the execution object stay bound together. If a project can change the command behind a previously approved server name, then the approval becomes a durable trust token for whatever future code inherits that name.
That is a governance problem for non-human identity in the developer toolchain: the assistant is not merely reading configuration, it is executing code on behalf of the user with the user’s privileges. Once that boundary shifts, the review point must shift with it.
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. A later change can keep the same server label, inherit the old grant, and execute a different command at the next startup without a fresh decision from the user. That is a definition drift problem, not a prompt problem.
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. Once the assistant can execute code on launch, approval is no longer just permission to access a project, it is permission for that project to trigger actions later.
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. That means review, sandboxing, and tighter approval scope matter more than a one-time click on first open.
Q: What is the difference between approving a project and approving a specific MCP server?
A: Approving a specific server should bind trust to the reviewed command, while approving a project can become a broader standing grant for future servers or future command changes. The first is narrower and easier to reason about; the second is more convenient but creates far more room for silent definition drift.
Technical breakdown
Why name-keyed approval creates a definition gap
Claude Code’s approval model stores the allowed server as a string name rather than as the full server definition. That means the grant can survive a change to the underlying command, arguments, or entrypoint as long as the label stays the same. In practice, the approved identity is the project label, not the executable definition. For agentic tools, that is a material difference because execution happens at startup and the user may never re-open the approval dialog. Practical implication: treat any name-keyed trust model as a standing execution grant unless it is bound to the reviewed definition.
Practical implication: Review whether approvals bind to a fingerprinted definition, not just a server label.
How MCP projects turn repository edits into runtime execution
An MCP server defined in a project file can be changed by anyone who can commit to the repository, so the configuration file itself becomes part of the runtime trust chain. If the assistant starts those servers automatically on launch, a later commit is no longer just a code change, it is a launch-time behaviour change. This is the same structural issue that appears when supply-chain updates alter what a trusted package does after it has already been approved. Practical implication: model project configuration files as command surfaces, not passive metadata.
Practical implication: Treat .mcp.json changes as runtime-relevant and inspect them on every pull or branch switch.
Why agentic assistants make old trust prompts unsafe by default
Traditional trust prompts assumed software would only run when the user actively invoked it. Agentic assistants break that assumption because they can execute code on the user’s behalf, at startup, without a fresh decision about the changed command. Once an approval is durable and project-scoped, the trust prompt is no longer guarding a single action, it is underwriting future execution. Practical implication: if the tool can act autonomously at runtime, the approval model must be anchored to what it will actually execute, not what it once looked like.
Practical implication: Re-evaluate every trust prompt that predates agentic execution and ask what it really authorises.
Threat narrative
Attacker objective: Persisted code execution through a trusted project configuration so that later repository changes can run silently under the user’s authority.
- Entry occurs when a user grants a project-scoped MCP approval in Claude Code, including the option that covers current and future servers in that project.
- Credential or command access is then inherited by a later repository change that keeps the same server name but replaces the underlying command in .mcp.json.
- Impact follows at the next startup, when the new command runs as the user with no additional prompt and can read any local data the user can access.
Breaches seen in the wild
- Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
- Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Definition-bound trust, not name-bound trust, is the minimum viable control for agentic developer tools. The article shows that a project-wide MCP grant can persist even when the command behind the server name changes. That means the trust decision is attached to a label, not to the actual executable definition. For identity governance, that is a structural mismatch between approval and execution. The practitioner conclusion is simple: if the grant does not bind to the reviewed definition, it is not a safe authorization boundary.
The assumption that a trusted project changes less than a trusted identity is now broken. This was designed for a world where code was inert until invoked, and where approving a project meant approving a known thing in front of you. That assumption fails when the actor is an assistant that starts code on launch and follows repository changes automatically. The implication is that review cadences built for static code no longer cover agentic execution paths.
AI coding agents turn ordinary repository maintenance into privilege-bearing execution. A routine pull, merge, or branch sync can become a runtime event if a previously approved MCP server changes underneath the same name. That collapses the distance between development workflow and machine identity risk. The practitioner conclusion is to govern the configuration file as an execution surface, not as a convenience setting.
Prompt scope becomes a governance object the moment an assistant can act on it. The button text may feel like a user experience choice, but in operational terms it defines how much future authority a project receives. That changes the meaning of consent, because the user may think they approved a visible server while the system recorded a broader standing grant. The practitioner conclusion is to align trust language with actual enforcement semantics, or the UI will keep overpromising the control.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Definition drift is the real trust-boundary failure here: a label can remain stable while the executable beneath it changes. In agentic developer tools, that means the review point must move from the project name to the exact server definition, or the control will keep certifying the wrong thing.
Security teams should expect more workflows where approval UX and execution semantics diverge. The practical response is to govern any config file that can launch code as part of the identity surface, especially when an assistant can re-run that code on every startup.
The article signals a broader shift in non-human identity governance: trust decisions that once applied to static tools now govern runtime actors that can inherit, repeat, and amplify privileges across sessions. That makes AI coding agents a governance problem, not just a developer convenience problem.
For practitioners
- 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.
- Treat repo trust as command execution Open shared, forked, or third-party projects in a sandbox or disposable environment when their MCP configuration can be edited by someone else.
Key takeaways
- The central risk is not a hidden exploit but a trust model that authorizes future commands under an old approval.
- The evidence points to a name-keyed grant that can survive repository changes and re-run code at later launches.
- Practitioners should govern approval scope, inspect configuration diffs, and treat agent startup paths as execution surfaces.
Related NHI Mgmt Group resources: AI Coding Agents Security Guide · OWASP Agentic Applications Top 10 · MCP Security Guide · NHI Authentication Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article shows a trust grant that authenticates by label rather than by reviewed command definition. |
| NHI-09 — NHI Reuse | A prior project grant is reused for a later command under the same name. | |
| Recommendation — Bind approvals to the executed definition and revalidate any command change before runtime execution. Prevent reusing an approval across changed definitions unless the new command is explicitly re-authorised. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The assistant can inherit authority and act under a stale trust decision. |
| Recommendation — Limit agent privileges to the exact runtime scope of the reviewed action and re-authorize definition changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is an authorization boundary that persists beyond the reviewed object. |
| Recommendation — Review entitlements so approval follows the actual executable object, not just the project label. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The reproduced command can access local credentials and other user-readable data, enabling follow-on movement. |
| Recommendation — Map startup-executed agent code to credential access and harden paths that can reach local secrets. | ||
Key terms
- Standing Grant: A standing grant is access that remains active after the moment it was approved. In SaaS and identity environments, it often comes from OAuth consent, delegated permissions, or service accounts that persist long after the original business need has faded. Standing grants increase blast radius and complicate revocation.
- Definition Drift: Definition drift occurs when the thing that was approved no longer matches the thing that executes. For agentic developer tools, it is the gap between a trusted label and the command or behaviour that later inherits that trust.
- Project-scoped Approval: Project-scoped approval is permission recorded at the repository or workspace level rather than for one exact action. It simplifies user experience, but it also widens the blast radius if future commits can alter what the approved project launches.
- Execution surface: An execution surface is any system or environment where an identity can actually do work, such as an application, trigger, endpoint, or API. For AI agents, execution surfaces matter because risk appears where action is taken, not only where authentication occurs.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org