Clarify guidance: form-mode elicitation should not be treated as authorization for destructive actions

[mirusser]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

The Idea

The current MCP draft already moves in the right direction by distinguishing form mode from URL mode, by stating that URL-mode interactions must not pass through the MCP client, and by making URL-mode accept mean only consent to the interaction rather than completion.

However, the spec does not yet clearly state that form-mode elicitation is not sufficient authorization for destructive or irreversible actions, nor does it provide a concrete server-side approval pattern for those cases. I’m proposing a docs/spec clarification that recommends URL mode plus server-side verification for high-risk actions, including same-user binding, single-use expiring challenges, transaction binding, CSRF protection for browser approvals, and audit recording.

The goal is not to add a new feature, but to make the security boundary and implementation pattern explicit for server authors building approval-gated mutations.

Scope selections:
- Protocol Specification
- Documentation
- Developer Experience

Suggested addition under Form Mode Security

Destructive Action Authorization

Servers MUST NOT treat a form-mode elicitation response as sufficient authorization for destructive, irreversible, or materially sensitive actions.

Form mode is appropriate for collecting non-sensitive user input. When a server must verify that a user completed an approval flow outside the MCP client’s control — for example, confirming deletion, mutation of production infrastructure, financial actions, or other high-impact operations — the server SHOULD use URL mode and MUST verify the result server-side.

Suggested addition under URL Mode Security

URL Mode for High-Risk Actions

When URL mode is used to confirm a specific high-risk action, the client’s URL-mode response with action: "accept" indicates only that the user consented to continue via the URL. It is not the authorization event for the underlying action.

The server MUST treat completion of the out-of-band flow as the authorization event.

For high-risk approvals, the server SHOULD bind the out-of-band approval to:

• the authenticated user identity that initiated the MCP
• the specific action or transaction being approved,
• a single-use identifier,
• and an expiration time.

If browser cookies or cookie-backed sessions are used, the server MUST protect approval submissions against CSRF.

The server SHOULD record audit events for approval, denial, expiration, and replay attempts.

Suggested non-normative example section

Example: Approval of a Destructive Action

A server stages a pending infrastructure change and computes an operation digest over the staged action. The server returns a URL-mode elicitation requiring browser approval. The browser flow authenticates the same user, renders the staged change from server-side state, and records a single-use, expiring approval bound to the user identity and operation digest. A later retry of the original MCP request succeeds only if the stored approval still matches the same user and the same operation digest.

Suggested example JSON using the current protocol shape

{
  "jsonrpc": "2.0",
  "id": 42,
  "error": {
    "code": -32042,
    "message": "Human approval required before this change can be applied.",
    "data": {
      "elicitations": [
        {
          "mode": "url",
          "elicitationId": "approval-550e8400-e29b-41d4-a716-446655440000",
          "url": "https://gateway.example.com/approvals/approval-550e8400-e29b-41d4-a716-446655440000",
          "message": "Review and approve the pending Kubernetes plan in your browser. Approval is bound to your identity and expires shortly."
        }
      ]
    }
  }
}

Server-side, the record behind approval-... should include at least:

- requester identity,
- transaction / operation digest,
- created time,
- expiry time,
- single-use status,
- completion status,
- and audit metadata.

That keeps the protocol surface small while making the authorization semantics unambiguous.

---

Checklist answers

• I have verified this would not be more appropriate as a feature request in a specific repository: Yes. The issue is cross-cutting: it spans the protocol specification, security guidance, and developer documentation rather than a single SDK implementation. The closest official materials are SEP-1036, SEP-1299, and repository discussions, but none of them already provide the exact “destructive action approval” clarification.
• I have searched existing discussions to avoid duplicates: Yes. The closest adjacent items are Discussion #219 on human-in-the-loop approval, SEP-1036 on URL mode, Security IG notes #1750, Discussion #2578 on session binding, and Discussion #2493 on authorization-context and approval references. They are adjacent, but not duplicates of my proposed clarification.

---

I've encountered these problems while designing my own implementation of 'safe' approval of destructive actions
gist: https://gist.github.com/mirusser/1d86ca8a038a321020fd96842520d893
repo: https://github.com/mirusser/Kubernetes-MCP-Guard

---

I tried my best to find similar discussions, if this is somehow redundant I sincerely apologize

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[mirusser]

Just to clarify: I ran into the practical version of a problem MCP now addresses with URL-mode elicitation: in-band approval is the wrong trust boundary for destructive actions.

URL-mode elicitation solves the channel problem. What I think is still worth documenting is the destructive-action authorization pattern: same-user binding plus transaction/plan-hash binding, single-use challenge, TTL, CSRF protection, drift check, and audit record.