Optional "Receipt Required" guard for destructive tools (delete_repo, permissions) #2761

Activity

1. github-actions

   added

   request ai review

   and removed

   request ai review

   on Jun 24, 2026
2. SamMorrowDrums

   added

   enhancementNew feature or requestNew feature or request

   on Jun 24, 2026
3. CAOShurong commented on Aug 23, 2026

   

   CAOShurong

   on Aug 23, 2026

   More actions

   Status update from the current main history: the basic repository-deletion confirmation boundary has already landed in merged PR #3076 (8ec6249, merged 2026-08-18).

   The current implementation now:

   • requires the client to elicit the exact owner/repo name before deletion (pkg/github/repositories.go:749-840);
   • binds the requested owner, repo, repository ID, and a 10-minute expiry into encrypted multi-round-trip request state (:742-747, :808-839);
   • rejects missing/invalid/expired state, target changes, recreated repositories, declined or mismatched confirmation (:843-884);
   • hides delete_repository from self-hosted HTTP inventory when GITHUB_MCP_SERVER_MRTR_STATE_KEY is absent, and refuses malformed keys at startup (pkg/http/server.go:281-291, documented in docs/streamable-http.md:35-51).

   That substantially addresses a “do not delete without an explicit exact-target confirmation” requirement, but it is not equivalent to the EMILIA receipt model described here: the current MCP elicitation does not authenticate a named human signer, verify a signature/trust root, or provide one-time receipt consumption/audit identity. Also, the current repository exposes no visibility/permission write tool corresponding to the other half of the issue title; collaborator listing is read-only.

   I suggest retargeting this issue rather than treating the two mechanisms as interchangeable:

   • close or split the already-addressed delete-repository part if exact interactive confirmation is sufficient; or
   • keep a narrower follow-up for an identity-bound, protocol-independent receipt rail, with explicit requirements for trust-root/key rotation, canonical action binding, replay storage and atomic consumption, transport/actor binding, error semantics, and direct-call bypass tests.

   In particular, an accepted ElicitResult alone should not be described as proof that a named human signed an authorization receipt.
4. FutureEnterprises commented on Aug 23, 2026

   

   FutureEnterprises

   on Aug 23, 2026 via email

   Author

   More actions

   Thank you, this is a very helpful correction. I checked merged PR #3076 at 8ec6249. I agree that the current delete flow now covers exact-target interactive confirmation, and I would not describe an accepted ElicitResult as a signed authorization from a named human. I also agree that the permission half of my original title is stale because this server exposes no permission write tool today. I would like to keep the issue open only if maintainers see value in the narrower gap: an opt-in, protocol-independent receipt rail that authenticates a named signer and consumes an exact-action receipt once, across direct and transport-mediated calls. I can retitle and rewrite the issue around the requirements you listed, then bring a concrete PR with atomic-consumption and direct-call bypass tests, without changing default behavior. Would that narrower contribution be useful here, or would you prefer that I close this and return only once the PR is ready? Thank you again, Iman