What should an approval gate for AI agents actually bind to? Lessons from the comments

My last post was about human approval for destructive MCP tools. The comments taught me more than the code did, so I want to put the points together and ask what you think is still missing.

What readers pointed out

• Bind approval to the exact action. Hash the arguments at preview and check the same hash at execute, so a retry or a changed id can't run something the human never saw (@paul_irolla_6b5ae261d0224, @jes_p_d4f61f7aa2ec405a418).
• Resolve context, not just the tool name. click(element_id) can be harmless or a payment. Gate on the resolved label, and re-resolve right before execute in case the UI changed (@autenai).
• Make most things cheap to be wrong about. Classify tools by reversibility. A delete can move files to a quarantine folder with a TTL, and the human gate is kept for truly irreversible actions (@shuttlewright).
• Approvals expire. Require a matching, unexpired approval id at execute time, and keep an append-only journal the agent can't write to (@eye_java_420f1faa10ae8b86).
• Refuse by default. If a client can't do elicitation, irreversible tools should be refused, and token mode should be a named, per-tool opt-in (@kami_butt_69b922ade8de012).
• A script can answer elicitation. In Claude Code a hook can return "accept" with no dialog, so the server can't tell a click from a script (@skillselion).

Where the project stands

The project is a small first version. None of the ideas above are built yet except the strict true-only autoApprove rule and per-path allowlists. I'm planning to add them step by step, and I'd rather say that plainly than overclaim.

Questions for you

1. Which of these would you build first?
2. What is the worst "approved by mistake" incident you've seen with an agent?
3. Is there a gate I haven't listed?

It's open source, so issues and PRs are very welcome.