Human-approval controls for MCP media generation

Put approval between a proposal and every consequential action

A useful MCP approval is a transaction boundary, not a generic “continue” button. Let the model propose a media operation, then have trusted client or policy code classify it before execution. The current MCP tools specification describes tools as model-controlled but says a person should be able to deny invocations; it also recommends showing inputs before a call and confirming sensitive operations. For media generation, the preview should name the exact tool, model or provider route, prompt and source assets, output count, dimensions or duration, destination, and the maximum authorized spend.

Split one creative request into separately reviewable effects. Previewing a prompt is not approval to charge an account, publish a file, replace an existing asset, disclose a source image, or change a credential. OWASP's current agent guidance treats financial and externally visible actions as high impact and recommends separating an agent's proposal from independently validated execution. A safe sequence is therefore propose, normalize arguments, display consequences, approve the exact action, execute once, and record the result. If arguments change after approval, stop and ask again.

Proposal

No side effectThe model can assemble prompts and settings, but the execution layer has not yet spent, uploaded, published, or changed access.

Approval

Bound to normalized argumentsShow the exact tool, source assets, destination, cost ceiling, and expiry rather than an agent-written summary alone.

Execution

One authorized attemptReject changed arguments, expired approval, replay, or a request outside the approver's scope.

Verify the gate in the client and execution layer

The protocol supplies security guidance but leaves implementations free to choose their interface pattern, so test the actual client, server, transport, and operating mode you deploy. Cursor currently documents asking for approval before MCP tool use by default and lets a user click the arrow beside a tool name to inspect its arguments. Those two documented behaviors are useful review surfaces, not proof that every downstream effect is constrained or that another client behaves the same way.

Keep the decisive check outside model-controlled text. The execution layer should compare the approved canonical payload with the payload it will send, verify actor and target, enforce a spend ceiling, and fail closed when approval state or audit storage is unavailable. OWASP's MCP guidance recommends explicit confirmation for destructive, financial, or data-sharing operations and displaying full parameters rather than only a summary. Test denial, timeout, duplicate delivery, changed arguments, unavailable pricing, and a tool retry after partial failure. A polished dialog that is not bound to execution is only ceremony.

Verified surface

MCP 2026-07-28 specification and current client documentationThis research validates documented control surfaces, not every client version, extension, or automation mode.

Negative tests

Deny, expire, mutate, retry, and replayEach case should stop before a charge, upload, publication, or credential change.

Known gap

No end-to-end client or provider test in this passTreat the design as a review checklist until your deployed stack passes those cases.

Use four distinct gates for source, spend, publication, and credentials

Source approval should identify every uploaded or referenced asset, who supplied it, the asserted license or permission, intended use, and any territorial or channel limit. Provenance can help reviewers understand history, but it does not replace a rights decision. C2PA says Content Credentials preserve tamper-evident provenance and are not digital-rights management; its core specification also does not attribute content to a person or organization. Record the evidence reviewed and the approver's assertion without presenting either as a legal determination.

Spend approval should show the price basis available at decision time, quantity, currency, taxes or fees if known, and a hard maximum. If the final amount is unknown or exceeds that ceiling, return to the person rather than silently selecting a cheaper or more expensive route. Publication approval should be a later gate over the actual output, destination account, audience, caption, disclosure, and schedule. Approval to generate a draft is not approval to post it.

Credential creation, entry, scope expansion, rotation, and revocation are separate administrative actions. The current MCP elicitation specification prohibits collecting passwords, API keys, access tokens, or payment credentials through form mode and requires URL mode for those sensitive interactions. Clients must show the target URL, obtain explicit consent before opening it, and must not fetch it automatically. Keep secrets out of the prompt, approval record, media metadata, and ordinary tool logs.

Source gate

Asset identity and asserted permissionDo not infer usage rights from a filename, a public URL, or provenance metadata alone.

Spend gate

Quantity, basis, currency, and ceilingA changed or unavailable amount invalidates the decision instead of broadening it.

Publication gate

Final asset, destination, audience, and timingReview the rendered output rather than relying only on the prompt that produced it.

Credential gate

Out-of-band entry and least privilegeNever ask a model or in-band MCP form to collect a password, token, API key, or payment credential.

Retain an approval receipt without retaining the sensitive payload

An approval receipt should answer who approved what, for which account and destination, under which policy, and until when. Bind it to the tool name, normalized non-secret parameters or their digest, source-asset identifiers, spend ceiling, target resource, timestamp, expiry, and a one-time request identifier. OWASP's agent guidance recommends exact-action binding, short-lived authorization artifacts, replay protection, step-up authentication for critical actions, idempotency where possible, and failing closed when approval validation or audit logging fails.

Minimize what the receipt stores. Keep a reference or digest when raw prompts, source media, credentials, signed URLs, or payment details are not needed for the decision record. Log the approval outcome and execution result, but redact secrets and personal data. Retention duration is an operator policy decision: align it with dispute, security, contractual, and privacy needs rather than keeping every creative payload indefinitely. Expiry should govern authorization, while a separately protected audit record can show that an action was approved and executed.

Reapproval is required when any material field changes: a different source, provider route, output count, destination, audience, cost ceiling, credential scope, or execution after expiry. Do not treat a previous campaign approval as consent for a new campaign, and do not let a retry mutate the request. Where an operation cannot be made safely idempotent, show that duplicate risk explicitly and require a new decision.

Keep

Actor, action digest, target, policy, time, expiry, and outcomeThese fields support review without copying every sensitive input into the audit trail.

Exclude

Secrets, payment credentials, signed URLs, and unnecessary mediaRedaction is part of the logging design, not a cleanup step after collection.

Invalidate

Any material change or replayThe new action needs a new approval; the old receipt remains an audit fact, not reusable authority.

Review the adjacent security boundaries

Use the broader MCP security guide to verify authentication, scopes, server trust, uploads, output access, logs, and revocation. Then check resource indicators before accepting a remote token and provider-retention terms before sending a prompt or source image to a cloud generation service. Those are separate decisions from the human gate: a well-designed confirmation cannot repair an over-scoped token or an undisclosed retention boundary.

Evidence boundary and remaining gaps

This page defines a vendor-neutral approval pattern; it does not claim that OfflineCreator or any named MCP client implements every control. Stripe's current MCP documentation is included only as a concrete first-party example: Stripe recommends human confirmation for its tools, restricted API keys for agent access, and keeping keys out of code. It does not establish how a media-generation provider prices, refunds, retains, or licenses an output.

Recent community evidence was insufficient to support a page claim. The mandatory last30days pass completed with degraded coverage—Reddit returned a partial result after HTTP 429, X was not configured, and Polymarket had no source-status record—and no retrieved community item cleared the relevance bar for a retained claim. Failed or unconfigured lanes do not establish that those communities were quiet. No community anecdote is used. This research also did not run a generation, incur a charge, publish media, test a credential flow, obtain a legal rights opinion, or verify an approval UI end to end.