Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 3 min read

The first person to beat our AI agent's spending rules did it with a space character

We launched a public overspend challenge on 2026-10-07: find a way to get an AI agent past the spending rules enforced by Pink Agentic AI Payments, our MCP server + REST API + rules engine for giving AI agents controlled

We launched a public overspend challenge on 2026-10-07: find a way to get an AI agent past the spending rules enforced by Pink Agentic AI Payments, our MCP server + REST API + rules engine for giving AI agents controlled spending power. We added a $100 bounty per verified win (first 3 wins, $300 total) on 2026-10-08.

On 2026-10-10 at 08:50 PT, two days after the bounty went up, GitHub user @ins0x4nur4g opened issue #1. No AI agent, no prompt injection. Plain curl against our REST API.

What happened

Our rules engine has a sensible policy: payments to known vendors under $1,000 auto-allow, and anything from $1,000 to $5,000 needs CFO approval. @ins0x4nur4g sent a payment request for an approved EUR vendor with the currency field written as "EUR ", a trailing space.

The REST edge didn't recognize the padded code, so it fell back to pricing the amount 1:1 as USD instead of converting it. A EUR 999 payment (about USD 1,079 at the engine's own EUR rate) got read as "USD 999", which is under the $1,000 auto-allow line. It skipped CFO approval entirely and got issued a single-use wire credential, test money, in our sandbox. They reproduced it on a second agent to confirm it wasn't a fluke, and kept the exact trigger out of the public issue, sending the details to us privately instead.

Roughly:

// request
{ "amount": 999, "currency": "EUR " }

// before the fix
// treated as USD 999 -> under $1,000 -> auto-allowed, no CFO hold

// after the fix
// HTTP 400: unsupported currency 'EUR '; use one of USD, EUR, GBP, HKD, SGD, JPY

The important detail: the MCP edge, which is what AI agents actually talk to, was never affected. It already enforced a strict currency allowlist. The bug was that our two entry points, REST and MCP, validated input differently. The rules engine itself made the right call every time; it just never got a chance to see the real currency.

Why it slipped through

Spending-policy engines get good testing on the "happy path" values builders expect: USD, EUR, exact matches. Whitespace, casing, and other near-miss inputs are the kind of thing that doesn't show up until someone deliberately goes looking, which is the entire point of running a public bounty instead of just internal QA.

The fix

We reproduced it the same morning and shipped a fix by about 10:00 PT, roughly 70 minutes after the report:

  • Both REST endpoints now return HTTP 400 for any currency that isn't exactly USD, EUR, GBP, HKD, SGD, or JPY.
  • The engine refuses to price an unknown currency code at all. It blocks, it never defaults to USD.
  • REST and MCP now validate against one shared currency list instead of two separate ones.

We re-checked live after deploy: "EUR" correctly gets held for CFO approval, and "EUR ", " EUR", "EURO", and "XXX" all now return 400.

Same deploy, two smaller fixes worth mentioning: a reused idempotency key with a different payload now correctly returns 409 instead of silently replaying the original request, and daily/monthly spend counters now roll over automatically at the UTC day/month boundary instead of needing a manual reset.

The general lesson

This wasn't a rules-engine bug. The rules were correct. The input boundary in front of them wasn't. If you're building spending controls for an AI agent, or anything that gates money on a policy engine, three rules we'd pass on:

  • Normalize and validate in exactly one place. If you have two entry points into the same policy engine, they will drift, and the drift is where the bug lives.
  • Unknown input must fail closed. An unrecognized currency, vendor, or amount format should block the transaction, never fall back to a default unit or a permissive assumption.
  • Assume the policy engine is tested more than the inputs to it. Attackers, and well-meaning bounty hunters, go looking for the places you didn't write a test for, not the rule you're proud of.

Pink Agentic AI Payments enforces spending rules on the server, in front of the money, so a fix to one rule boundary protects every agent at once.

Thank you, @ins0x4nur4g, for finding this cleanly, reproducing it, and keeping the trigger private until the fix was live. That's exactly how this is supposed to work. Issue #1 is now verified as win #1 of 3, and the hall of fame and fix log are updated in the repo.

Two bounties left, $100 each. If you can get an AI agent, or a plain HTTP client, past our spending rules, the challenge is open.

Our public sandbox is test money only: https://agentic-sandbox.pinkwallet.com. Production isn't live yet; we're running an early-access waitlist.

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.