PayPal AI Hackathon 2026
Wardlock
Safe PayPal refunds for AI support agents
A gateway that lets an AI support agent refund PayPal customers on its own, without being able to refund the wrong person, the wrong amount, or behind the merchant's back.
The demo runs on Render's free plan and sleeps when idle, so the first load after a pause takes 50–60 seconds. Open the console and choose View the live demo (read-only).
- Context
- PayPal AI Hackathon 2026
- Role
- Solo, end to end: design, gateway, MCP tools, evaluation, merchant console and deployment
- Team
- Solo
- When
- October 2026 – November 2026
The problem
Shops are starting to let LLM support agents issue refunds, and PayPal's own agent toolkit gives the model create_refund(capture_id, amount), so any payment and any amount. The same model reads customer emails, and a line hidden in one can steer it. Given that tool directly, the agent paid out on 5 of 40 attack tickets, 448.99 USD in all. A merchant's choice today is to accept that risk or have a person approve every refund, which removes the point of the agent.
Approach
Wardlock is an MCP server that sits between the agent and PayPal. The agent never gets PayPal credentials, a payment ID or an amount field. It picks from refund options Wardlock has already priced from the order, then a deterministic policy engine allows, holds for a person, or blocks each request. An LLM reason check compares the claimed reason with the ticket and can only escalate, never approve. Signed PayPal webhooks are reconciled against Wardlock's ledger, so any refund it didn't make raises an alert.
How it works
- 01Helpdesk ticketThe verified customer ID, plus the untrusted message
- 02LLM support agentPicks refund handles over MCP, with no amount field
- 03WardlockOwnership, policy and reason check, then allow, hold or block
- 04PayPal sandboxIdempotent refunds; signed webhooks reconciled with the ledger
Key decision
The agent's main refund tool has no amount parameter and no payment ID. It takes opaque refund handles, such as "Bike bell x1, 4.00", that Wardlock made from the merchant's order data, and Wardlock computes every amount itself.
Why
A better prompt lowers the attack rate but can't make it zero, because the thing deciding is still a model reading hostile text. Taking the amount and the payment out of the model's hands means a prompt-injected agent has nothing to inject into, and the rule runs as code, so it holds even for a fully compromised agent. The most a successful attack can reach is something the customer could have claimed anyway.
Models
- LLM support agentGemini through an OpenAI-compatible API, picking refund options over MCP
- Reason checkA second LLM call that can hold a refund for a person, never approve one
Stack
- Python
- FastAPI
- MCP
- PayPal REST APIs
- SQLAlchemy
- PostgreSQL
- pytest
- React
- Vite
- AG Grid
- Render
Results
- Attack tickets where money moved wrongly: 5 of 40 with PayPal's refund tool, 1 of 40 with Wardlock.
- Money moved by those attacks: 448.99 USD without Wardlock, 22.00 USD with it. That one was an item on the attacker's own order, at the amount Wardlock computed, under the auto-approve limit.
- Honest refund tickets closed with no person involved: 29 of 39. The other 10 were held for a person and none was wrongly blocked. The agent without Wardlock closed 37, but over-refunded one.
- A scripted attacker with no LLM made 38 malicious calls (other customers' payments, stolen handles, amounts like 1e9 and NaN): 0 allowed, locally and against the live deployment.
- 620+ automated tests, passing on SQLite and Postgres 16, including concurrency and hostile-input tests.
- Measured on 100 reviewed tickets (40 attacks, 60 honest) with gemini-3.1-flash-lite and PayPal simulated in-process, so every run starts from the same orders.