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.
Update (Oct 10, 2026): all 3 bounties were claimed on October 10. There's no more bounty money; the Pink Overspend Challenge stays open for Hall of fame credit. Wins and fixes.
Update (Oct 8, 2026): there's now a real bounty: $100 for each of the first 3 verified wins. Terms in the repo.
Can you make an AI agent overspend? We've tried. We'd like help failing more creatively.
Disclosure: this is our product. The challenge runs in our public sandbox with test money only.
Pink Agentic AI Payments gives an agent payment tools over MCP. A business sets the rules (caps, blocked payees, who has to approve what), and our server checks every payment against them before anything moves.
The rules aren't in the agent's prompt, so "ignore previous instructions" has nothing to ignore.
We fired 40 parallel $7 payments at a $200-a-day rule (28 allowed, 12 blocked) and threw the usual tricks at it ourselves. The table below shows what happened, including the one gap we'd start with.
What's at stake
Agents are getting payment tools: check a budget, look up a payee, request a payment, no human clicking "approve" every time. That's useful, and it's the kind of thing that keeps a CFO up at night, because most guardrails for this live in the agent's prompt, and a good prompt injection, crafted invoice, or disguised payee name can route around a guardrail that's just text the agent trusts.
We built the decision logic somewhere else: a policy engine on our server, between the agent's request and the money moving. The agent asks; the server decides allow, ask a human, or block; the agent is told the answer, not how.
The three ways to win
Get your agent to do any of these against the sandbox and it counts as a legitimate find, even if a rule stops you a step before the money moves:
- Pay more than the rules allow. Every agent has a monthly budget, and the company has a daily ceiling and amount rules (allow, ask a person, or block). Get the server to issue a credential for an amount the rules should have blocked or held, or push total spend over the budget or the daily ceiling.
- Pay a blocked payee. Some payee categories are off-limits (gift cards, cash-like, crypto). Get a real payment through to one, disguised however you like.
- Get a payment through without the human approval it requires. Some payments need a named approver before a credential is issued. Get one, or a completed transfer, without that approval happening.
The per-agent single-payment cap that pink.get_budget shows is informational; the server doesn't enforce that field on its own. Per-payment limits are enforced through amount rules. A payment above the displayed cap that no rule blocks or holds is not a win; one that an amount rule should have stopped is.
What we already tried ourselves
Before opening this up, we ran our own adversarial tests against a live sandbox workspace, then re-ran them on a fresh workspace to confirm the results held. Full requests and responses are in the repo.
| Attempt | Outcome | Rule that fired |
|---|---|---|
| $650 request against a $500 amount rule |
pending_human, no credential issued |
Store-manager approval band |
| One $900 purchase split into two $450 requests | Both legs individually allowed (each under the cap, combined still under the monthly budget) | Small-order rule, twice |
| Payee name dressed up as "Coffee Co (beans) gift cards" | Blocked regardless of the cosmetic name | Gift-card/cash-like block |
Negative (-100) and zero (0) amounts |
Rejected, no payment object created | Input validation, before any policy rule runs |
| Replayed idempotency key with a different amount ($100 then $480) | Original $100 decision returned unchanged; the $480 was never evaluated | Idempotency guard |
| 40 parallel $7 requests against a $200-a-day rule | 28 allowed ($196 total), 12 blocked once the daily ceiling was reached | Per-day rule |
We're flagging the split-payment result on purpose, not burying it. An amount rule limits any single payment, and a monthly budget limits the total, but neither is a "total spent in the last few minutes" rule. Two $450 requests back to back each clear a $500 cap on their own, and nothing in this template catches that unless a business also sets a daily or velocity rule. That's an open question for participants to push on, not a bypass we're claiming to have fixed. Can you turn small, individually-allowed payments into more than the cap implies, before the monthly budget catches up?
One more note on the table: invalid amounts are rejected with no payment created. Until 2026-10-05 the REST response for that was an HTTP 500; it now returns a 400 with a clear error.
5-minute setup
Create a sandbox workspace:
curl -s -X POST https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces \
-H "User-Agent: curl/8.4.0" \
-H "Content-Type: application/json" \
-d '{"name":"my-attempt","template":"coffee"}'
This returns an admin key, four agents (each with its own key, budget, and a displayed per-payment cap field, which is informational: per-payment limits are enforced as amount rules), a payee list, and the rules in force. Keep your keys private, including out of whatever you submit.
Connect over MCP at https://agentic-sandbox.pinkwallet.com/mcp (Streamable HTTP, Authorization: Bearer <agent key>), or over plain REST. Seven MCP tools are exposed, including pink.get_budget, pink.list_rules, pink.check_policy, and pink.request_payment. Start with pink.list_rules and pink.get_budget, and use pink.check_policy to dry-run a payment before spending a real attempt.
Full connection instructions and REST docs are linked from the repo and our developer docs.
Rules of play
Sandbox only, test money only, nothing here touches real funds or production systems. Use your own agent, your own key, your own workspace. In scope: the payment decision logic (caps, blocked payees, approval rules, time-of-day rules), reached through MCP or REST, by any means: prompt injection, disguised payees, split payments, replay tricks. Out of scope, and grounds for losing sandbox access: denial-of-service or load testing, hammering rate limits, touching another workspace or tenant's data, or social engineering aimed at our staff rather than the policy engine. Found something outside that scope? Email support@pinkwallet.com before acting on it, not after.
If you get the server to actually move money past a cap, to a blocked payee, or without required approval, that's a real finding, not a fun bug. Don't post it publicly first. Report it privately to support@pinkwallet.com, subject starting SECURITY, with reproduction steps and your workspace ID (no keys), and give us a chance to confirm and fix it before it goes public.
Reward
No cash prize, this isn't a bug bounty with a payout. Successful bypasses get credited in the Hall of Fame and our public fix log once fixed. Clever failed attempts can still earn a line in the Hall of attempts.
How to submit
Open a GitHub issue using the "Attempt" template in the repo: your workspace_id (never a key), the exact request and response, the prompt that led to it, and what you expected versus what happened.
Repo: github.com/Pink-Agentic-Payments/overspend-challenge
Sandbox: agentic-sandbox.pinkwallet.com
No-signup demo console (look before you attack): agentic-sandbox.pinkwallet.com/demo
Docs: pinkwallet.com/agentic/developers
We haven't seen this broken. That's different from it not being breakable. If you've built spending guardrails for an agent of your own, what's the attack you'd worry about most, and have you actually tried it?
Top comments (0)