Knowledge · MCP

    Confirmation tokens and two-step agent execution

    How a preview-then-confirm pattern stops an AI agent from performing destructive, financial or outbound actions on a single ambiguous instruction.

    How do you stop an AI agent from acting on a misunderstanding?

    Make consequential actions two calls instead of one. The first call returns a preview of exactly what would change plus a signed confirmation token. The second call executes only when that token is presented. A misunderstanding then produces a preview a human rejects, not a sent message or a deleted record.

    Key takeaways

    • Preview first, execute second, for anything destructive, financial or outbound.
    • The token must be signed and issued by the server, not composed by the agent.
    • A preview should state the records and values that will change.
    • Confirmation is not a dialog box; it is a server-enforced protocol step.
    • Read-only calls should stay one step so the pattern is not diluted.

    Which actions deserve two steps

    • Destructive: deletions, voids, cancellations, status reversals.
    • Financial: invoices, payments, credits, refunds, price overrides.
    • External sends: anything that reaches a customer by message or email.
    • Bulk: operations touching many records at once.
    • Overrides: anything that bypasses a normal business rule.

    Why a signed token and not a flag

    A boolean 'confirmed: true' argument is something the model can set on its own. A signed token can only come from a preview the server produced, which means the confirmation refers to a specific, unmodified plan. Change the parameters and the token no longer matches.

    Keeping the pattern credible

    Confirmation loses its meaning when everything requires it. Reads should be immediate. Reserve the second step for the categories above, describe the consequence in plain language, and make refusal as easy as approval.

    Where URBLD fits

    URBLD's MCP dispatcher returns a preview and a signed confirmation token for every action classified as destructive, financial, override, bulk or external send, and executes only when that token is presented on a second call. Outbound customer messaging is always a separate, separately confirmed action rather than an implied side effect.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in MCP

    The protocol that lets AI do work instead of describing it.

    Browse MCP
    Share this page