v1.0 governs tools only: sampling, elicitation, and roots are ungoverned

Summary

v1.0 is a strong, usable framework, but every governance artifact in it keys off tools. MCP servers also drive three other capabilities, and none of them appear anywhere in the document:

$ grep -ic "sampling\|elicit\|roots/list" mcp-governance-risk-framework-v1.0.md
0

Sampling, elicitation, and roots invert the direction of trust: the server initiates and the client or user responds. Because they are not tool calls, they pass through the tier decision tree, the eight risk factors, the hard gates, the SIEM field list, and the practitioner checklists without being scored, gated, or logged.

Chapter 2 sets this up: the architecture list at "How MCP works in security terms" enumerates host, client, server, transport, tools, resources, prompts, and notifications, and then "each MCP server exposes" lists only tools, resources, and prompts. Sampling and elicitation are missing from both, so the omission propagates to every downstream chapter.

Three concrete gaps

1. Sampling defeats the Action Capability factor and the tier tree

sampling/createMessage lets a server request generations from the client's model. In the 2025-11-25 revision the request can carry a tools array and toolChoice, and the server runs a multi-turn tool loop: it receives stopReason: "toolUse", executes the tools itself, and sends the results back for another generation.

Score that server with the v1.0 model. It exposes two read-only tools over internal wiki content, so:

• Tier decision tree: read-only, not sensitive, no write actions, so Tier 1
• Action Capability: "Read-only" = 1
• Blast Radius: "Single user" = 1

The server nevertheless controls systemPrompt and the full messages array, spends the organization's model budget, and drives an agentic loop inside the user's session. The spec's only protection is that there "SHOULD always be a human in the loop" and clients "SHOULD implement user approval controls" and "SHOULD implement rate limiting". All advisory, all client-side, and Chapter 3 Principle 4 currently sets HITL requirements by tier, so a Tier 1 server inherits the weakest ones.

None of the eight factors move for this server. It is a Tier 1 approval that can act like Tier 3.

2. URL mode elicitation is an unaddressed inbound phishing surface

Elicitation lets a server request input from the user mid-session. URL mode is new in 2025-11-25, the exact revision the Authorization Hard Gates section cites, and it exists specifically so servers can collect credentials, payment details, and third-party OAuth consent out of band: the server supplies a URL and a message, and a trusted client renders the prompt.

The Network Exposure Hard Gates cover SSRF and DNS rebinding, which are the outbound and inbound-to-a-listener cases. There is no gate for the third case: a server-supplied URL pushed into the user's browser through the client's trusted UI. The spec devotes a section to a concrete cross-user account-takeover via that URL, and pushes a long list of MUSTs onto clients (never pre-fetch, never open without consent, show the full URL, highlight the domain, warn on Punycode).

This also inverts Principle 4. "Human approval must be meaningful" assumes the organization writes the approval prompt. With elicitation, the server writes both the message and the schema, so the party being approved authors the approval dialog. Form mode is bounded by MUST NOT request secrets, but that is a constraint on a well-behaved server, not a control the organization holds.

Nothing in the intake, the hard gates, or the client and host governance table asks whether a server elicits, in which mode, or whether the host meets the client-side URL requirements.

3. Roots are the filesystem scope control, and they are advisory

The inventory's "Effective local access" field captures filesystem and credential reach for a locally launched process. For a server reached over HTTP, the only filesystem scope signal is roots, and the normative language is that servers SHOULD "respect root boundaries during operations". A root is advertised scope, not enforcement. Approving a server on the basis of declared roots records an intention.

Roots are also not in the inventory, so an approval never states which roots the host will expose, and a notifications/roots/list_changed that widens them is not a documented re-review trigger.

Related: capability drift after approval

Capabilities are negotiated per session at initialize. An approval record pins a tool list and a version, but nothing pins the negotiated capability set, so a server that requested no sampling at review time can request it in a later session with no configuration change and no new artifact. Chapter 5 Rule 2 ("Re-classify when tools change") is the right policy, but the appendix's declared-versus-observed drift detection only watches the tool manifest, and notifications/tools/list_changed is not named as a signal.

Proposed changes

Small and additive, no restructuring:

1. Chapter 2: add sampling, elicitation, and roots to the architecture and "each MCP server exposes" lists.
2. Chapter 4: one required inventory field, "Non-tool capabilities", recording sampling, elicitation and mode, roots exposed, and resource subscriptions.
3. Chapter 5: a classification rule that non-tool capabilities count toward tier, so a sampling-capable or elicitation-capable server cannot sit at Tier 0 or 1 on the strength of read-only tools.
4. Chapter 6: an "Undeclared capability" production hard gate (server negotiates a capability absent from the approval record), plus scoring notes so Action Capability and Blast Radius account for sampling, and Identity Scope accounts for elicitation.
5. Appendix: a short non-tool capability control set with test cases, plus mcp_method, capability, and elicitation_mode in the SIEM field list so these calls are attributable at all.

Happy to raise a PR against these five points if the direction looks right.

Start with mcp-governance-risk-framework-v1.0.md and run the issue's grep command to confirm the missing coverage. Read Chapters 2, 4, 5, 6, and the Appendix, then map sampling, elicitation, and roots to the five proposed changes. Done means the capabilities appear in the architecture, inventory, classification and gates, drift controls, test cases, and SIEM fields.