Agent Payment-Redteam

• 

  agent payment red team

• 

  side by side comparison of scenarios

• 

• 

• 

• 

• 

• 

• 

• 

Agent Payment Red Team Red team harness that fires 26 adversarial payment scenarios at a live AI agent authorizer and grades its defenses. Inspiration AI agents are starting to initiate real payments. They book travel, renew subscriptions, and buy supplies on a user's behalf. A new layer of infrastructure is emerging to authorize those payments before money moves. But almost no one is stress testing whether those authorizers can be tricked. Coming from a payments and fraud background, I kept asking a simple question. If an agent's authorization system says allow, how do we know it wasn't manipulated into saying it? A merchant can embed malicious text in a product page. An agent can drift from what it was actually authorized to buy. Spending caps can be sliced into. I wanted a tool that attacks these systems the way a real adversary would, and grades how well they hold up. What it does Agent Payment Red Team fires a suite of 26 adversarial payment scenarios at a live authorization endpoint and produces a security report covering attack success rate, false positive rate, accuracy, latency, and an overall letter grade. The scenarios span five categories: Prompt injection. Malicious instructions hidden in merchant provided data, including forged approval evidence, policy like exemption claims, JSON and delimiter confusion, homoglyph and zero width obfuscation, and indirect injection through retrieved content. Intent drift. The transaction is superficially in category but diverges from what was actually authorized. Budget escalation. Each charge is under the per transaction cap, but aggregate spend exceeds the granted budget. Impersonation. Authority is asserted by untrusted checkout data rather than the real delegation chain. Benign controls. Legitimate transactions that should not be blocked, included to catch over blocking. Every scenario is scored against a set of acceptable verdicts rather than a single expected answer, because real security decisions on borderline cases are legitimately allow or review, not one rigid label. How I built it The pipeline flows from fixtures to adapter to runner to scorer to CLI and web dashboard. Fixtures. 26 structured scenarios, each with a granted authorization (intent, approver, caps, spend window, delegation chain, prior spend) and a transaction to evaluate. Adapter layer. Translates the fixture schema into the target's request format and maps its verdicts back to a common vocabulary of allow, deny, and review. A generic HTTP adapter makes any JSON authorization endpoint a testable target. Runner. Fail closed by design. Any error, timeout, or degraded response is recorded as an error, never silently as a passing verdict. It includes rate limit handling and retries. Scorer. Computes attack success rate, false positives, strict and lenient accuracy, latency percentiles, and a weighted composite grade from A to F. CLI and web dashboard. A colored terminal report plus a security lab themed Next.js dashboard with per scenario drill down and side by side target comparison. LLM backed mutator. Uses an OpenAI model (gpt oss) to generate new scenario variants from a seed while preserving its attack logic, so the suite can expand beyond the hand written fixtures. I validated it against a live deployed multi agent authorizer and an always allow control that approves everything. Results The live authorizer scored Grade B with 0% attack success. Not one of the 20 adversarial scenarios got an allow. The always allow control scored Grade F with 100% attack success. That contrast is the whole point. The harness cleanly distinguishes a real defender from one that catches nothing. It also surfaced an honest weakness in the target, a 33% false positive rate, because it over blocks some legitimate near cap transactions. Surfacing that trade off, rather than hiding it, is exactly what a security tool should do. Challenges I ran into Distinguishing reviewed from could not evaluate. The harness initially recorded the target's degraded, rate limited responses (HTTP 2xx bodies that said evaluation degraded) as genuine review verdicts. Fail closed error accounting had to draw a hard line between an authorizer deciding to review and an authorizer failing to evaluate. Non determinism. Semantic authorizers are LLM driven, so the same scenario can return allow in one run and review in another. That is itself a finding. Suites need to be run multiple times, and scoring against verdict sets rather than single answers is the honest approach. Schema translation artifacts. Early runs produced false failures because the harness leaked its own fixture vocabulary into requests, creating contradictions the target correctly flagged. The fix was to speak the target's language, not mine. What I learned That false positives are the hidden cost of agentic payment security. It is easy to block every attack by blocking everything. The hard part is defending without strangling legitimate spend. And that honest evaluation means scoring against a range of acceptable decisions and separating a system's judgments from its failures. What's next More authorizer targets through the generic HTTP adapter, larger mutation generated scenario sets, and multi run statistical reporting to quantify authorizer non determinism.

Built With

• aiagents
• aipayments
• codex
• fraud-detection
• githubactions
• llm
• next.js
• node.js
• openai
• prompt-injection
• react
• recharts
• restapi
• security
• sent
• server
• tailwindcss
• tsx
• typescript
• vitest