Optional "Receipt Required" guard for destructive SQL

[FutureEnterprises]

The SQL/migration tools can run irreversible statements (DROP, DELETE, TRUNCATE) against production when driven by an agent. I maintain EMILIA's open Receipt Required rail (Apache-2.0): a small, opt-in gate so a destructive-SQL call refuses to run unless a named human signed an authorization receipt for that exact action.

The four-step behavior (CI-verified):

• missing receipt → 428 Receipt Required
• valid, action-bound receipt → runs
• same receipt replayed → refused (one-time consumption)
• forged receipt → refused

Disabled by default, no lock-in — purely additive. There's a runnable supabase-admin example that gates run_destructive_sql end-to-end. Would a PR behind an opt-in flag be welcome? Happy to author it.

Spec + guide: https://github.com/emiliaprotocol/emilia-protocol/blob/main/docs/guides/RECEIPT-REQUIRED-MCP.md

[gregnr]

This is neat, thanks for sharing @FutureEnterprises. In general we'd like to see more adoption of this protocol before committing to it here, but happy to reconsider if/when that changes!

[FutureEnterprises]

Totally fair — adoption-first makes complete sense, and thanks for the thoughtful read.

The design is fully opt-in (off by default, zero behavior change unless a maintainer turns it on), so there's no cost to revisit whenever you're ready. I'll circle back as adoption of the receipt/EG-1 pattern grows across the MCP ecosystem. Appreciate the look, @gregnr.