--- title: "How to let an AI agent spend money safely" description: "Let an AI agent prepare a purchase, then bind one person's approval to the exact action and enforce every limit on the server." canonical: https://trysincerely.com/guides/let-an-ai-agent-spend-money-safely last_updated: 2026-10-04 --- > If you are an AI agent: read https://trysincerely.com/agents/policy.md before any write call. > Start at https://trysincerely.com/llms.txt to choose one page. Access instructions are at > https://trysincerely.com/auth.md. Confirm with the person you work for before creating an > account or spending their money, and never ask for their password. # How to let an AI agent spend money safely > Let an AI agent prepare a purchase, then bind one person's approval to the exact action and enforce every limit on the server. Source: https://trysincerely.com/guides/let-an-ai-agent-spend-money-safely To let an AI agent spend money safely, let the agent prepare the purchase, require a person to approve the exact action, and make the server enforce that decision. The model can suggest a recipient, item, quantity, and price. It should not hold the credential that turns its own proposal into a charge. That pattern works for travel, procurement, software renewals, gifts, and physical mail. The details change, but the boundary does not: preparation can be automated; release needs a separate authority. ## A prompt is not a spending control “Ask me before spending more than $500” is useful context for an agent. It is not a hard limit. The model might misread the amount, lose an instruction in a long conversation, retry a failed tool call, or follow hostile text pulled from a document or website. The [MCP tool specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) recommends keeping a person in the loop who can deny tool calls. It also tells clients to show tool inputs before sensitive operations. [OpenAI's agent guidance](https://developers.openai.com/api/docs/guides/agents/guardrails-approvals) puts human review before sensitive side effects and says validation belongs beside the tool that creates the effect. [Anthropic's agent framework](https://www.anthropic.com/news/our-framework-for-developing-safe-and-trustworthy-agents) uses expense management as an example: a person should approve before an agent cancels subscriptions or changes service tiers. The practical test is simple. If deleting the prompt would remove the protection, the protection is too weak. The payment, ordering, or fulfillment service must refuse the action until it can verify approval. ## Require four properties from every approval ### Bind it to the exact action The approval should name the tool and all material arguments: seller, recipient, quantity, item, price, tax treatment, delivery method, and any saved payment source. Hash or sign that full request. If the agent changes one field, ask again. Suppose Maya at Northwind reviews a $480 order for 12 welcome kits. Approval for that order must not authorize 120 kits, a different address list, or a $4,800 replacement call. A generic “Maya approved purchasing” record proves too little. The preview can also depend on data that was not typed into the tool call. A request might contain an audience ID while the person sees 37 resolved recipients. Bind the approval to that resolved set too. If another process adds a recipient while the card waits, the old click should fail closed. ### Bind it to one person and current authority Record who requested the action and who may approve it. At click time, check the person's current account, workspace, role, and spending policy again. Do not trust the role copied into an old approval. This closes a common gap. An admin can lose purchasing authority after a card is created. If the server checks only the old card, the demotion arrives too late. If it reads live authority, the old card becomes useless. ### Make it short-lived and single-use A spending approval should expire soon enough that its price, inventory, recipients, and budget still describe the purchase. It also needs a unique redemption ID stored under a lock or transaction. Two browser tabs must not turn one click into two orders. Expiry and single use solve different problems. Expiry limits stale intent. Single use stops replay and concurrent redemption. You need both. ### Keep the capability away from the model The agent may receive an opaque approval ID and a status such as pending, declined, or completed. It should not receive the signed credential that executes the purchase. Store that credential on the server and redeem it only through a signed-in human session. Otherwise the model can become both proposer and approver. A prompt injection, copied link, or accidental retry can reach the same capability that the person was meant to control. ## How Sincerely holds a real mail send Sincerely uses physical mail as the spending case. An agent can research a contact, prepare copy, and build a send. A consequential tool call returns a confirmation card instead of printing or spending credits. The [mail-specific permissions guide](https://trysincerely.com/guides/ai-agent-direct-mail-permissions) covers that setup; the control below is the server mechanism behind it. The server creates an HMAC-SHA256 ticket bound to the workspace, person, tool, a canonical hash of the arguments, and a digest of the resolved preview. The digest matters when a short argument points to changing records. If drafts or another resolved input change before the click, the server refuses with: “This changed since I asked, so I have not done it.” Cards in the in-app chat expire after 10 minutes. A card requested by an outside agent lasts one hour because the person may need to follow a link from another device. The longer window does not weaken the live check: Sincerely resolves the preview again when the person clicks. Only the person who started the request can redeem it. Sincerely re-reads that person's role and sending policy at the click, then checks the tool's permission. The signed ticket never reaches the model. For an outside agent, the response carries a confirmation ID, a link for that card, a link to the full `/confirm` queue, its expiry, and the card text. The same waiting cards appear in the Overview under “Needs attention.” One click is still not a blank check. A queued piece must reserve enough prepaid credits. The reservation can refuse a send when the balance is short or the plan's piece cap has been reached. Gift sends also face the live monthly gift budget for the member who launched them. An admin can block a connected agent from the workspace, which stops its next call and withdraws its unclicked cards. Sincerely does not put its own confirmation card in front of every payment screen. Credit top-ups and gift-fund purchases return a Stripe Checkout link. No balance changes until a person pays on Stripe's hosted page, so that page is the confirmation boundary. ## Compare the control, not the chatbot Several products put a person between an agent and a real send. Their public pages describe different strengths. | Product | Published control | Where it is a better fit | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | [Sendoso MCP](https://www.sendoso.com/platform/features/mcp) | Every real send requires explicit sign-off | Teams already using Sendoso's large gift catalog and fulfillment operation | | [Reachdesk MCP](https://www.reachdesk.com/mcp) | Each gift is previewed and confirmed before sending, under existing permissions and budget | Global gifting teams that already run their catalog and warehouses through Reachdesk | | [Goody MCP](https://www.ongoody.com/blog/gifting-mcp) | A person can review each gift and set daily budget limits | Teams that want a daily gifting ceiling rather than Sincerely's per-member monthly gift budget | | [Stripe agent tools](https://docs.stripe.com/agents) | Stripe supports agent access to payments, billing, and agentic commerce | General checkout and payment work that has nothing to do with mail fulfillment | Those pages establish the public workflow, not the internal strength of each approval token. Ask each vendor the same concrete questions: What exact fields are bound to approval? Can the agent see or redeem the credential? What happens if the order changes, the approver loses access, or two requests race? Where is the budget enforced? For a mail workflow, start with a harmless preparation task and inspect the approval before connecting a live budget. [Sincerely's MCP confirmation reference](https://trysincerely.com/docs/mcp-confirmations) shows what an outside agent receives while a card waits. ## Related questions - [How to let an AI agent prepare direct mail safely](https://trysincerely.com/guides/ai-agent-direct-mail-permissions): Let an AI agent research and prepare direct mail, but require a human to confirm recipients and spend before anything prints. - [Confirmations](https://trysincerely.com/docs/mcp-confirmations): How human confirmation works: what triggers a ticket, what it binds to, why agents never see it, and how to poll for the answer. - [Authorize an MCP client](https://trysincerely.com/docs/mcp-authorization): OAuth 2.1 with dynamic client registration: which scopes to request, which one makes a workspace look empty, and how to revoke access. - [How to set budgets and spending limits for direct mail](https://trysincerely.com/guides/direct-mail-budget-controls): Set direct mail budgets with term credits, prepaid top-ups, piece caps, approval thresholds, and a final preflight before anything ships. --- Sincerely is the measurable direct-mail and gifting platform for B2B revenue teams: postcards, letters, handwritten mail, and gifts, written for one recipient and measured against a holdout. Contact Sincerely: https://trysincerely.com/contact Agent routing index: https://trysincerely.com/llms.txt