[C10.4] No requirement covers MCP servers declared in project configuration and started on folder trust #1202

Activity

1. jmanico commented on Oct 24, 2026

   

   jmanico

   on Oct 24, 2026

   Last edited by jmanico

   Member

   More actions

   Good catch. My preference is to broaden 10.4.7 before adding two new requirements. The current wording ties consent to installation:

   Verify that MCP clients present users with explicit consent dialogue and cancellation options upon installation of a local MCP server.

   A project can start a program that is already on your machine. No installation step, but we are still executing code! That deserves explicit approval specific to the server.

   The related controls help, but answer different questions: 10.1.2 covers which servers are allowed, and 10.1.3 limits what they can access through sandboxing. 10.4.7 is the right place to clarify consent.

   There is useful support for this in the docs. MCP security guidance already requires showing the complete command and allowing cancellation for one-click configuration. VS Code documents that workspace MCP servers inherit folder trust, including after configuration changes. So the distinction you are raising matters.

   I'd suggest this as a starting point for 10.4.7, still L2, in 1.02-dev:

   Verify that MCP clients require explicit approval before installing or launching each local MCP server, including servers declared in project or workspace configuration. Approval prompts display the complete command and arguments and allow cancellation. Workspace trust alone does not satisfy this requirement.

   For non-interactive automation, approval configured beforehand by an authorized user or administrator should work. We don't need a person clicking a dialog on every automated run. The repository must not be able to approve its own server by supplying an approval setting. User and managed approval settings already exist in clients, so there is a practical path here.

   One piece still needs an explicit decision: changes to the approved launch configuration. Swapping the command or arguments must not inherit approval just because the server name stayed the same. That is distinct from #1201, which concerns tool definitions returned by the server. I wouldn't claim the wording above fully resolves that part yet.

   Let's start by broadening 10.4.7 and work through that remaining change-approval question here. Thanks for bringing concrete evidence to this. 🙏
2. jmanico

   added

   1.02Active release: work targets 1.02-dev; proposals require review before inclusion.Active release: work targets 1.02-dev; proposals require review before inclusion.

   on Oct 24, 2026
3. ottosulin commented on Oct 24, 2026

   

   ottosulin

   on Oct 24, 2026

   Collaborator

   More actions

   Thanks @paolocostanzo for pointing this out, this is a real gap. Also agreed with Jim, let's try to rather work this into existing requirements.

   And yes exactly we should not always require approvals for automated runs when an agent is using MCPs unattended. Related to this exact concern you're asking about, I posted a suggested revised version in #1201 - please check that. TL;DR: we should watch for any changes that get fed to the context.
4. paolocostanzo commented on Oct 25, 2026

   

   paolocostanzo

   on Oct 25, 2026

   ContributorAuthor

   More actions

   Thanks @jmanico @ottosulin. Agreed on broadening 10.4.7, and Jim's text works for me. I'd add his point that the project can't approve its own server, plus one sentence for the open change-approval question:

   Verify that MCP clients require explicit approval before installing or launching each local MCP server, including servers declared in project or workspace configuration. Approval prompts display the complete command and arguments and allow cancellation. Workspace trust alone does not satisfy this requirement, nor does an approval setting supplied by files distributed with the project or workspace that declares the server. Approval is bound to the approved launch configuration (command, arguments, working directory, environment variables including any referenced environment file, and sandbox settings), and any change to it requires re-approval before the server is launched again.

   Otto, the revised 10.4.8 covers changes that reach the model context; the launch configuration never does, so I think it needs its own clause. Pre-approval by a user or administrator for unattended runs fits, as long as it is bound to the configuration and not only to the server name.

   Working directory and environment matter as much as the command: ./server resolves against the working directory, and NODE_OPTIONS or LD_PRELOAD change what runs without touching the command line. Comparing variables as declared, before interpolation, keeps secrets and host values out of the comparison. Changes to the code the command resolves to (an unpinned npx pkg@latest, or a repository script edited by a later commit) are a different problem, closer to 10.1.1 and 10.1.3, and I'd leave them out of scope. I haven't measured re-approval after configuration changes; the closest data point is the VS Code documentation Jim cited.

   If you'd rather keep 10.4.7 to the launch decision, the last sentence works as a separate 10.4.22 (L2), mirroring 10.4.10 for endpoints. Happy to open the PR once we agree, as with #1204.
5. ottosulin commented on Nov 4, 2026

   

   ottosulin

   on Nov 4, 2026

   Collaborator

   More actions

   @paolocostanzo in your revised version you have two requirements.

   Broken down, and pulling the definition to glossary entry it could look like this:

   10.4.7, L2: Verify that MCP clients require explicit approval before installing or launching each local MCP server, including servers declared in project or workspace configuration, and that approval prompts display the command and arguments and allow cancellation, and that neither workspace trust nor an approval setting supplied by the project or workspace satisfies this requirement.

   Although that 10.4.7 could be broken into sentences like Jim's suggestion, making it a bit more readable.

   The new part:

   10.4.22, L2: Verify that MCP clients bind the approval of a local MCP server to the launch configuration the client is about to use, and require re-approval before launching it where that configuration differs from the approved one.

   Appendix A, Launch Configuration: The declaration that determines what a local MCP server runs: the command, arguments, working directory, transport, and declared environment variables, compared as declared before interpolation. Changes to the code the command resolves to, to the contents of a referenced environment file, or to the client's sandbox policy are not launch configuration changes.

   Our 1.01 basis for MCP requirements were pretty spec MUSTs + few picks from SHOULDs (I'd remember). To that point, this new part is not part of MCP spec's requirements - there closest language quickly found being (not exactly about installation, but could be said to implicitly cover that also?):

   If an MCP client supports one-click local MCP server configuration, it MUST implement proper consent mechanisms prior to executing commands. [...] The MCP client MUST: show the exact command that will be executed, without truncation (include arguments and parameters); clearly identify it as a potentially dangerous operation that executes code on the user's system; require explicit user approval before proceeding; allow users to cancel the configuration.

   @jmanico / @RicoKomenda thoughts?

   🚀React with 🚀1Reacted by Paolo Costanzo