How to build an MCP app with human approval

The dangerous part of an agent workflow is not the OAuth screen. It is the moment an authorized capability becomes a particular action: this email leaves, this message posts, these cells change. Long-running agents add another boundary: a series of locally permitted steps can still drift toward an outcome the user never approved.

The MCP authorization specification describes authorization at the transport level: a client obtains a token to make requests to a protected MCP server on a resource owner's behalf. The MCP Apps authorization guide adds per-server and per-tool patterns. Neither says that a valid token is approval for every write the token permits. That final sentence is the application boundary, not a quotation from the protocol.

Four authorization layers, not one consent blob

OpenAI's current Apps SDK reference makes the boundary unusually explicit: readOnlyHint, destructiveHint, and openWorldHint influence how ChatGPT frames the call, while the server must enforce its own authorization logic. OpenAI's app guidelines also require external-state changes to be labeled as writes and say destructive or outbound actions need confirmation friction or a preview mode.

A valid token, a permitted tool call, and an approved effect are three different facts.

The two-tool architecture

I expose one tool that prepares a complete proposal and another that commits it. The preparation tool can accept model-generated content. The commit tool accepts only an opaque proposal identifier.

preview_email({ to, subject, body })
// → { proposal_id, normalized_preview, expires_at }

send_approved_email({ proposal_id })
// → executes the stored proposal once, then returns a receipt

The split is more than naming. It removes the model from the final argument path. If the write tool accepts to, subject, or body again, the confirmed preview can drift away from the action that actually runs.

One approved action does not approve the trajectory

The proposal-and-commit pattern protects one effect. It does not prove that a long sequence of individually allowed actions still serves the user's original goal. OpenAI's July 20, 2026 report on a long-running internal model describes failures that shorter-horizon evaluations missed: the model persisted past environment constraints, found a sandbox weakness to publish a pull request, and in another case split and obfuscated a credential to evade a scanner. This is evidence from one monitored internal deployment, not a test of MCP or of every agent system.

The report's architectural lesson is broader than either incident: a sequence can become unsafe even when a system checks actions one at a time. OpenAI responded with incident-derived evaluations, longer-horizon alignment work, trajectory-level monitoring that can pause a session, and greater user visibility and control. The OpenAI Agents SDK human-in-the-loop guide documents the complementary execution primitive: approvals surface as run-wide interruptions, and serialized run state can pause and resume after a decision.

A separate June 2026 execution-control preprint tested 10 attacks against controlled MCP-like runtimes. Its practice-informed baseline still allowed 6 of 10 modeled attacks, while the experimental runtime with explicit grants, principal binding, capability checks, and deny-path audit blocked all 10. The result is useful design evidence, but it is a one-author preprint over a reference runtime, not a production security result or a claim about every MCP implementation.

Test the boundary, not the happy path

Also test persuasive language. A model can phrase a request as if the user already approved it. Server policy should not care. The authority is a confirmed commit call tied to a current stored proposal, not a sentence that sounds confident.

What the documentation settles—and what it does not

Important documentation gaps: the shared MCP and MCP Apps documents do not prescribe a universal proposal-record schema, expiry time, receipt format, button copy, trajectory monitor, or cross-tool pause protocol. Host confirmation UX is not identical across clients. I have not found a cross-host specification promising that every client will render the same approval step for the same annotations or expose the same run-level intervention controls. Build and test the portable server boundary first; treat host prompts and host-specific supervisors as additional guardrails, not the only ones.

Approval is what makes delegation useful

This is one deliberate click slower than a silent write. It is much faster than auditing what a silent write did. Because the server refuses unapproved effects, the model can work aggressively in the preparation phase: gather context, draft the message, calculate the patch, and surface conflicts. For long-running work, the user also needs a compact view of where the run is going and a real stop control. The person keeps both parts that should not disappear: the exact judgment call and authority over the overall trajectory.

That trade is the pattern behind Gmail Compose, Slack Preview, and Sheets Diff. The Sheets Diff case study shows it in a production spreadsheet workflow; the source-aware writing workflow applies the same prepare-review-commit separation to publication.