AI agents are increasingly able to deploy code, modify infrastructure, query sensitive systems, and initiate financial operations. A conversational “Are you sure?” prompt is useful, but it is not independent authorization. The same agent that proposed the action may also control the confirmation flow.
I wanted an approval mechanism with four properties:
The resulting design is GoodRoom.verify, an MCP sidecar that s a configured high-risk action while an operator verifies with a passkey.
The agent calls an MCP tool with a human-readable summary, a SHA-256 hash of the canonical action, a risk level, and an audience identifying the protected tool.
{
"action_summary": "Deploy migration to production",
"action_hash": "sha256:...",
"risk_level": "CRITICAL",
"audience": "tool:db_migrate"
}
The gateway sends those fields to the approval API and receives separate approval and polling capabilities. The approval page displays the summary and requests WebAuthn user verification.
After successful verification, the API atomically consumes the challenge and issues a short-lived Ed25519 proof. The MCP gateway downloads the public JWKS and verifies the signature, issuer, audience, action hash, key ID, and expiry locally.
The protected operation should independently require that proof. Without that enforcement point, an approval UI is only advisory.
WebAuthn provides phishing-resistant user verification tied to the relying party. The private credential remains in the platform authenticator or hardware key. It also makes physical operator presence a clearer security boundary than another button controlled by the agent runtime.
The approval service does not need the prompt, conversation, source code, or raw tool arguments. GoodRoom.verify receives a bounded display summary and an action hash.
Persistent audit records can retain the hash, result, proof identifier, and timestamps without retaining the summary.
A useful execution proof needs more than an “approved” boolean. The GoodRoom.verify design binds it to:
The protected tool must reject a mismatched audience or action hash, an expired signature, an unknown signing key, and a reused proof identifier.
This design does not determine whether an action is safe, sandbox the tool, or prevent a runtime from bypassing the approval tool. The agent runtime or tool wrapper must enforce proof verification, and it must hash the same canonical action that will execute.
That last point matters: if the reviewed payload and executed payload can differ, the approval is meaningless.
There are three plausible places:
My current preference is defense in depth: runtime or MCP policy for usability, with final verification at the sensitive tool boundary whenever possible.
GoodRoom.verify is currently a private-beta MVP, not a finished security product. I am looking for feedback from developers building agents with sensitive tools, particularly on proof enforcement and action canonicalization.
See the architecture and request beta access.
What is the riskiest tool your agent can call today, and where do you enforce human approval?