Instrument · Agents
Who approved the delete?
A destructive MCP tool behind two replicas, confirmed four ways. Replays the audit of servers generated before the 2026-07-28 spec: self-approval, stuck confirmations, and replayed state.
Sources: Stateless MCP audit
Audit replay / MCP 2026-07-28
Who actually approved the delete?
A destructive tool behind two replicas, confirmed four different ways. Pick a gate design and how the load balancer routes, then run a scenario. The first three designs replay what I ran against real servers. The fourth is the fix I am proposing, and it is modelled, not measured.
| # | Replica | Request | Response |
|---|
Deletes executed
—
A person was asked
—
Verdict
—
What each design does
- Call twice. The first call returns
confirmation_requiredand remembers a digest of the arguments in that process. An identical call to the same process inside 300 seconds runs the delete. Nobody else is involved. - MRTR, default key. The first call returns
input_requiredwith an elicitation for a person and a sealedrequestState. The SDK seals with a random per-process key unless you configure one, so only the replica that minted the state can open it. - MRTR, shared key. Every replica holds the same key, so the retry can land anywhere. The state is bound to the arguments and expires, but it is not single use.
- Shared key + single-use record. Adds a shared record of spent confirmations, which the spec requires when a request must run at most once. Proposed; I have not run this one.
MCP 2026-07-28, python SDK 1.30 for the first design and 2.2 for the others. Details in the audit post.