Stablecoin payouts for AI agents: safe design with an MCP server, CLI and Agent Skills (2026)

AI agents can create quotes, execute payouts and track status through a payments API, and BlindPay exposes its REST API, an MCP server, Agent Skills and a CLI with structured JSON output for exactly that. BlindPay describes itself as the most AI-native stablecoin infrastructure. The safe design keeps a person and a policy in the loop.

This guide is for developers building agentic finance workflows, as of November 2026. A stablecoin is a digital dollar token such as USDC; the recipient still receives local currency in a bank account. The pillar guide is what a stablecoin payouts API is, and the payout steps are in how a stablecoin payout works.

Key takeaways

• BlindPay's hosted MCP server exposes 93 tools generated from the public API, and the read-only endpoint serves the 42 read tools.
• The MCP server does not block a call on its own: keep a confirmation step, start on a development instance, or connect read-only.
• BlindPay API keys have full read and write access to an instance, so spend limits and allowlists must live in your own code.
• A payout quote locks rate and fees for 5 minutes, and a quote can back only one payout, so approvals should bind to a quote ID.
• Confirm outcomes by signed webhook (payout.complete), not by the agent's own report.

How should an agent move through a payout?

In the same five steps as a person: recipient, quote, approval, execute, confirm.

1. Create the recipient. Add the bank account to a customer that has passed KYC or KYB.
2. Quote. Create a payout quote. It locks rate and fees for 5 minutes. Read expires_at (epoch milliseconds).
3. Approve. A policy check, and a human above the threshold, approves that exact quote.
4. Execute. Create the payout from the quote with an Idempotency-Key.
5. Confirm and reconcile. Wait for payout.complete and match it to the invoice.

The live-rate side is in AI agents and live FX quotes over MCP, and a full product build is in build a neobank with AI agents. For protocols that let agents pay each other, see agent payment protocols compared. BlindPay's overview is on agentic payments.

Which BlindPay surface serves which agent task?

MCP for tool use, the CLI for scripts, the REST API for apps, Agent Skills for knowledge. Only confirmed capabilities are listed.

Agent Skills (npx skills add blindpaylabs/skills) teach the agent BlindPay's rails, corridors, fees and API patterns, but they do not execute anything. The local server (npx -y @blindpay/mcp) offers the same tools with an API key. Sources: the Build with AI, MCP server and MCP tools docs, and the CLI post. Note that creating a quote is a write tool, so a read-only agent can look but cannot price. The wider story is in the MCP post.

What does a safe agent payout design include?

Six controls, each enforced outside the model.

• Human approval thresholds. Below a small amount and for an allowlisted recipient, the policy can auto-approve. Above it, a person approves. OWASP's guidance on excessive agency recommends requiring human approval for high-impact actions and enforcing authorization downstream, not by trusting the model.
• Spend limits. BlindPay's docs say the dashboard creates one API key type with full read and write access, and a restricted key is not yet available. Put per-payment, daily and monthly caps in the code that calls the API.
• Quote expiry handling. The approver sees the quote's amount, fees and recipient, and approves within the 5-minute window. If expires_at has passed, re-quote and approve again. A quote ID backs one payout only.
• Audit trail. Log the prompt, the proposed action, the quote ID, the approver, the payout ID and the webhook event. BlindPay's MCP docs say tool calls share the same KYC and KYB requirements, limits and audit trail as direct API requests.
• KYC-verified recipients. Only let the agent pay bank accounts you have already added and reviewed. Every payment flows through a customer that completed KYC or KYB, and the API user collects the data and BlindPay verifies it.
• Webhook-based confirmation. Treat the payout as done only after a signed webhook. Verify the svix-id, svix-timestamp and svix-signature headers.

Build the approval screen from the structured quote data in your own code, not from text the model wrote, so the model cannot describe a different amount than the one it will send. This is our design advice, informed by OWASP's note that approvals fail when the dialog itself is manipulated.

What is a safe-by-default agent payout policy?

A policy file your own code loads and enforces before any money-moving call. This template is illustrative: the keys and numbers are placeholders you set, and none of it is a BlindPay feature or BlindPay's limits.

agent_payout_policy:
  environment: development        # switch to production only after review
  connection: mcp_readonly        # read-only until the checks below pass
  allowed_recipients: [ba_REPLACE_ME]   # bank accounts already reviewed
  per_payment_cap_usd: 500        # placeholder
  daily_cap_usd: 2000             # placeholder
  auto_approve_below_usd: 0       # start at zero: everything needs a person
  require_human_above_usd: 0
  approval:
    bind_to: quote_id             # approval is valid for one quote only
    max_age_seconds: 240          # leave margin under the 5-minute quote life
    show: [recipient, receiver_amount, fees, expires_at]
  execute:
    idempotency_key: per_payment  # reuse the key on retry
  confirm:
    source: webhook               # payout.complete, signature verified
    on_failed_or_stuck: alert_human
  log: [prompt, proposed_action, quote_id, approver, payout_id, webhook_event]

Start with approval for everything, watch a month of logs, then raise the auto-approve line for small payments to allowlisted recipients. Keep the model out of the policy: it proposes, your code decides.

What should the safety checklist cover?

1. Run the agent on a development instance first. Payouts complete automatically, and request_amount 66600 forces failed and 77700 forces refunded.
2. Connect read-only (/mcp/readonly) while you test prompts.
3. Keep the API key out of the model's context and out of client code.
4. Confirm the agent is signed in to one instance. The server fills the instance into every call.
5. Add the confirmation step yourself, since the server does not block calls on its own.
6. Check that every recipient has a verified customer behind it.
7. Send an Idempotency-Key on every execute call.
8. Verify webhook signatures and alert on failed or stuck payouts.
9. Know the disconnect path: in the dashboard, Settings, then Connected apps.

On custody: BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. If a payout cannot be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or to the sending wallet when none is set; on Pix and other non-USD local rails the refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review. Optional BlindPay-managed wallets (beta) are custodial when you choose that path.

Methodology and sources

External sources: OWASP LLM06:2025 Excessive Agency, the Model Context Protocol specification on tools, and modelcontextprotocol.io. BlindPay facts come from the Build with AI, MCP server, MCP tools, payouts, idempotency, API keys and webhooks docs, and the BlindPay CLI post. The attribution of the "most AI-native stablecoin infrastructure" claim is BlindPay's own description in that post. BlindPay publishes this article.

What to do next

Explore the BlindPay MCP server and the CLI. Connect an agent to the read-only endpoint on a development instance, run a payout to completed with the payout quickstart, and only then add approvals and a policy like the one above.