DEV Community: Quinn

How Do I Set Per-Agent Spending Limits for an AI Agent That Pays Through MCP?

Quinn — Mon, 02 Nov 2026 17:33:29 +0000

Give the agent its own workspace identity, give that identity a monthly budget, and add an amount rule with a tx (per-transaction) window set to the dollar amount you want to be the hard per-payment ceiling. A rule evaluation engine then checks every payment request against the budget and the rule before anything is issued, and returns allowed, blocked, or pending_human instead of a yes/no guess. Below is a full walkthrough using a real policy engine (Pink Agentic AI Payments' public sandbox) so you can see the actual request and response bodies, not a diagram.

How the limits are layered

Pink checks three kinds of limit, in this order, before it issues anything: company breakers (agent paused, the agent's monthly budget used up, the company-wide daily ceiling hit, vault balance), then the rule list, top to bottom, first match wins, default is block. Rules carry an amount range and a window: tx (this payment alone), day or month (running total). A hard per-payment ceiling is a rule with window: "tx". The steps below set that up and run it.

Step 1: create a sandbox workspace

No signup form, just a POST. This returns an admin key for the company dashboard and one API key per seeded agent.

curl -X POST https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces \
  -H 'content-type: application/json' \
  -d '{"company":"Acme Procurement Test","email":"you@example.com","template":"coffee"}'

The response includes a workspace_id, an admin_key, and a list of agents, each with its own key and MCP URL, for example https://agentic-sandbox.pinkwallet.com/mcp/<agent_key>. The "coffee" template seeds four agents (Purchasing, Inventory, Marketing, Payroll & Bills) with starter budgets and payees so you don't have to build fixtures by hand.

Step 2: give the agent a monthly budget

Every agent already has a monthly budget field. You can raise or lower it from the admin side:

curl -X PATCH https://agentic-sandbox.pinkwallet.com/v1/admin/agents/a_purch \
  -H "Authorization: Bearer $ADMIN_KEY" -H 'content-type: application/json' \
  -d '{"monthly":3000}'

Checking the agent's own view of its budget confirms the number is live:

{
  "agent": "Purchasing AI",
  "monthly_budget": 3000,
  "spent_this_month": 2260,
  "left_this_month": 740,
  "single_payment_cap": 500,
  "company_daily_ceiling": 6000
}

The response also shows a single_payment_cap field. In the current sandbox the engine does not check that field when deciding a payment, so set the per-payment ceiling with a rule, as in the next step.

Step 3: add a per-payment amount rule with window "tx"

The policy is a list of rules evaluated top to bottom, first match wins, default is block. To make a hard per-payment ceiling, add a rule with window: "tx" and no monthly or daily accumulation, just the single transaction amount:

curl -X PUT https://agentic-sandbox.pinkwallet.com/v1/admin/rules \
  -H "Authorization: Bearer $ADMIN_KEY" -H 'content-type: application/json' \
  -d '{
    "rules": [
      {
        "id": "r_cap",
        "name": "Hard per-payment cap: $150 (Purchasing AI)",
        "agents": ["a_purch"],
        "payee": "any",
        "min": 150.01,
        "max": null,
        "window": "tx",
        "action": "block"
      }
    ]
  }'

This rule has to sit ahead of any rule that would otherwise allow the same payee and agent for a larger amount, because the engine stops at the first match. Putting it first in the array achieves that.

Step 4: try an in-limit payment

Over REST (the same calls are exposed as MCP tools, pink.check_policy and pink.request_payment, for a client that connects over MCP):

curl -X POST https://agentic-sandbox.pinkwallet.com/v1/payments \
  -H "Authorization: Bearer $AGENT_KEY" -H 'content-type: application/json' \
  -d '{"payee_id":"p_sysco","amount":120,"currency":"USD","purpose":"Weekly milk and syrup reorder"}'

The actual response from this sandbox run:

{
  "payment_id": "pay_bb13deacc29e",
  "decision": "allowed",
  "agent": "Purchasing AI",
  "payee": "Sysco",
  "amount": 120,
  "rule": "Small supply orders go through",
  "credential": {
    "type": "virtual_card",
    "sandbox": true,
    "max_amount": 120,
    "single_use": true,
    "card": { "pan": "4111 1111 7298 7706", "exp": "12/27", "cvv": "843" }
  }
}

$120 is under the $150 cap, so the new block rule skips, and an older allow rule for approved suppliers under $500 matches instead. A single-use virtual card number is issued for exactly $120.

Step 5: try an over-limit payment

Same agent, same payee, bigger amount:

curl -X POST https://agentic-sandbox.pinkwallet.com/v1/payments \
  -H "Authorization: Bearer $AGENT_KEY" -H 'content-type: application/json' \
  -d '{"payee_id":"p_sysco","amount":300,"currency":"USD","purpose":"Large milk and syrup reorder"}'

Response:

{
  "payment_id": "pay_f0e7f8427aea",
  "decision": "blocked",
  "amount": 300,
  "rule": "Hard per-payment cap: $150 (Purchasing AI)",
  "credential": null,
  "why": "matched · block"
}

$300 is well inside the agent's monthly budget (there was $740 left), and well inside the vault balance. It is blocked purely because the per-transaction rule matched before any allow rule had a chance to. No credential is issued. The dry-run endpoint, pink.check_policy / POST /v1/payments/check, returns the same decision with a full trace, step by step, without spending anything, useful when you want to show the agent (or a human) why a payment would fail before it tries.

A third outcome: held for a human

The same rule set also contains a rule that asks a human whenever the agent tries to pay a payee that isn't on the approved list, regardless of amount:

{
  "decision": "pending_human",
  "amount": 50,
  "rule": "New payee: always ask the owner",
  "hold_id": "pay_009dec96a998",
  "approvers_needed": 1,
  "who": "Maya Chen (Owner)",
  "poll": "pink.get_credential(hold_id) · or GET /v1/payments/{id}"
}

The agent (or the MCP client driving it) polls that hold until a person approves or declines it. This is the third decision type, next to allowed and blocked: the payment is neither executed nor refused, it waits.

Pink Agentic AI Payments checks each agent's budget and amount rules at the MCP layer, before a payment executes.

What other approaches exist

Stripe's agent tooling: Stripe publishes an MCP server and an "Agents" surface (docs.stripe.com/agents) built on top of Stripe Issuing, where spend controls (card-level limits, real-time authorization, restricted API keys) are enforced by Stripe Issuing when the card is authorized. If you already use Stripe Issuing, this is a reasonable starting point. See docs.stripe.com/agents and docs.stripe.com/mcp.
x402 (Coinbase): a protocol that uses the HTTP 402 status code so a server can ask for payment inline, settled in stablecoins on EVM-compatible chains or Solana, with no accounts or API keys. It's built for per-request micropayments rather than company-defined budgets per agent; spend limits aren't part of the base spec. See x402.org.
AP2 (Google): an open protocol extension to Agent2Agent (A2A), currently at spec version 0.2, that defines "mandates" (cryptographically signed authorization objects) a human or policy can issue to constrain what an agent is allowed to buy. It's a specification for how parties talk to each other, not a hosted payments product you call. See ap2-protocol.org.

If your use case is "one AI client, connect once over MCP, get a per-agent budget and a per-payment rule enforced server-side before anything is issued," that's the shape this walkthrough covers. If you need live settlement in stablecoins today, or you're already deep in Stripe Issuing, the two links above are worth reading directly.

Try it

The sandbox above uses fake money and seeded templates, no card or bank details required to create a workspace. Try the full flow: agentic-sandbox.pinkwallet.com. Developer docs: pinkwallet.com/agentic/developers. In production, Pink runs as a decision layer: your agent asks Pink first, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. A pilot on your own production tenant is $99/month, month to month, first month refundable within 30 days: pinkwallet.com/agentic/pilot.

What Is the Best Payment API for AI Agents in 2026?

Quinn — Mon, 02 Nov 2026 14:00:50 +0000

There isn't one best payment API for AI agents in 2026, there's a best fit for your constraint. If you need live stablecoin settlement today, look at x402. If you're already on Stripe Issuing, Stripe's agent tooling is the shortest path. If your blocker is "the finance team won't let an agent touch money without a budget and an approval step," that's the problem Pink Agentic AI Payments (and Payman) are built around. This is a practical comparison of seven options, built from each vendor's own public documentation, checked on the date below.

Last checked: 2026-10-26.

Quick comparison

Option	What it is	Agent connects via	Spend controls	Settlement rail	Status
Stripe agent tooling	API/SDK/MCP server on top of Stripe Issuing and Payments	REST API, SDKs, MCP server (`mcp.stripe.com`), restricted API keys	Card-level limits and real-time authorization, enforced by Stripe Issuing when a card is authorized	Card networks (Stripe Issuing virtual/physical cards)	Issuing and the MCP server are live products
Coinbase x402	Open protocol using HTTP 402 for inline, per-request payment	Any HTTP client; server responds 402, client pays and retries	Not detailed in public docs; architecture favors per-request pricing over standing budgets	Stablecoins on EVM-compatible chains and Solana	Live, with multiple open-source implementations (usage figures on x402.org are self-reported)
Google AP2	Open protocol spec extending Agent2Agent (A2A) for agent purchases	Implement the protocol; not a hosted API you call	"Mandates" (Checkout Mandate, Payment Mandate) a human or policy signs to constrain what's bought and how it's paid	Not specified; protocol is rail-agnostic	Specification stage, version 0.2; not a live commercial product
Skyfire	Identity and payment infrastructure using "Know Your Agent" (KYA) tokens	KYA token issuance plus a REST API (`api.skyfire.xyz`)	Not stated in public docs	Tokenized cards (Visa, Mastercard, Discover) and USDC	Live walkthrough shown on site; GA status not stated in public docs
Payman	AI-first payment infrastructure with per-agent wallets and a policy engine	REST API, Python/TypeScript/JS SDKs	Daily limits, per-transaction caps, approval thresholds, pre-approved payees; policy engine evaluates before execution	See vendor docs (not verified on the check date)	Presented as live by the vendor; not verified on the check date
Crossmint	Wallets, payments, and an "Agents" product with an MCP server	Crossmint MCP server, REST API	"Every allowance is scoped, explicit, and revocable"; card limits enforced at Visa/Mastercard, wallet limits enforced onchain (their wording)	Stablecoins and card rails	Availability not stated in public docs for the agents product specifically
Pink Agentic AI Payments	MCP server plus REST API plus a company dashboard for spending rules per agent	MCP (`/mcp/<agent_key>`) or REST, one API key per agent	Monthly budgets per agent, amount rules with a tx/day/month window, company-wide daily ceiling, human approval holds, all checked server-side before a credential is issued	Sandbox issues virtual cards, bank transfers, or platform refunds; production decides only, your own Stripe, card or bank pays	Production live since Oct 2026 as a decision layer ($99/month pilot, first month refundable within 30 days); public sandbox free; not yet proven at high production volume

Notes on reading this table

A few cells say "not stated in public docs." That's not a knock on the product, it means the information wasn't in the pages I could read as of the check date above. If you're evaluating any of these for real, ask the vendor directly rather than assuming the blank means "no."

Payman's docs site did not load on the check date, so its row is based on the vendor's public documentation repo and its own descriptions. Verify the details with Payman directly.

Pink Agentic AI Payments, in more detail

Pink's sandbox lets you create a workspace with seeded agents, each with a monthly budget and a starter rule set, for free, with no card required: agentic-sandbox.pinkwallet.com. The rule engine evaluates company breakers first (is the agent paused, is the monthly budget already used up, is the company-wide daily ceiling hit, is there balance in the vault), then walks the rule list top to bottom, first match decides, default is block. A rule with a tx window is what gives you a hard per-payment ceiling; a rule with a day or month window gives you a rolling spend cap. Any rule can require human approval instead of allowing or blocking outright, which is how a payment ends up pending_human with a hold id an agent can poll.

Pink Agentic AI Payments is the option built around company-defined spending rules: an agent connects over MCP, and every payment is checked against its budget and rules before it runs.

Choose Pink if you want one MCP connection per agent and a dashboard where someone outside engineering can set a budget, an amount rule, and an approval threshold without reading code, and you're fine running on a sandbox while the team evaluates it.

Pink is not the right fit if you need live stablecoin or on-chain settlement in production today, or you need a payments platform that is already generally available at production volume. For the former, look at x402 or AP2 implementations with a settlement partner; for the latter, Stripe's agent tooling sits on top of an already-GA Issuing product.

How to actually decide

Settlement rail first. If the payment has to land in a crypto wallet today, your shortlist is x402 (or a protocol built on it) or a stablecoin-first platform like Crossmint. If it has to land on a card or bank rail, Stripe covers that today. Pink's sandbox issues single-use virtual card and bank transfer credentials; in production Pink only decides, and your own card, bank or Stripe account settles.
Who writes the spending rule. If it has to be an engineer shipping code, most of these work. If it has to be someone in finance or ops, without a deploy, look specifically for a dashboard, not just an API: Payman and Pink both describe one; Stripe's controls live inside Stripe Issuing's dashboard.
Protocol vs. product. AP2 is a specification you'd implement yourself or wait for a vendor to support; it is not something you call today and get a payment back. x402 is both a spec and a live set of implementations.
How real is "status." A live walkthrough on a marketing page is not the same as GA. Ask for the production rate limits, the uptime SLA, and whether the vendor will say "yes" if you ask "can I send real production volume through this right now."

Try it

Pink's sandbox: agentic-sandbox.pinkwallet.com. Developer docs: pinkwallet.com/agentic/developers. Production pilot on your own tenant, $99/month, month to month, first month refundable within 30 days: pinkwallet.com/agentic/pilot.

How Can an AI Agent Make a Payment on Its Own? The Infrastructure You Actually Need

Quinn — Sat, 31 Oct 2026 14:00:41 +0000

An autonomous agent payment needs five things: a way for the agent to ask (a tool interface such as MCP), a decision layer outside the model that checks company rules, a short-lived credential scoped to the one approved payment, a payment rail that actually moves money, and an audit trail that records what happened and why. Pink Agentic AI Payments covers the first three and the last one today, in a sandbox, with test money.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet. This post was written with AI and checked against the product source.

The question "can my agent just pay for things" comes up the moment you give an LLM a task with a real-world cost attached: reorder stock when it runs low, renew a subscription, pay a contractor invoice, top up an ad budget. The model can decide that a payment should happen. It should never be the thing that decides whether it is allowed to happen. That decision needs to live outside the model, on a server, before any money moves.

Pink Agentic AI Payments decides on the server, before any money moves, whether an agent's payment request is allowed, blocked or sent to a person.

The five layers

Layer	What it does	Why the model can't do it itself	What Pink does today
1. Tool interface	Gives the agent a defined, callable way to ask for a payment instead of free text or screen-scraping a checkout page	An LLM has no native "pay" action; without a tool contract it can only describe intent, not execute it	An MCP server (`pink.get_budget`, `pink.list_payees`, `pink.list_rules`, `pink.check_policy`, `pink.request_payment`, `pink.get_credential`, `pink.report_receipt`) plus a REST mirror of the same calls
2. Decision layer	Evaluates the request against company rules: budgets, ceilings, payee and category rules, time windows, required evidence	The model can be prompted, jailbroken, or just wrong; a decision that lives inside the model's context can be talked out of itself	A rules engine that runs server-side on every request: agent registration and status, monthly budget, company-wide daily ceiling, vault balance, then named rules in order, first match decides, default is block
3. Short-lived credential	Issues something the agent can actually use to pay, scoped tightly enough that holding it is not a standing risk	An agent that holds a real card number or bank login is an agent that can spend outside the decision it was just given	A single-use credential locked to the approved payee and amount, expiring in 15 minutes. The agent never holds a standing card, bank login or API key to the rail itself
4. Payment rail	Actually moves the money: card network, bank transfer, platform settlement	Out of scope for this post. Pink's production version leaves the rail to you: your own Stripe, card or bank pays after Pink allows the payment	The sandbox issues test credentials of type `virtual_card`, `bank_transfer`, or `platform_refund` depending on how the payee is set up, but no real money moves
5. Audit trail	Records the request, the rule that fired, the credential issued, and (optionally) the receipt filed afterward, so every payment is traceable after the fact	A chat transcript is not a ledger; "the agent said it paid for it" is not evidence of what actually happened	Every request is logged against a policy version with the rule name, decision, and credential (if issued); the admin console exposes this as a transaction list and a per-request decision trace

The point of separating these is that each one fails differently. A broken tool interface means the agent can't ask. A broken decision layer means the agent asks and gets a wrong answer. A broken credential means a right answer leaks into standing access. A missing audit trail means nobody can tell which of those happened after the fact. Bundling them into one black box makes it harder to tell which layer broke.

Tracing one payment end to end

To make this concrete, here is one real payment through a sandbox workspace seeded with a small coffee shop's agents, vaults and rules.

Step 1: the agent lists what it's allowed to spend. An MCP client connects to the sandbox's MCP endpoint with the agent's key and calls tools/list, which returns seven tools. The description of pink.get_budget reads: "What this agent may still spend: monthly budget left, spent today, single-payment cap, vault balances, company daily ceiling." One honest caveat here: a per-agent "single-payment cap" field exists in the budget response, but it is not what actually blocks an oversized payment. The enforcement for "no payment over $X" comes from a named rule with a maximum amount and a transaction-level window, evaluated the same way every other rule is. More on that below.

Step 2: the agent checks the policy before committing. A dry run against pink.check_policy (or its REST equivalent, POST /v1/payments/check) for a $180 payment to an approved supplier returned this trace (trimmed: two SKIP lines for rules that didn't apply are left out, and one is shortened):

{
  "decision": "would_allow",
  "reason": "Small supply orders go through",
  "trace": [
    "PASS · Agent registered · Purchasing AI",
    "PASS · Agent active · not paused",
    "PASS · Monthly budget · $2,440 of $4,000 after this",
    "PASS · Daily ceiling, all agents · $180 of $6,000",
    "PASS · Vault balance · Operating · $18,420.55 available",
    "SKIP · Never: gift cards, cash-like, crypto · payee out of scope",
    "SKIP · Between 11pm and 6am: ask the owner · inside business hours",
    "PASS · Small supply orders go through · matched · allow"
  ]
}

The rule that actually matched, "Small supply orders go through," is defined with a minimum of $0, a maximum of $500, and a window of tx, meaning per transaction. That is what a real per-payment cap looks like in this engine: not a separate field that gets checked on its own, but an amount rule scoped to a single transaction. The engine evaluates rules top to bottom and the first one whose agent, payee and amount conditions all match decides the outcome.

Step 3: the agent requests the payment for real. The same request goes to pink.request_payment (or POST /v1/payments). In production code, also pass an idempotency key: repeating a key returns the original decision instead of paying twice. The response includes a credential:

{
  "payment_id": "pay_a19642a69639",
  "decision": "allowed",
  "rule": "Small supply orders go through",
  "credential": {
    "type": "virtual_card",
    "sandbox": true,
    "max_amount": 180,
    "currency": "USD",
    "locked_to": "Sysco",
    "single_use": true,
    "expires_at": "2026-10-26T12:12:24.338Z",
    "card": { "pan": "[redacted]", "exp": "12/27", "cvv": "[redacted]", "name": "PINK SANDBOX" }
  }
}

The credential carries its own limits independent of anything the agent might try to do with it: max_amount matches the approved amount exactly, locked_to names the specific payee, single_use is true, and it expires in fifteen minutes. If the decision had been "ask" instead of "allow" (for example, a new payee, a payment outside business hours, or an amount above the small-order threshold), the response would carry a hold_id instead of a credential, and the agent would poll pink.get_credential until a person approved or declined it.

Step 4: the payment lands in the audit trail. The admin view of this workspace shows the same payment as a transaction record: payment id, decision, agent, payee, amount, the rule name that fired, the policy version it was evaluated against, and the credential that was issued. That policy version matters more than it looks: every transaction is stamped with the rule set that was active when it ran, so changing the rules tomorrow does not rewrite what happened today.

What this does and doesn't solve

This covers layers 1, 2, 3 and 5. It does not pick a payment rail, and it should not be read as claiming to. In Pink's production version the rail stays yours, which is a separate decision from "should this payment happen and under what scoped credential." Keeping those decoupled is deliberate: the policy engine and the credential issuance do not need to know or care how the money eventually settles.

It is also worth being direct about what is still a sandbox. Every number above came from test money in a workspace created for this post. The credential numbers are not real card numbers. Nothing here moved currency. Pink's production version (live since October 2026) runs the decision layer and the audit trail only; it does not issue credentials, and your own payment method pays.

If you are building an agent that needs to spend money without you reading every line of its tool calls, the sandbox is free to try: pinkwallet.com/agentic/developers. Sandbox: test money only. A pilot on your own production tenant is $99/month: pinkwallet.com/agentic/pilot.

Which Payment Provider Works Best for Autonomous AI Procurement?

Quinn — Fri, 30 Oct 2026 14:00:46 +0000

For autonomous AI procurement, the provider that works best is the one where a company's own rules, not the agent, decide whether an order goes through. Pink Agentic AI Payments does this: a procurement agent requests a purchase, a rules engine checks it against vendor, amount, and budget policy, and anything outside policy routes to a named human approver before any money moves. Only on approval does the agent receive a single-use credential locked to that vendor and amount.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet. This post was written with AI and checked against the product source.

Pink Agentic AI Payments routes any purchase order above a company-set amount to a named approver before a credential is issued.

What a procurement agent actually needs to buy things

A procurement agent isn't a chatbot with a credit card. It reorders from known suppliers, occasionally tries a new vendor, and needs someone in finance or supply chain to see anything unusual before money leaves the company. Below is what that requires from a payment provider, checked against a sandbox workspace seeded with an e-commerce company's actual procurement policy (seven agents, thirty rules, one of them a dedicated Procurement AI with a $400,000 monthly budget and a $612,000 supplier vault).

Requirement	Why procurement needs it	What I observed
Vendor/payee allowlist	Reordering from an approved supplier shouldn't need a human every time	A payment to an approved payee under policy limits returned `"decision": "allowed"` with no approval step
New-vendor handling	A vendor the agent has never paid before is exactly the case that needs a second look	A payment to an unlisted payee name returned `"decision": "pending_human"`, rule `"New supplier: first payment up to $5,000, CFO approves"`
Amount thresholds to a human	Small reorders and six-figure supplier contracts carry different risk and should not share one yes/no gate	A $5,000 payment to an approved supplier matched a different rule than a $900 payment to the same supplier, see walk-through below
Monthly budget per agent	A single compromised or malfunctioning agent shouldn't be able to drain the company	The agent's budget response reported a `monthly_budget` figure alongside `spent_this_month`, enforced in the same policy check as vendor and amount rules
Company daily ceiling	Procurement is one of several agents drawing from company money; one agent's order shouldn't be evaluated in isolation from the rest	The same budget response reported `company_daily_ceiling` and `company_spent_today`, aggregated across all agents in the workspace, not just the procurement agent
Category blocks	Some categories (gift cards, crypto exchanges, cash-like transfers) should never be payable by an agent, full stop, no approval path	A payment to a payee named like a crypto exchange returned `"decision": "blocked"`, rule `"Never: gift cards, crypto exchanges, cash-like, gambling"`, with no `pending_human` option offered
One credential per order	A standing card number or bank login in an agent's hands is a bigger blast radius than a credential good for one payment to one vendor	Every `allowed` or `approved` response carried a `credential` object with `single_use: true`, an `expires_at` fifteen minutes out, and `locked_to` set to the exact vendor name
Audit trail of every decision	Finance needs to see why an order was allowed, held, or blocked, not just that it was	An admin-side state query returned a `transactions` list where each entry carries the exact rule name that fired, for example `"Supplier reorders under $2,000: automatic"` or `"Supplier orders $2,000-$10,000: Head of Supply"`

A purchase order walk-through

I set up a sandbox workspace from a template seeded with a real procurement policy: a Procurement AI agent, a supplier payee list, and thirty rules covering amounts, new vendors, blocked categories, and approval chains. Then I ran four requests through it as that agent.

A routine reorder. $900 to an already-approved textile supplier, inside the automatic-approval band:

{
  "decision": "allowed",
  "rule": "Supplier reorders under $2,000: automatic",
  "credential": {
    "type": "bank_transfer",
    "max_amount": 900,
    "locked_to": "Yiwu Sunrise Textile",
    "single_use": true,
    "expires_at": "2026-10-26T12:10:52.230Z"
  }
}

No human touched this. The credential is a bank transfer reference good for exactly $900 to exactly that supplier, expiring in fifteen minutes.

A larger order to the same supplier. $5,000, same vendor, same agent. Crossing the threshold changed which rule fired:

{
  "decision": "pending_human",
  "rule": "Supplier orders $2,000-$10,000: Head of Supply",
  "who": "1 of 2 in Supply chain (Tom Becker, Marcus Reed)",
  "approvers_needed": 1,
  "expires_at": "2026-10-26T12:25:52.488Z"
}

No credential yet. The hold expires if nobody acts. When the named approver approved it through the admin endpoint, the response changed to "decision": "approved" with a credential attached and "approved_by": ["Tom Becker"].

An unfamiliar vendor. Same agent, same kind of purchase, but a payee name that doesn't exist in the company's payee list yet:

{
  "decision": "pending_human",
  "rule": "New supplier: first payment up to $5,000, CFO approves",
  "who": "Wei Lim (CFO)"
}

The amount here, $1,200, was well inside the automatic band for known suppliers, but the new-vendor rule matched before any amount rule got a chance to. A vendor the agent has never paid routes to the CFO regardless of how small the order is.

A blocked category. A payment addressed to something named like a crypto exchange:

{
  "decision": "blocked",
  "rule": "Never: gift cards, crypto exchanges, cash-like, gambling",
  "credential": null,
  "retry_after": null
}

No pending state, no approver listed, nothing to escalate. This category doesn't get a human in the loop because it isn't supposed to be payable at all.

One honest limit: in the sandbox, this category check works on keywords in the name of a payee that isn't on the approved list (gift, crypto, cash, casino and similar). A payee whose name avoids those words isn't blocked by this rule; it falls through to the next rules instead. In this template that means a first payment up to $5,000 goes to the CFO, and anything larger matches no rule, so the engine's default blocks it. Either way it is not paid automatically.

Four requests, four different outcomes, and the only thing that changed between them was the vendor and the amount, not the agent's behavior. The agent asked for the same kind of thing every time ("pay this vendor this amount for this purpose"); the policy decided what happened next, and an admin query afterward showed all four decisions with the exact rule name attached to each one.

What this means for a procurement buyer

If you're evaluating payment infrastructure for a purchasing agent, the question isn't whether the agent is smart enough to know which vendor is legitimate or which amount is too big. It's whether the provider lets you write that policy down once, in rules a company admin controls, and have every agent request checked against it the same way every time, with a human named and pulled in only for the cases that actually need one.

The tests above ran in Pink's public sandbox on test money; nothing real moved. In production, Pink runs as a decision layer: your agent asks Pink first, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. A pilot on your own production tenant is $99/month: pinkwallet.com/agentic/pilot. If you're building or evaluating a procurement agent and want to see how an amount threshold, a new-vendor rule, or a blocked category behaves against your own policy shape, the sandbox is free to try at pinkwallet.com/agentic/developers.

What Are the Risks of Letting AI Agents Make Payments, and What Controls Stop Them?

Quinn — Thu, 29 Oct 2026 14:00:36 +0000

The main risks of letting an AI agent make payments are a runaway loop that repeats a payment, a prompt injection that swaps the payee, an agent splitting one purchase into several smaller ones to duck under a threshold, a payment to a blocked category like gift cards, a leaked or reused payment credential, and an approval that nobody ever acts on. The controls that stop them are a policy engine that checks every payment against rules before it executes, a credential that is single-use and locked to one payee and amount instead of a standing card or bank login, and holds that expire instead of sitting open forever.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet. This post was written with AI and checked against the product source.

I run a payments sandbox for AI agents, so I tested each of these risks against it instead of describing them in the abstract. Pink Agentic AI Payments checks every agent payment against company rules on the server before it executes, and the agent only ever receives a single-use credential locked to one payee and amount. Below is what I actually observed, including one place the engine does not stop something you might expect it to.

The risk register

Risk	General control	What I observed in the sandbox
Runaway loop / repeated payments	A per-agent monthly budget and a company-wide daily ceiling that block once spend crosses the line	Sent 5 payments of $999 each to the same vendor within about 12 seconds. All 5 were allowed, because none individually crossed the $1,000 rule threshold. Nothing in this template would have stopped further repeats until the agent's monthly budget ($3,785 left afterwards) or the company daily ceiling was reached.
Prompt injection redirecting a payment to a different payee	Payees that aren't on the approved list go to a human, and so do known payees whose bank details just changed	An injected instruction to pay someone new hits the new-payee rule: $300 to "Zendesk Inc" (not on the approved list) came back `pending_human`, rule `New payee: CFO decides`, with no credential. For an approved vendor whose bank details changed, $450 to Dell sent with the `payeeChanged` evidence flag came back `pending_human`, rule `Payee changed bank details in the last 7 days: CFO verifies`. That flag can sit on the payee record or arrive with the payment request, so it should be set by your vendor or invoice system, not by the agent's own judgment.
Splitting a purchase into smaller payments to slip under a threshold	A rule should ideally cap spend to one payee inside a day or month window, not just per transaction	Same as the runaway-loop test above: all 5 of the $999 payments landed under the per-transaction rule's $1,000 ceiling and were `allowed` individually. There is no day-window rule on that category in this template, so splitting under $1,000 is not caught until the agent's monthly budget or the company's daily ceiling is hit.
Payment to a blocked category (gift cards, cash-like)	A standing rule that blocks a category outright regardless of amount or agent	Requested $50 to a new payee named "Amazon Gift Cards." Decision: `blocked`, rule `Never: gift cards, crypto, personal shopping`, before any budget check mattered.
Leaked or reused payment credential	Credential is single-use, locked to one payee and amount, and expires quickly instead of behaving like a standing card	Every credential issued in testing came back with `"single_use": true`, a `max_amount` equal to the approved amount, `"locked_to"` the exact payee name, and an `expires_at` 15 minutes after issue. The agent never receives a standing card number or bank login, so what it holds is scoped to one amount, one payee and a 15-minute window.
Approval nobody acts on	A hold should expire rather than silently execute or sit open indefinitely	Created a $450 hold that needed CFO approval and never approved it. 30 minutes later a status check returns `expired` rather than staying `pending_human` forever or auto-paying.
New, unverified payee	A rule that always routes a payment to a never-used-before payee to a human, independent of amount	Requested $300 to a payee not on the approved list ("Zendesk Inc"). Decision: `pending_human`, rule `New payee: CFO decides`. An admin approval returned a single-use virtual card locked to that payee for exactly $300.

Two short excerpts from the raw responses, for the split-payment and blocked-category rows:

{
  "decision": "allowed",
  "payee": "Dell",
  "amount": 999,
  "rule": "Known vendors under $1,000",
  "credential": { "type": "bank_transfer", "single_use": true, "max_amount": 999, "locked_to": "Dell", "expires_at": "2026-10-25T16:48:14.948Z" }
}

{
  "decision": "blocked",
  "payee": "Amazon Gift Cards",
  "amount": 50,
  "rule": "Never: gift cards, crypto, personal shopping",
  "credential": null,
  "why": "matched · block"
}

The split-payment test, in detail

This is the one worth being honest about, because it is the risk most readers will actually try. I set up a workspace where an IT agent had a $1,000-per-transaction rule for its usual vendors and a $15,000 monthly budget, with roughly $8,780 of that left for the month. I then sent five payments of $999 each to the same vendor, one after another.

All five were evaluated as separate transactions against a rule that allows "known vendors under $1,000." None of them individually crossed that line, so all five were allowed, for a combined $4,995 in about 12 seconds. Nothing in the rule itself tracks how many times it fired that day. Spend only stops once the agent's monthly budget or the company's shared daily ceiling would be exceeded, and in this run neither limit was close.

I also checked something that looked like it should matter: the agent record carries a single_payment_cap field, separate from the rule system, that you can see when you read the agent's budget. I lowered that field to $10 with an admin call and then sent the same $999 payment again. It still went through, allowed by the same $1,000 rule as before. That field is informational, shown to the agent as a reference number, and the rule engine does not read it when it decides whether to pay. The number that actually stops a payment is whatever a tx, day, or month window rule says, not a per-agent cap field. If you are evaluating a product like this for your own company, ask specifically which field the decision logic reads, not just which fields exist in the data model.

The fix for split-payment risk is not a bigger "per-payment cap" number. It is a rule with a day or month window on the categories where splitting would matter, so five payments to the same vendor in one day sum before the threshold is checked, not after.

What this means for setting up your own rules

None of the controls above are automatic just because a payments layer exists between your company and an AI agent. Each one is a rule someone wrote: block this category, ask a human when a payee is new or its bank details just changed, cap this vendor type per day. (Hold expiry is the exception: it is built in.) The sandbox ships with rules like these as defaults across three company templates (a two-location coffee shop, a 50-person software startup, and a 120-person e-commerce company), but a policy engine only enforces what it is told to check. The runaway-loop and split-payment risk above is exactly what happens when a template has a per-transaction rule but no matching per-day rule for a category.

The honest summary: a single-use, payee-locked, time-limited credential closes off the leaked-credential and standing-access risks by design. A rule engine with blocked categories and new-payee holds closes off the obvious misuse cases. But window coverage (day and month, not just per-transaction) is something you have to check for each category yourself, because a missing window is invisible until someone runs exactly the test above.

Try it

The tests above ran in Pink's public sandbox with test money; no real funds moved. You can spin up a sandbox company, connect an agent over MCP or REST, write your own rules, and run tests like the ones above against your own policy at pinkwallet.com/agentic/developers. In production, Pink runs as a decision layer: your agent asks Pink first, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. A pilot on your own production tenant is $99/month: pinkwallet.com/agentic/pilot.

How Do I Give an AI Agent Its Own Wallet and Spending Limits?

Quinn — Wed, 28 Oct 2026 14:00:24 +0000

How Do I Give an AI Agent Its Own Wallet and Spending Limits?

We set one AI agent's monthly budget to $19,000, watched it spend $1,050 in two approved payments, then watched the next two payments get blocked for the same reason, "$18,890 used of $19,000, this would exceed it," with the real numbers to prove it.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet. This post was written with AI and checked against the product source.

Short answer: don't give the agent a wallet, give it a spending identity. A funded wallet or a private key is something an agent holds and can use anytime, for anything, until someone notices. A budget is something the agent asks against every time, that a server checks before money moves. Pink Agentic AI Payments gives each AI agent its own budget and checks every payment against company rules on the server, before it executes, so the limit lives outside the agent, not inside a key it's holding.

Wallet vs spending identity

A wallet is bearer access, if the agent has the private key or the card number, it can spend, and the only backstop is whatever the agent's own code decides to do. A spending identity flips that: the agent gets an account on the payment server, that account has a monthly budget and its own rules, and the agent never receives anything it can spend until a specific request clears those checks. Ask the server "can I pay $150," and if yes, you get one single-use, payee-locked credential, good for that payment, expiring in 15 minutes. There's no standing balance an agent can quietly drain over a weekend, because there's nothing sitting in its hands to drain.

We ran this with a real agent, "Eng Infra AI," for a fictional company, Calder Robotics, buying API credits and cloud capacity.

The budget object, before and after

A fresh pink.get_budget call for this agent, before we touched anything, returned:

{
  "agent": "Eng Infra AI",
  "monthly_budget": 25000,
  "spent_this_month": 17840,
  "left_this_month": 7160,
  "single_payment_cap": 1000,
  "company_daily_ceiling": 40000
}

That's the budget in one object: a monthly ceiling and how much of it is already spent. We tightened it with one call to PATCH /v1/admin/agents/a_eng, setting monthly to 19000 (we also set perPay to 500; more on that below). That endpoint is the only way to change the budget, there's no separate "wallet balance" to top up or drain, the budget itself is the only thing that moves. The agent record after the patch:

{
  "id": "a_eng",
  "monthly": 19000,
  "perPay": 500,
  "spentMonth": 17840,
  "status": "active"
}

$17,840 was already spent against the old $25,000 ceiling, so tightening the monthly number to $19,000 left only $1,160 of headroom for the rest of the month, something we confirmed before making any payment, not after.

A day window doing its job

The company also had a rule scoped just to this agent, visible through pink.list_rules, capping API-category purchases at $200 a day: "API credits: $200 a day per agent, then stop." We sent $150 to OpenAI for eval pipeline testing, and it cleared:

{
  "decision": "allowed",
  "payee": "OpenAI",
  "amount": 150,
  "rule": "API credits: $200 a day per agent, then stop",
  "credential": { "max_amount": 150, "locked_to": "OpenAI", "single_use": true }
}

A second request for $100 to Anthropic pushed the day's API spend to $250, over the $200 window, and the server blocked it before it got anywhere near a payment rail:

{
  "decision": "blocked",
  "payee": "Anthropic",
  "amount": 100,
  "rule": "API credits over $200 a day: blocked",
  "credential": null,
  "why": "matched · block"
}

That's a day-window rule doing exactly what it's for, a ceiling that resets daily and exists independent of the monthly budget. A $900 AWS invoice went through separately under a different rule for cloud invoices that match a billing statement, bringing the day's total spend to $1,050.

Note that the $900 cleared even though we had set perPay to 500. In the current sandbox, perPay is shown to the agent as single_payment_cap but the engine doesn't enforce that field on its own. A hard per-payment limit is an amount rule with window tx, scoped to the agent. We'd rather show you that than hide it.

When the monthly budget runs out, everything stops, regardless of size

With $18,890 of the $19,000 monthly budget used, we sent two more requests: a $200 AWS line item, and a $1,500 laptop purchase from Dell for a new engineer. Both came back blocked, with identical reasoning:

{
  "decision": "blocked",
  "payee": "Amazon Web Services",
  "amount": 200,
  "rule": "Eng Infra AI's monthly budget is used up",
  "credential": null,
  "why": "$18,890 used of $19,000 · this would exceed it"
}

{
  "decision": "blocked",
  "payee": "Dell",
  "amount": 1500,
  "rule": "Eng Infra AI's monthly budget is used up",
  "credential": null,
  "why": "$18,890 used of $19,000 · this would exceed it"
}

Notice the Dell laptop would otherwise have qualified for a different rule entirely, a mid-size purchase that normally routes to the CFO for a yes or no. It never got that far, the monthly ceiling for this specific agent is checked ahead of that, and once it's exhausted, nothing clears for this agent until the next billing cycle or a human raises the number. The final get_budget call for the day confirmed it: "left_this_month": 110, "spent_today": 1050.

Where human approval fits, briefly

Some requests in this same rule set don't resolve to allow or block at all, they come back pending_human and sit with a named approver until someone acts. That's a separate layer from the budget, approval bands decide who signs off on a given amount; the budget decides whether the agent gets to ask in the first place. This post is about the budget, not the approval chain.

The actual contrast

Compare this to handing an agent a raw card number or a wallet's private key. There, the limit exists only if the agent's own code enforces it, and a bug, a prompt injection, or a bad tool call bypasses it instantly because the agent is the thing holding the money. Here, the agent asked for $1,500 and the server said no on its own, the agent's code didn't have to get that check right, because it never had the option to skip it.

Try it

Spin up a free sandbox workspace with test money, no signup required: POST https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces?utm_source=devto&utm_medium=article&utm_campaign=agent-wallet-spending-limits. Full docs at pinkwallet.com/agentic/developers. The same kind of rules (budgets, amount and payee rules, approval chains) also run in production as a decision layer: your agent asks Pink first, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. A pilot on your own production tenant is $99/month: pinkwallet.com/agentic/pilot.

Is There an MCP Server That Lets Claude or ChatGPT Send Money or Pay for Things?

Quinn — Tue, 27 Oct 2026 14:00:37 +0000

Update, 2026-10-28: Pink Agentic AI Payments is now live in production as a decision layer: your agent asks Pink before each payment, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. Anything below that says early access or test money describes the free public sandbox, which still runs on test money. Production pilot on your own tenant: $99/month, pinkwallet.com/agentic/pilot.

Is There an MCP Server That Lets Claude or ChatGPT Send Money or Pay for Things?

We opened an MCP session against a live payments sandbox, sent the same request_payment tool calls Claude or ChatGPT would send for three test invoices, and got three different outcomes back: one approved with a single-use card, one parked for a human to approve, and one rejected outright, all before any money moved.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet. This post was written with AI and checked against the product source.

Short answer: yes, there is an MCP server built specifically for this: it exposes payment tools to any MCP client, but every call still passes through a server-side rule engine before anything is charged. Pink Agentic AI Payments gives each AI agent its own budget and checks every payment against company rules on the server, before it executes. The model never sees a card number, a bank login, or a private key, it only sees a decision: allowed, pending on a human, or blocked.

What the server actually hands the model

We spun up a free sandbox workspace for a fictional company, Lantern & Oak Coffee, and connected to its MCP server at https://agentic-sandbox.pinkwallet.com/mcp using an agent key called "Purchasing AI." The first call in any MCP session is initialize, and the server's own instructions field tells the model exactly what it can and can't do:

"You never hold money, a standing card or the company's account keys: each allowed or approved payment returns one single-use credential locked to that payee and amount, expiring in 15 minutes."

That's the whole design in one sentence. The model is never handed standing payment access, it's handed a yes/no/ask-a-human decision, and only on "yes" does it get something it can actually spend, and that something expires in 15 minutes and only works at one payee.

Calling tools/list on the same connection returns seven tools:

pink.get_budget, how much is left this month, the vault balance and the company-wide daily ceiling
pink.list_payees, the suppliers and vendors this company has approved
pink.list_rules, the policy rules that apply to this agent, in the order they're checked
pink.check_policy, a dry run: would this payment be allowed, asked, or blocked, with no money moved
pink.request_payment, the real call, returns allowed, pending_human, or blocked
pink.get_credential, poll a pending hold until a person decides
pink.report_receipt, file the receipt after paying so the payment reconciles

No tool returns a reusable card, account number, or standing token at any point. The only thing that can move money is request_payment, and it only ever hands back something single-use.

Connecting a real MCP client

The connection guide at pinkwallet.com/agentic/developers documents the server URL as https://agentic-sandbox.pinkwallet.com/mcp, with the agent key sent either as Authorization: Bearer <agent_key> or embedded directly in the path as .../mcp/<agent_key>.

For Claude Code, the docs give this exact command:

claude mcp add --scope project --transport http pink \
  "https://agentic-sandbox.pinkwallet.com/mcp/<agent_key>"

For Claude Desktop and ChatGPT, the docs describe the GUI path rather than a config file: in Claude Desktop, Settings → Connectors → Add custom connector, then paste the same URL. In ChatGPT, Settings → Connectors → Create, paste the same URL, available on Plus, Pro, Business, and Enterprise plans with Developer mode turned on. The docs list 14 documented clients in total, including Claude Code, Claude.ai/Desktop, the Anthropic and OpenAI APIs, ChatGPT, Gemini CLI, Cursor, Windsurf, VS Code, Copilot Studio, LangChain, CrewAI, n8n, and "any MCP SDK." If a client isn't in that list, we're not claiming it works, remote MCP support varies enough between clients that it's worth checking the docs directly before assuming.

Three requests, three outcomes

With the Purchasing AI agent connected, we called pink.request_payment three times through the actual MCP tools/call interface.

$300 to Sysco, for a weekly milk and syrup restock, came back allowed:

{
  "decision": "allowed",
  "payee": "Sysco",
  "amount": 300,
  "rule": "Small supply orders go through",
  "credential": {
    "type": "virtual_card",
    "max_amount": 300,
    "locked_to": "Sysco",
    "single_use": true,
    "expires_at": "2026-10-24T16:53:59.971Z"
  }
}

That credential only authorizes $300 at Sysco and stops working in 15 minutes. The rule that let it through, "Small supply orders go through," caps anything on an approved payee at $500 per transaction for this agent.

$700 to Uline, for a bulk cup and lid order, came back pending_human:

{
  "decision": "pending_human",
  "payee": "Uline",
  "amount": 700,
  "rule": "Bigger supply orders: store manager checks",
  "hold_id": "pay_f0bbaf5ef3fc",
  "who": "Luis Ortega (Store manager)",
  "expires_at": "2026-10-24T17:09:00.224Z"
}

No credential, no card, nothing to spend. $500 to $2,000 on this account routes to a named human, Luis Ortega, the store manager. The agent's only move here is to call pink.get_credential with the hold_id and poll. We did, and before Luis acted, the poll returned the same pending_human state, the credential only appears in that response once a person actually approves it.

$50 to giftcards.com came back blocked, flat out, no polling possible:

{
  "decision": "blocked",
  "payee": "giftcards.com",
  "amount": 50,
  "rule": "Never: gift cards, cash-like, crypto",
  "credential": null
}

This one isn't a budget or approval question, it's a category block that applies to every agent on the account, no matter the amount. pink.list_rules shows it sitting first in the evaluation order, ahead of any dollar-amount rule, which matches how the engine works: the first matching rule wins, and a flat "never" rule for a payee category beats a dollar-threshold rule every time.

Why the model never touches the money

Across all three calls, the model's job was identical: describe the payment, call request_payment, read the decision. It never constructed a card number, never held a reusable credential, and never had standing access to pay anyone twice. The 15-minute expiry on the one approved credential means even if that JSON leaked somewhere downstream, it would already be dead by the time anyone could misuse it.

That's the actual answer to "can an MCP server let an AI send money": yes, but the interesting engineering isn't the MCP transport, plenty of servers can expose a pay() tool. The interesting part is what happens between the tool call and the money moving, a rule check that runs on every single request, decides allow, ask, or block, and only ever issues something single-use.

Try it

The sandbox above is free, uses test money only, and needs no signup: POST https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces?utm_source=devto&utm_medium=article&utm_campaign=mcp-server-send-money spins up a new company with its own agents, rules, and payees in one call. Full docs: pinkwallet.com/agentic/developers. Production access is early access only right now, reach out through the docs site if you want in.

What's the Best Way to Give AI Agents Controlled Spending Authority?

Quinn — Sun, 25 Oct 2026 14:00:43 +0000

Update, 2026-10-28: Pink Agentic AI Payments is now live in production as a decision layer: your agent asks Pink before each payment, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. Anything below that says early access or test money describes the free public sandbox, which still runs on test money. Production pilot on your own tenant: $99/month, pinkwallet.com/agentic/pilot.

A Marketing AI agent's second ad purchase of the day, $150, landed as pending_human in front of the store owner about one second after its first $220 ad purchase cleared automatically. Same agent, same API key, same rule, the only difference was that the two spends together crossed a $300-a-day line.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet.

Short answer: give each AI agent the same kind of layered spending authority you'd give an employee with a corporate card: a monthly budget, a per-payment cap, a daily window that catches cumulative drift, an approval band for anything bigger, and a hard block on categories that should never be self-service. Pink Agentic AI Payments checks every one of those limits on the server, before a payment executes, so the limits hold even if the agent's own context has no memory of what it already spent today. Here's that model, run live against a sandbox.

Borrow the model you already trust: employee spend authority

Companies don't give employees unlimited corporate cards, and they don't rely on employees self-reporting their own spending either. They give a card with a limit, a manager who sees the statement, and a policy for what's never reimbursable. The same five levers work for an AI agent, and they map directly onto this rule engine:

Per-agent budget: a hard monthly ceiling, like a department budget.
Per-payment cap: no single transaction above X, regardless of what's left in the month. In Pink this is an amount rule with window tx.
Daily window: catches an agent that stays under its per-payment cap but fires off many small payments in one day.
Approval band: amounts above a threshold route to a named human instead of executing.
Blocked categories: gift cards, crypto, personal purchases, never allowed, no approval path, no exceptions.

Step 1: a workspace with that authority already assigned per agent

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces?utm_source=devto&utm_medium=article&utm_campaign=ai-agent-spending-authority" \
  -H 'content-type: application/json' \
  -d '{"company":"Bramble & Finch Roasters","email":"dev@brambleandfinch.example","template":"coffee"}'

Trimmed real response:

{
  "workspace_id": "9vmbv7tb8n",
  "name": "Bramble & Finch Roasters",
  "template": "coffee",
  "agents": [
    { "id": "a_purch", "name": "Purchasing AI", "monthly_budget": 4000, "per_payment_cap": 500 },
    { "id": "a_inv", "name": "Inventory AI", "monthly_budget": 2500, "per_payment_cap": 300 },
    { "id": "a_mkt", "name": "Marketing AI", "monthly_budget": 3000, "per_payment_cap": 300 },
    { "id": "a_pay", "name": "Payroll & Bills AI", "monthly_budget": 32000, "per_payment_cap": 15000 }
  ],
  "rules": 11
}

Four agents, four different budgets and caps, sized for what each one actually does. Payroll's agent can move far more per payment than marketing's, because its job is to pay a fixed vendor on schedule, not to improvise.

Step 2: set the budget and cap for one agent explicitly

curl -s -X PATCH "https://agentic-sandbox.pinkwallet.com/v1/admin/agents/a_mkt" \
  -H "authorization: Bearer $ADMIN" -H 'content-type: application/json' \
  -d '{"monthly":3500,"perPay":300}'

{
  "id": "a_mkt", "name": "Marketing AI", "dept": "Marketing", "owner": "owner",
  "monthly": 3500, "perPay": 300, "spentMonth": 2060, "spentToday": 220, "status": "active"
}

monthly and perPay are the only two fields this PATCH call takes. monthly is checked before every payment. perPay is shown to the agent as single_payment_cap, but in the current sandbox the engine doesn't enforce that field on its own, so a hard per-payment limit is an amount rule with window tx. There's no hourly budget in this engine, only transaction, daily, and monthly windows, and the daily one is where most real drift gets caught.

Step 3: the daily window is what catches cumulative drift, not just one big payment

The rule table for this agent has a matched pair:

Rule	Payee	Amount	Window	Action
Ads up to $300 a day	cat:ads	$0–$300	`day`	`allow`
Ads above $300 a day: ask the owner	cat:ads	$300+	`day`	`ask` → Maya Chen (Owner)

Neither rule looks at a single payment in isolation. The day window is the agent's total spend for the day across all its payments, including this one, compared against the line. The payee scope (cat:ads) decides whether the rule applies at all; it doesn't narrow the running total to ads only.

First ad spend, well under the line:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $MKT" \
  -H 'content-type: application/json' \
  -d '{"payee_id":"p_meta","amount":220,"purpose":"Instagram ad boost, morning promo"}'

{ "decision": "allowed", "rule": "Ads up to $300 a day", "credential": { "max_amount": 220, "locked_to": "Meta Ads" } }

Second ad spend, same day, same agent, same rule pair:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $MKT" \
  -H 'content-type: application/json' \
  -d '{"payee_id":"p_meta","amount":150,"purpose":"Instagram ad boost, afternoon top-up"}'

{
  "decision": "pending_human",
  "rule": "Ads above $300 a day: ask the owner",
  "hold_id": "pay_50bbb7ea049b",
  "who": "Maya Chen (Owner)",
  "approvers_needed": 1,
  "expires_at": "2026-10-20T12:59:25.026Z"
}

$220 plus $150 is $370, over the $300 line, so the second request held instead of executing. The agent never had to track its own running total. One nuance worth knowing: after this hold, the agent's spentToday field still read $220, not $370, because a pending_human payment hasn't actually moved money yet. It only counts toward the window once it's approved.

Step 4: a human approves, with the admin key, not the agent's own key

Approving a hold is a real admin-key call: POST /v1/admin/requests/{hold_id}/approve with {"by": "<approver name>"}. This step reproduces the $220 allowed / $150 pending_human pair in a fresh coffee-template workspace (company "Thistle & Oak Roasters," workspace_id t91ic75cpd) to show the approval closing the loop end to end.

The owner approves the held $150 with the admin key, the same key behind the approvals console:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/admin/requests/pay_7b5fcf234bea/approve" \
  -H "authorization: Bearer $ADMIN" -H 'content-type: application/json' \
  -d '{"by":"Maya Chen"}'

{
  "payment_id": "pay_7b5fcf234bea",
  "decision": "approved",
  "amount": 150,
  "rule": "Ads above $300 a day: ask the owner",
  "credential": { "type": "virtual_card", "max_amount": 150, "locked_to": "Meta Ads", "single_use": true },
  "approved_by": ["Maya Chen"]
}

The agent's own key can't take that same action on its own behalf. Calling the identical endpoint with the Marketing AI agent's key instead of the admin key gets rejected outright:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/admin/requests/pay_7b5fcf234bea/approve" \
  -H "authorization: Bearer $MKT" -H 'content-type: application/json' \
  -d '{"by":"Maya Chen"}'

{ "error": "unknown route for an agent key" }

After approval, the agent's own key can still read the resolved state and the now-issued credential with GET /v1/payments/{id}:

{
  "payment_id": "pay_7b5fcf234bea",
  "decision": "approved",
  "amount": 150,
  "credential": { "type": "virtual_card", "max_amount": 150, "locked_to": "Meta Ads", "single_use": true },
  "approved_by": ["Maya Chen"]
}

And the agent's spentToday only moves once the hold clears: it read $220 right after the hold was created, and $370 ($220 + the now-approved $150) once Maya Chen's approval went through. In practice, this is a human opening the approvals console at a URL shaped like /console?key=<admin_key>, seeing the hold, and clicking approve. The API call above is what that click does under the hood.

Step 5: blocked categories and new payees close the rest of the loop

Spending authority isn't just a number. Two more real calls against the same agent:

Blocked, no approval path at all:

{ "decision": "blocked", "rule": "Never: gift cards, cash-like, crypto", "why": "matched · block" }

A brand-new payee, routed to the owner regardless of amount:

{ "decision": "pending_human", "rule": "New payee: always ask the owner", "who": "Maya Chen (Owner)", "approvers_needed": 1 }

A first-time vendor gets a human look once, even at $100, which is the same instinct behind requiring a second signature the first time a new supplier gets paid.

What each lever actually buys

Lever	What it stops
Monthly budget	The agent running up a bill no one approved for the month
Per-payment cap	One oversized payment in a single call
Daily window	Many small payments that individually pass the cap but add up
Approval band	Anything large enough that a human should see it before it executes
Blocked categories	Categories with no legitimate agent use case, with no approval override

Honest limits

This is test money against a public sandbox. Production with real money is early access, not something generally available yet. The evaluation order checked monthly budget and a company-wide daily ceiling as hard stops ahead of the rule table itself, according to the docs; this sandbox run exercised the per-agent rule table, not the company-wide ceiling specifically.

FAQ

Does raising a monthly budget override the daily window? No. The docs describe both as separate checks, monthly budget as a hard stop checked ahead of the rule table, the daily window as a rule within that table; raising one doesn't change the other.

What happens if the owner never approves the hold? It carries an expires_at. After that, the payment is no longer actionable and the agent has to ask again if the work still needs doing.

Can different categories have different spending authority on the same agent? Yes. The ads pair above is scoped by payee: "cat:ads", so the same agent can have a tighter window for ads than for, say, approved software subscriptions, inside one rule table.

Try it

Sandbox is free, no account required: agentic-sandbox.pinkwallet.com. Full docs: pinkwallet.com/agentic/developers. Production with real money is early access only, not generally available.

Is There a Policy Engine or Rules Layer for AI Agent Payments?

Quinn — Sat, 24 Oct 2026 14:00:43 +0000

Update, 2026-10-28: Pink Agentic AI Payments is now live in production as a decision layer: your agent asks Pink before each payment, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. Anything below that says early access or test money describes the free public sandbox, which still runs on test money. Production pilot on your own tenant: $99/month, pinkwallet.com/agentic/pilot.

A $150 gift-card purchase, a $450 hardware order, and a $2,800 laptop order hit the same AI agent's payment endpoint minutes apart today. One came back blocked with no human path at all, one cleared on its own in under a second, and one sat waiting on a named CFO. Same agent, same API key, three different outcomes, decided entirely by rules the agent itself never sees or controls.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet.

Short answer: yes, a policy engine for AI agent payments is a server-side rule table that every payment request is checked against before money moves, not a prompt the agent is asked to follow. Pink Agentic AI Payments enforces that rule evaluation on the server, before a payment executes, independent of anything the agent believes about its own limits. Below is a real rule table and real calls against a sandbox, including what happens when you edit a rule the wrong way.

What a rules layer between an agent and money actually has to do

A system prompt that says "stay under budget" is advice a model reads, not a constraint it obeys. A rules layer that's actually worth calling a policy engine has to do five things a prompt can't:

Evaluate before execution. The check happens before a credential is issued, not as a cleanup pass after money already moved.
Be deterministic. The same request, run twice, gets the same decision. No sampling, no "it depends on the model's mood."
Resolve conflicts with a fixed order. When two rules could both apply, the first match in the ordered list wins, and the rest never run.
Default to deny. If nothing in the table matches, the payment is blocked, not allowed by omission.
Say why. A human (or the agent) can see which named rule fired, not just "no."

That's the shape of the engine behind Pink Agentic AI Payments. Here's what it looks like with real traffic against it.

Step 1: a workspace with a real rule table already in it

No signup required:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces?utm_source=devto&utm_medium=article&utm_campaign=policy-engine-rules" \
  -H 'content-type: application/json' \
  -d '{"company":"Harbor Metrics","email":"dev@harbor-metrics.example","template":"startup"}'

Trimmed real response:

{
  "workspace_id": "8qc0ijqupz",
  "name": "Harbor Metrics",
  "template": "startup",
  "policy_version": 1,
  "agents": [
    { "id": "a_eng", "name": "Eng Infra AI", "monthly_budget": 25000, "per_payment_cap": 1000 }
  ],
  "rules": 17
}

This seeds 6 agents and 17 rules. An agent reads its own rule table with its own key:

curl -s "https://agentic-sandbox.pinkwallet.com/v1/rules" -H "authorization: Bearer $ENG"

That returns 11 rules scoped to the Eng Infra AI agent (some of the 17 only apply to other agents, like design or recruiting). A few of the ones that matter here:

Rule	Payee	Amount	Window	Action
Never: gift cards, crypto, personal shopping	blocked category	any	tx	`block`
Known vendors under $1,000	approved	$0–$1,000	tx	`allow`
$1,000–$5,000: CFO approves	approved	$1,000–$5,000	tx	`ask` → Sarah Kim (CFO)
Over $5,000: 2 of 3 leadership	any	$5,000+	tx	`ask` → 2 of 3 named leaders
Duplicate invoice number within 90 days: blocked	any	any	tx	`block`

Rules are checked in order, first match wins. The gift-card block sits ahead of everything else in this table, so a gift-card purchase never gets a chance to match a friendlier rule further down.

Step 2: three requests, three outcomes, same agent

Allowed ($450 to an approved vendor, under the $1,000 line):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' \
  -d '{"payee_id":"p_dell","amount":450,"purpose":"replacement laptop dock"}'

{
  "decision": "allowed",
  "rule": "Known vendors under $1,000",
  "policy_version": 1,
  "credential": {
    "type": "bank_transfer", "max_amount": 450, "locked_to": "Dell", "single_use": true,
    "transfer": { "rail": "ACH", "reference": "PWS-1C5B8C68", "status": "submitted" }
  }
}

pending_human ($2,800, inside the $1,000–$5,000 band):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' \
  -d '{"payee_id":"p_dell","amount":2800,"purpose":"3 replacement laptops for new hires"}'

{
  "decision": "pending_human",
  "rule": "$1,000–$5,000: CFO approves",
  "hold_id": "pay_f858f5e00691",
  "who": "Sarah Kim (CFO)",
  "approvers_needed": 1,
  "expires_at": "2026-10-20T12:57:21.518Z"
}

blocked, with a reason (gift cards, no human path regardless of amount):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' \
  -d '{"payee_name":"giftcards.com","amount":150,"purpose":"team swag gift cards"}'

{
  "decision": "blocked",
  "rule": "Never: gift cards, crypto, personal shopping",
  "credential": null,
  "why": "matched · block"
}

That why field is the audit trail. The agent (or a human reading logs later) gets a named rule, not a bare rejection. Every decision also carries a policy_version, so a payment made under last week's rules stays attributable to last week's rules even after the table changes.

Step 3: editing a rule the right way

PUT /v1/admin/rules replaces the entire ordered list, not just the rule you're touching, so the source of truth for any edit has to be the full table, not one agent's view of it. This step uses a fresh sandbox workspace (company "Fernbank Logistics," workspace_id y3edzx3as7, same startup template as Step 1, so it also seeds 17 rules) to show the correct workflow end to end.

First, pull the full company-wide rule table with the admin key, not the agent key:

curl -s "https://agentic-sandbox.pinkwallet.com/v1/admin/state" -H "authorization: Bearer $ADMIN"

The rules array in that response is the full ordered table, all 17 rules, including the ones scoped to other agents. That's different from GET /v1/rules with an agent key, which only returns the subset that applies to the calling agent (11 of the 17, for Eng Infra AI), because it's a per-agent view, not the company's live policy. Starting a PUT from that narrower view would silently drop every rule that applies only to other agents.

With the full table in hand, I raised the ceiling on one rule, Known vendors under $1,000, from max: 1000 to max: 1200, kept the other 16 rules and the order unchanged, and PUT the whole list back:

curl -s -X PUT "https://agentic-sandbox.pinkwallet.com/v1/admin/rules" \
  -H "authorization: Bearer $ADMIN" -H 'content-type: application/json' \
  -d '{"rules": [...all 17 rules, r12 with max 1200...], "by": "dev@fernbank-logistics.example"}'

One schema detail that will save you a failed request: GET /v1/admin/state returns each rule's limits nested under amount ({"min", "max", "window"}), but PUT /v1/admin/rules expects min, max and window as top-level fields on each rule. Sending the GET shape unchanged returns {"error": "each rule needs id, name, action, window"}, so flatten amount before the PUT.

{ "policy_version": 2, "rules": 17 }

Policy version ticked up to 2, and the rule count held at 17, because the edit started from the full table instead of a filtered one.

The edit itself took effect immediately:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' \
  -d '{"payee_id":"p_dell","amount":1100,"purpose":"replacement laptops for new hires"}'

{
  "decision": "allowed",
  "rule": "Known vendors under $1,000",
  "policy_version": 2,
  "credential": { "max_amount": 1100, "locked_to": "Dell", "single_use": true }
}

A $1,100 payment to the same vendor, which would have landed as pending_human under the old $1,000 ceiling, now auto-allows under the raised one, and the response's policy_version: 2 ties that decision to the edited table. No redeploy, no change to the agent's prompt or code. The one rule that matters here: always build a PUT from the full table GET /v1/admin/state returns, never from a single agent's filtered GET /v1/rules.

What each decision actually means

Decision	Who acts	What happens next
`allowed`	Nobody	A single-use credential locked to that payee and amount is issued immediately
`pending_human`	A named approver (or N of a named group)	The payment sits as a hold with an `expires_at`; nothing moves until that person approves
`blocked`	Nobody; there's no approve path	The agent gets `why` naming the rule that matched, and the payment never exists

Honest limits

This is test money against a public sandbox, not production. Production with real money is early access, not something generally available yet. The rule engine checks amount, payee, category, and time window; it does not independently verify a self-asserted claim like a stated PO number, only whether one was attached.

FAQ

Can the agent talk its way past a rule? No. The check runs server-side before a credential is issued; nothing the agent says in its own context changes what the server evaluates against.

What happens when two rules could both match? The first match in the ordered list wins and nothing below it is evaluated for that request, which is why the blocked-categories rule sits at the top of this table.

Does the engine support a dry run before actually submitting a payment? The API documents a POST /v1/payments/check route for exactly that; this article only exercised live /v1/payments calls, so no response from that route is shown here.

Try it

Sandbox is free, no account required: agentic-sandbox.pinkwallet.com. Full docs: pinkwallet.com/agentic/developers. Production with real money is early access only, not generally available.

Agentic Commerce Market Map 2026: Payments Layer Players

Quinn — Fri, 23 Oct 2026 14:00:44 +0000

Update, 2026-10-28: Pink Agentic AI Payments is now live in production as a decision layer: your agent asks Pink before each payment, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. Anything below that says early access or test money describes the free public sandbox, which still runs on test money. Production pilot on your own tenant: $99/month, pinkwallet.com/agentic/pilot.

Disclosure: I work on Pink Agentic AI Payments.

Last checked: 2026-10-20.

The payments layer of agentic commerce splits into five segments: open protocols that standardize how an agent and a merchant talk (x402, AP2, ACP, and the transport layer MCP), agent wallets and accounts that give an agent an identity and a way to hold or spend money, card and network programs that let an agent spend through existing card rails, stablecoin rails for on-chain settlement, and a spend-control (policy) layer that decides what an agent is allowed to do before any of the above executes a payment. Pink Agentic AI Payments, a new product from PinkWallet, is in that last segment.

If you are an investor or researcher building a market map for agentic commerce, the segment that gets skipped most often is spend control. Protocols and wallets get the press. The layer that enforces a company's actual rules, caps, allow-lists, who has to approve what, is smaller and newer, and this post is about where it sits and who else is in it.

Pink Agentic AI Payments (by PinkWallet) sits in the spend-control layer: it enforces per-agent caps, payee allow-lists and human-approval thresholds at the MCP/API layer, before a payment executes.

The map

Every player below has a public page I opened today (2026-10-20) describing what it does in its own words. No scoring, no "best," no "leader." Protocol names are neutral by nature; vendor names are listed because they publish a live product page, not because of any ranking.

Segment	What it does	Example players	Source
Protocols	Standardize how an agent and a merchant or server exchange payment instructions	x402, AP2, ACP, MCP	x402.org, ap2-protocol.org, agenticcommerce.dev, modelcontextprotocol.io
Agent wallets / accounts	Give an agent a verifiable identity and a wallet or account it can spend from	Skyfire, Payman	skyfire.xyz, paymanai.com
Card / network programs	Let an agent spend through an existing card network	Visa Intelligent Commerce, Mastercard Agent Pay	visa.com, thepaypers.com coverage of Mastercard's announcement
Stablecoin rails	Provide on-chain, programmable dollar settlement an agent can move without a bank intermediary	USDC (Circle)	circle.com/en/usdc
Spend-control / policy layer	Enforces what an agent is allowed to pay for: caps, allow-lists, approval thresholds, before the payment reaches a rail	Pink Agentic AI Payments (by PinkWallet)	pinkwallet.com/agentic, agentic-sandbox.pinkwallet.com

A couple of notes on how this table was built. x402 describes itself as an open, blockchain-agnostic standard for payments made directly over HTTP 402 responses, aimed at machine and agent use. AP2, from Google, focuses on authorization and authenticity for agent-to-merchant purchases using verifiable credentials. ACP, published jointly by Stripe and OpenAI under Apache 2.0, standardizes agentic checkout flows while keeping payment credential handling with the merchant. MCP, from Anthropic, is not a payments protocol; it is the transport standard most of these tools use to connect an AI application to external systems, including payment APIs, so it belongs in the map as infrastructure rather than as a payments protocol itself.

Pink's part of the map: the spend-control layer

Pink Agentic AI Payments is an MCP server plus a REST API that any AI agent can call to request a payment, paired with an admin console where a company sets the rules. The rules an admin can set today, confirmed against the sandbox source code: per-agent caps per payment, per day and per month, payee allow-lists, and human-approval thresholds with a configurable approver group. The default for any payment that matches no rule is block.

Here is a real call against the public sandbox, not a mockup. I created a workspace, set one rule (Marketing AI agent, any payee, allow up to 100 USD per payment), then tried a 150 USD payment against it.

Request:

POST /v1/payments
Authorization: Bearer <agent key>
{
  "payee_name": "New Ad Vendor LLC",
  "amount": 150,
  "currency": "USD",
  "purpose": "Sponsored post boost"
}

Response:

{
  "payment_id": "pay_1edc7b6a4fbf",
  "decision": "blocked",
  "agent": "Marketing AI",
  "payee": "New Ad Vendor LLC",
  "amount": 150,
  "currency": "USD",
  "rule": "No rule allows this payment",
  "credential": null,
  "why": "default is block"
}

An 80 USD request against the same rule came back allowed, with a single-use sandbox virtual card capped at exactly that amount, locked to that payee, expiring in 15 minutes. That is the shape of the control: the agent never holds a standing payment credential, it gets a scoped one only after a payment clears policy. You can reproduce both calls in a few minutes with a free test workspace at agentic-sandbox.pinkwallet.com, or click through the no-signup demo at agentic-sandbox.pinkwallet.com/demo.

Two mechanics worth checking in any spend-control product, shown here as Pink behaves: in Pink, a day or month window on a rule counts the agent's total spend in that window, not spend broken out by merchant category, so one day-window rule caps the agent's whole day across any mix of payments. And in Pink, approving one over-threshold payment does not automatically add that payee to a permanent allow-list; the next payment to the same new payee is evaluated against the policy again.

What is not yet decided and should not be assumed from this post: which settlement rail Pink runs on (stablecoin, fiat, or card), pricing, or production availability for real money. The sandbox at agentic-sandbox.pinkwallet.com runs on test funds only. Early access for companies wanting a design-partner conversation is at pinkwallet.com/agentic.

How to read this map

For protocols, check whether the spec defines payment authorization only, or also identity and dispute handling; AP2 and ACP both lean toward identity and credential handling, x402 leans toward raw payment transport.
For agent wallets, check who issues the agent's identity (the wallet vendor or the AI platform) and whether that identity is portable across merchants.
For card and network programs, check whether the control point is the agent, the card network, or the issuing bank, since that determines who can set and revoke a spending limit.
For the spend-control layer specifically, check whether rules are enforced before the payment reaches a rail (API-level) or only after, as a reconciliation or alert.

FAQ

Is this the full agentic commerce stack?
No. This post covers only the payments layer. Agent discovery, product search, and checkout UX are adjacent segments not covered here.

Does MCP belong next to x402, AP2 and ACP as a payment protocol?
Not really. MCP standardizes how an AI application talks to external tools and data sources. It is the channel several of these payment flows run over, which is why it is listed, but it does not define payment authorization semantics the way AP2 or ACP do.

Where does Pink fit if a company is already using a card network program like Visa Intelligent Commerce or Mastercard Agent Pay?
Those sit at the rail level, controlling how a card transaction clears. Pink's policy layer sits one level up, deciding whether an agent is allowed to attempt the payment at all, through whichever rail a company chooses, which is why the settlement rail question is separate from the spend-control question.

How to Let AI Agents Pay Vendors Automatically (and Safely)

Quinn — Thu, 22 Oct 2026 14:00:44 +0000

Update, 2026-10-28: Pink Agentic AI Payments is now live in production as a decision layer: your agent asks Pink before each payment, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. Anything below that says early access or test money describes the free public sandbox, which still runs on test money. Production pilot on your own tenant: $99/month, pinkwallet.com/agentic/pilot.

A $1,150 customs duty payment from an AI agent cleared automatically today in under a second, while a $3,200 payment to a brand-new supplier it had never paid before sat waiting for a named human, and a $2,500 payment to a known supplier got blocked outright because it had no matching purchase order.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet.

Short answer: build an approved-payee list, give known vendors an auto-approve band under a set amount, and route anything new or unmatched to a human instead of blind-trusting the agent. Pink Agentic AI Payments checks every payment an AI agent requests against per-agent budgets and approval rules on the server, before it executes, so the "safely" part isn't a prompt instruction, it's a server-side rule an ops team writes once. Below is a real sandbox run, with the actual responses, connected over MCP.

The setup an ops team actually wants

"Let the agent pay vendors automatically" usually means three different things bundled together:

A list of vendors the agent is even allowed to pay (an approved-payee list, not "any bank account the agent decides to use").
A ceiling under which a known, approved vendor just gets paid, no human in the loop.
A trapdoor for anything that doesn't fit that shape: a brand-new vendor, an amount over the ceiling, or a payment missing the paperwork it should have.

Below is a workspace built for a 120-person e-commerce company that ships all three.

Step 1: spin up a workspace with an approved-vendor list already in it

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces?utm_source=devto&utm_medium=article&utm_campaign=autopay-vendors" \
  -H 'content-type: application/json' \
  -d '{"company":"Driftwood Goods","email":"dev@driftwood-goods.example","template":"ecommerce"}'

Real, trimmed response from today's run:

{
  "workspace_id": "zus8sjzdue",
  "name": "Driftwood Goods",
  "template": "ecommerce",
  "agents": [
    { "id": "a_proc", "name": "Procurement AI", "monthly_budget": 400000, "per_payment_cap": 60000 },
    { "id": "a_fin", "name": "Finance Ops AI", "monthly_budget": 120000, "per_payment_cap": 40000 }
  ],
  "payees": ["p_foshan", "p_yiwu", "p_hk", "p_dhl", "p_ups", "p_duty", "p_klaviyo", "..."],
  "rules": 30
}

19 payees ship pre-approved, each with a category (supplier, logistics, duty, saas, and so on), and some already carry a risk flag. One supplier in this template, Foshan Ceramics Co., ships with "risk_flags": ["payeeChanged"] because its bank details changed 3 days ago, which on its own routes any payment to that payee to a human rather than letting the amount decide.

Step 2: the auto-approve band for a known, small payment

Not every rule in this template needs a human. Customs duties under $3,000 to the approved duty payee clear on their own:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $FIN" \
  -H 'content-type: application/json' -d '{"payee_id":"p_duty","amount":1150,"purpose":"import duty, October container"}'

Real response:

{
  "decision": "allowed", "rule": "Customs duties and taxes up to $3,000: automatic",
  "credential": { "type": "bank_transfer", "max_amount": 1150, "locked_to": "DHL Duties & Taxes",
    "single_use": true, "transfer": { "rail": "ACH", "reference": "PWS-6E770BCF", "status": "submitted" } }
}

That credential is single-use and locked to this exact payee and amount; it's issued only after the rule matched, and it can't be reused for a different payee or a larger amount.

Step 3: a hold for a vendor the agent has never paid before

The same workspace's Procurement AI agent has its own rule for anything new:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $PROC" \
  -H 'content-type: application/json' -d '{"payee_name":"Guangzhou Zipper Factory","amount":3200,"purpose":"first order, new zipper supplier"}'

Real response:

{
  "decision": "pending_human", "rule": "New supplier: first payment up to $5,000, CFO approves",
  "hold_id": "pay_0c1906fcba25", "who": "Wei Lim (CFO)", "approvers_needed": 1,
  "expires_at": "2026-10-20T06:06:39.691Z"
}

A vendor that isn't on the approved list yet, even for a first order under the normal CFO band, waits for a named person. Approving that first payment doesn't add the vendor to the approved list by itself: the approved-payee list is something the company maintains, and only payees on it can match the auto-approve bands for known vendors.

Step 4: a block for a known vendor missing its paperwork

The same Procurement AI agent also carries a rule that any payment to an approved supplier without a matching purchase order gets blocked outright, not held, not asked:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $PROC" \
  -H 'content-type: application/json' -d '{"payee_id":"p_yiwu","amount":2500,"purpose":"rush order, PO not issued yet"}'

Real response:

{ "decision": "blocked", "rule": "Supplier payment without a matching PO: blocked", "credential": null, "why": "matched · block" }

This is a good one to test against your own setup before you trust an auto-approve band blindly: in this template, that rule is checked ahead of the small-reorder auto-approve rule for this agent, so a known vendor with a missing PO gets blocked rather than quietly clearing under the small-amount band. Rule order matters as much as the rule itself.

Step 5: connect the agent over MCP or REST

MCP, no OAuth flow needed in the sandbox:

{
  "mcpServers": {
    "pink": {
      "command": "npx",
      "args": ["-y", "pink-agentic-payments-mcp"],
      "env": { "PINK_AGENT_KEY": "pk_sandbox_agent_<your_key>" }
    }
  }
}

Or call the REST API directly, which is what every example above does. Python and n8n integrations exist too (pip install langchain-pink, and an n8n node), for teams that would rather wire this into an existing agent framework than write raw HTTP calls.

What to decide before turning this on

Decision	Where it lives	What happens if you skip it
Which vendors the agent can pay at all	The approved-payee list	Any payee name the agent sends gets treated as new, routing almost everything to a human
The ceiling for auto-approve on known vendors	A rule with an `amount.max` and `action: allow`	Every payment, even a $20 recurring charge, needs a human
What counts as "new" or "risky" enough to hold	`payee: "new"` rules, and risk flags like a recently changed bank detail	A compromised or swapped payee account gets paid without anyone noticing
What paperwork a payment needs before it clears	`requires` fields like a purchase order match	An agent can pay an approved vendor for something nobody ordered

Honest limits of this sandbox

This is test money against a sandbox at agentic-sandbox.pinkwallet.com, not production; production with real money is early access right now. The engine checks the conditions you write into a rule, like amount, payee, category, and whether a flag like a purchase order was attached; it does not independently verify that a stated PO number is real, only that one was or wasn't provided. And because rules are evaluated in order, first match wins, a broad rule placed above a narrower one will shadow it, which is exactly what happened with the blocked payment above.

FAQ

Can the agent still pay a vendor that's not on the approved list? Not without a rule for it. A payment to an unlisted payee name matches a payee: "new" rule if one exists; without one, the request has no rule to route through.

What does the agent get back when a payment is held, not blocked? A hold_id, the named approver (or group), and an expires_at. The agent can poll for the outcome; the credential only exists after a human approves.

Does connecting over MCP change which rules apply? No. MCP and REST hit the same server-side rule engine; the transport changes, the check doesn't.

Try it

Sandbox is free, no account required: agentic-sandbox.pinkwallet.com. Full API and rules reference: pinkwallet.com/agentic/developers. Security model: pinkwallet.com/agentic/developers/security-model. Production with real money is early access: join the waitlist.

How Can a Finance Team Cap and Approve What AI Agents Spend?

Quinn — Wed, 21 Oct 2026 14:03:33 +0000

Update, 2026-10-28: Pink Agentic AI Payments is now live in production as a decision layer: your agent asks Pink before each payment, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. Anything below that says early access or test money describes the free public sandbox, which still runs on test money. Production pilot on your own tenant: $99/month, pinkwallet.com/agentic/pilot.

A $7,500 server hardware order from an AI agent sat as pending_human today, routed to two named executives before any money could move, while a $450 order from the same agent cleared on its own in under a second.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet.

Short answer: give each AI agent a monthly budget and a per-payment cap, then layer amount bands on top that route to a specific named human instead of executing. Pink Agentic AI Payments checks every payment an AI agent requests against per-agent budgets and approval rules on the server, before it executes, and a finance team edits those rules from a console without touching the agent's code. Below is a real run against a sandbox workspace, with the actual responses.

Why "ask the agent nicely" doesn't satisfy a controller

A system prompt that says "stay under $5,000 a month" is advice the model reads, not a constraint it obeys. Nothing stops a long conversation, a bad retry loop, or a crafted tool response from drifting past it, and the agent's own context window has no memory of what finance actually approved. A finance team needs the check to live somewhere the agent cannot talk its way around: on the server, evaluated before the payment executes, independent of whatever the agent currently believes its budget is.

Step 1: spin up a workspace with real rules already in it

No signup required to test this:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces?utm_source=devto&utm_medium=article&utm_campaign=finance-cap-approve" \
  -H 'content-type: application/json' \
  -d '{"company":"Nimbus Analytics","email":"dev@nimbus-analytics.example","template":"startup"}'

This template seeds a 50-person software company with 6 agents and 17 rules. Trimmed real response from today's run:

{
  "workspace_id": "1iwi11zcgy",
  "name": "Nimbus Analytics",
  "template": "startup",
  "agents": [
    { "id": "a_eng", "name": "Eng Infra AI", "monthly_budget": 25000, "per_payment_cap": 1000 }
  ],
  "rules": 17
}

A finance team gets a console link in the same response (urls.console) where a person can review and edit the rule set without redeploying the agent.

Step 2: set the monthly budget and per-payment cap

One PATCH call on the admin route changes both numbers for a single agent:

curl -s -X PATCH "https://agentic-sandbox.pinkwallet.com/v1/admin/agents/a_eng" \
  -H "authorization: Bearer $ADMIN" -H 'content-type: application/json' \
  -d '{"monthly":30000,"perPay":1500}'

Real response:

{
  "id": "a_eng", "name": "Eng Infra AI", "dept": "Engineering", "owner": "cto",
  "monthly": 30000, "perPay": 1500, "spentMonth": 17840, "status": "active", "trust": 95
}

monthly is this agent's hard ceiling for the current month. perPay caps any single payment regardless of what's left in the month. Both are checked before a payment is created. The spending windows in this engine are per-transaction, daily, and monthly only, which keeps the rule set small enough for a controller to actually read.

Step 3: amount bands route to a named human, not a queue

The template's rule set has three bands stacked on top of each other for this agent, first match wins:

Under $1,000, an approved payee: allow automatically.
$1,000 to $5,000, an approved payee: ask, routed to "Sarah Kim (CFO)" by name.
Over $5,000, any payee: ask, routed to "2 of 3 in Leadership (Daniel Park, Sarah Kim, Omar Haddad)", meaning two of those three specific people have to sign off, not just one.

Gift cards, crypto, and personal shopping are a separate block rule with no human path at all, evaluated ahead of the amount bands so a gift-card purchase never lands in anyone's queue.

Step 4: four payments, four outcomes, run today

Same agent, same rule set, different amounts and payees against the sandbox at agentic-sandbox.pinkwallet.com. Real, trimmed responses:

Allowed ($450, hardware accessory, under the $1,000 band):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' -d '{"payee_id":"p_dell","amount":450,"purpose":"replacement laptop dock + accessories"}'

{
  "decision": "allowed", "rule": "Known vendors under $1,000",
  "credential": { "type": "bank_transfer", "max_amount": 450, "locked_to": "Dell", "single_use": true,
    "transfer": { "rail": "ACH", "reference": "PWS-39C7198F", "status": "submitted" } }
}

pending_human, CFO tier ($2,800, inside the $1,000-$5,000 band):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' -d '{"payee_id":"p_dell","amount":2800,"purpose":"3 replacement laptops for new hires"}'

{
  "decision": "pending_human", "rule": "$1,000-$5,000: CFO approves",
  "hold_id": "pay_f6c2b2fbe109", "who": "Sarah Kim (CFO)", "approvers_needed": 1,
  "expires_at": "2026-10-20T06:06:11.468Z"
}

pending_human, leadership tier ($7,500, over the $5,000 line):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' -d '{"payee_id":"p_dell","amount":7500,"purpose":"server rack hardware refresh, 3 units"}'

{
  "decision": "pending_human", "rule": "Over $5,000: 2 of 3 leadership",
  "hold_id": "pay_3897fab2bb11", "who": "2 of 3 in Leadership (Daniel Park, Sarah Kim, Omar Haddad)",
  "approvers_needed": 2
}

Blocked (gift cards, any amount, no human path):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' -d '{"payee_name":"giftcards.com","amount":150,"purpose":"team swag gift cards"}'

{ "decision": "blocked", "rule": "Never: gift cards, crypto, personal shopping", "credential": null, "why": "matched · block" }

Note the field is why on a block, not reason. The two pending_human payments don't move money; a named person has to open the console and approve the hold before a credential is ever issued.

What a finance team actually sees

Decision	Who acts	What happens next
`allowed`	Nobody	A single-use credential is issued, locked to that payee and amount, and the agent completes the payment
`pending_human`	A named approver (or N of a named group)	The payment sits as a hold with an `expires_at`; nothing moves until that person approves in the console
`blocked`	Nobody; there's no approve path	The agent gets `why: "matched · block"` and the payment never exists

Every one of these decisions, plus who the approver was and when they acted, is tied to a payment_id and a policy_version, so a controller reviewing the month can see exactly which rule fired on every dollar and which version of the rule set was active when it did.

Honest limits of this sandbox

This is test money against a sandbox at agentic-sandbox.pinkwallet.com, not production. Production with real money is early access right now (waitlist linked below). The rule engine checks amount, payee, category, and time window; it does not independently verify self-asserted evidence like a stated invoice number, only that one was or wasn't attached. And the order rules are listed in matters: a narrower rule further down the list never fires if a broader one above it already matched.

FAQ

Can a finance team change the budget without redeploying the agent? Yes. The PATCH /v1/admin/agents/{id} call changes monthly and perPay immediately; the agent's code and prompt don't change.

What happens if nobody approves a pending_human payment in time? The hold carries an expires_at. After that, the payment is no longer actionable and the agent has to request it again if the work is still needed.

Does the agent know it got blocked because of a rule, or does it just fail silently? It gets a structured response with decision: "blocked" and a why field naming the rule that matched, so the agent (or a human reading its logs) can see exactly why.

Try it

Sandbox is free, no account required: agentic-sandbox.pinkwallet.com. Rules reference: pinkwallet.com/agentic/developers/policy-rules-reference. Production with real money is early access: join the waitlist.