MCP servers run before any Guardian decision: no vetting gate like steps/skillRegister

[paolocostanzo]

The gap

Skills have a static vetting gate. steps/skillRegister fires before any of the skill's actions execute, and steps/skillLoad binds activation to the approved digest. MCP servers have no equivalent.

A server first reaches the Guardian in agbom/snapshot (once per session, after sessionStart) or in agbom/changed, and the mcp_server component already lists tools[]. For a stdio server the host has to start the process to learn those tools, so by the time the Guardian can return deny, the server's code has already run. The component also records an endpoint URI but not the file that declared the server or the arguments it was started with, so a Guardian cannot see what was launched or on whose say-so.

Why it matters for coding agents

Project-level files such as .mcp.json, .vscode/mcp.json or .cursor/mcp.json let a repository declare servers. Between late September and 9 October 2026 I measured eight AI coding clients against a repository that declared one harmless canary server, each run from a clean VM snapshot:

• No client started the canary before the user answered its trust question.
• In three clients, accepting the folder-trust prompt started it at once, with no separate question. In a fourth, it started without a question as soon as the chat asked for a tool.
• One client asked per server and showed the full command, one kept project servers disabled until switched on, and one does not read servers from the repository.
• One client's non-interactive mode started it with no trust prompt at all.

So in most hosts "trust this folder" also means "run these programs", and a Guardian attached to that host first hears about them after they have run.

Possible direction

1. A pre-launch hook for MCP servers, by analogy with steps/skillRegister: it fires when a server enters the available set and before the host starts it, and carries the declaration source (user, project, managed), the transport, and for stdio the command and arguments. A Guardian MAY deny; a denied server MUST NOT be started.
2. Bind that declaration by digest, so a changed project-declared server (new command, new arguments) counts as a new registration instead of reusing an earlier approval. This would sit next to declaration_digest for tools in [Bug] Tool declarations have no integrity binding, so a same-version redefinition is invisible to Inspect-Dynamic #38.
3. Record the declaration source on the mcp_server component, so a policy can treat repository-declared servers differently from user-configured ones. Related to the integration path in Tool integration path is not on the wire, so a policy cannot distinguish a built-in from a third-party MCP server #151 / [Proposal] tool_kind: carry the integration path so a policy can tell a built-in from a third-party MCP server #153.

On principle 3: the command line and the declaration source are lost once the process is running, and starting it is a trust-boundary crossing.

Against the Current Priority Scope this is deferred work; I am raising it here first, as CONTRIBUTING asks for specification changes, and can turn it into a proposal issue if it is worth tracking.

Limits of the measurement: one OS in a VM, client versions current in late September and re-checked on 9 October, one server per configuration file; repeated runs show stability, not how often this happens in the wild.

Write-up: https://paolocostanzo.github.io/trusting-a-repo-means-trusting-its-mcp-servers/
Lab: https://doi.org/10.5281/zenodo.23300292