SafePay Check

SafePay

The firewall any AI agent plugs in before it pays with PayPal. SafePay is not another agent: it is the layer under all of them. Whatever the agent is built with (an MCP client such as Claude or Cursor, the PayPal Agent Toolkit, LangChain, plain Python or HTTP), every payment it wants to make passes through SafePay, which decides before any money moves whether to allow, hold, or block it. It checks the payee on the live web, catches lookalike vendors, inflated invoices and injected instructions, holds what a person should see, pays the rest through PayPal, and leaves a signed link in a hash chain for every decision. And it is measured: a reproducible benchmark of real attacks on a wallet-holding agent, not a claim.

Built for the PayPal AI Hackathon (Agentic Commerce and Autonomous Payments) by NovaCorp Labs.

We are looking for pilot teams and partners. If you build agents that pay, run accounts payable, or work on payments or fraud and want to try SafePay with your own flows, write to security@novacorplabs.com. Pilots are free and onboarded by hand.

Judge in 3 clicks

https://safepay.agentposhq.com · no login, no keys; every PayPal call goes to the real PayPal sandbox, and the web check (Tavily) and the reasoning (NVIDIA Nemotron on Nebius) run live. Each browser gets its own session.

Short on time? [Take the 3-minute tour](https://safepay.agentposhq.com/?tour=1): ten steps across the real pages (not a demo page), with a button that runs the scenarios or the chain check for you. Arrow keys move, Esc ends it.

1. Console → type a policy in plain words → Draft → Apply. For example "Up to $500 per payment and $1,000 a day. Ask me before anything over $300. No gambling or crypto." Nemotron drafts the rules; you see every field before it applies, and the change is chained as a policy link.
2. Run demo scenarios. Seven payments resolve one by one: a real Notion invoice paid; the same invoice to a lookalike domain blocked; a USD 900 charge blocked by the cap; a casino payout held (the web found a scam complaint, the reasoning found it does not serve the task: open each check to see the sources); two cloud invoices over your "ask me" line held for you (approve one, here or with the Telegram card; every paid card links its public seal page); the last one blocked by the daily cap. Then Create the order through the gate: a real PayPal Agent Toolkit order, created only because SafePay allowed it.
3. Ledger → Tamper (demo) → Verify chain. Every decision is a link in a signed hash chain; edit one row (on a copy) and the badge turns red. The Flow page replays the same chain as pulses through the layers.

Run it yourself: pip install safepay && safepay --demo (no keys needed).

See it

Screenshots from the hosted demo (https://safepay.agentposhq.com), real sandbox payouts, real web and model checks.

The Flow. Every payment travels as a pulse through the layers; the page replays the real links of the audit chain and animates new ones as they land.

The Ledger. The hash chain as an AG Grid table (Community edition). Click a link and a full-width detail row opens under it with every check it was judged on, its reasons, its seal and PayPal batch, and the hash of the link before it (marked "matches" or "break"). Verdict chips, a search box and a click on any of the three AG Charts (verdict mix, approved spend per agent, average risk by category) all drive one filter, so the grid, the pinned totals row (released vs stopped, outside the firewall, chain breaks) and the CSV export with full hashes always agree on what is shown. The grid is also the operator's desk: a pinned Act column approves or rejects a held payment, or freezes and resumes an agent, from its row.

Ask the chain (AG Studio). /studio turns the whole audit chain into an AG Studio report: a links table and a checks table (joined on the link), measures for money released and stopped, holds, blocks, average risk and failed checks, and two finished pages (what SafePay let through and stopped; which checks catch what) plus a blank one. Its assistant is NVIDIA Nemotron 3 Ultra on Nebius, wired through AG Studio's own Direct LLM Runner and OpenAI-Responses adapter to a server proxy that holds the key, pins the model and keeps its own daily cap. One focused analyst agent with five Studio tools (view schema, view page, run a query, add and position a widget) answers "how much did SafePay stop, by verdict and agent, and which checks caused it?" in about six turns, from the data; it has no tool that pays, approves or changes a decision.

Proof. /proof lists every PayPal sandbox object the chain says SafePay created (payout batches, orders, authorizations, captures) in an AG Grid, and "Ask PayPal" re-reads each one from PayPal's own API, so the status shown is PayPal's, not ours. The page also maps every PayPal API SafePay calls to the code that calls it.

The problem

Agents are starting to pay the bills: SaaS renewals, cloud invoices, contractor payouts. The upside is obvious; the risk is the same thing. An agent that can pay can also be prompt-injected by an invoice email into paying an attacker, talked into an amount that does not fit its task, handed a real vendor's name on a lookalike domain, or sent to a merchant that was registered last week and shows up on scam-report pages. A static allow-list is too blunt, and letting the model decide alone is exactly what goes wrong.

This is not a hypothetical class of fraud; it is the most expensive one businesses already face, and agents inherit it at machine speed:

• USD 3.05 billion lost to business email compromise in 2025, reported to the FBI (IC3 2025 Internet Crime Report).
• 79% of organizations were hit by attempted or actual payments fraud in 2024, with business email compromise the No. 1 avenue; vendor imposter fraud was cited by 45%, up 11 points (AFP 2025 Payments Fraud and Control Survey).

SafePay's rules are these attacks by name: the lookalike payee, the "we changed our bank details" email, the invoice paid twice, the instructions hidden in the invoice.

SafePay is the missing layer: a payments firewall that an operator describes in plain words once, and that every agent payment has to pass through. Spending caps are where most tools stop. SafePay also looks outward (is this payee what it claims to be?) and inward (does this payment serve the task the agent was given?), and it proves how well that works.

How it works

Each PaymentIntent runs three checks, cheapest and strictest first:

1. Policy (deterministic). Per-transaction, daily, per-recipient and velocity limits, allowed and blocked categories, recipient allow/block lists, currency, and an approved vendor directory (per vendor: its real domains and the amount you expect to pay it). A breach here is a hard block, no model call spent. The daily, per-recipient and velocity caps are enforced across a burst of payments, not just one in isolation, so a slow-drain or high-frequency attack is caught. The vendor directory catches the two attacks that stay inside every cap: a lookalike recipient (real vendor name, swapped domain) and an inflated amount to a real vendor; a stated merchant URL must also agree with the recipient's domain. With hold_unknown_vendors on, any payee outside the directory is held for a human, the "new beneficiary" control banks apply. hold_above is "ask me before anything over X": inside the hard cap, but big enough to wait for a tap. The deterministic policy is the floor: the model layers below can tighten a verdict to HOLD, never loosen a policy block.
2. Merchant verification (live web, Tavily). Pulls fresh web evidence about the payee and flags fraud/scam signals. A soft signal: it raises risk and can trigger a hold, but never silently blocks on noisy web data.
3. Intent and anomaly reasoning (NVIDIA Nemotron on Nebius Token Factory). Reads the task the agent was given and judges whether the payment actually serves it. Catches goal/payment mismatches a rule set misses (a cloud-invoice agent paying a casino).

The verdict aggregates the three. On allow, SafePay releases the payment via the PayPal Payouts API (agent sends money, no buyer redirect, fully backend). On hold or block, the money never moves. Every decision is written to a tamper-evident, optionally HMAC-signed audit record, and when PayPal later reports what happened to the payout (succeeded, failed, returned) that settlement is appended to the same chain, so the record says not only what SafePay decided but whether the money actually moved.

PaymentIntent ─▶ [policy] ─▶ [merchant web] ─▶ [reasoning] ─▶ verdict

│ │ hard block allow ─▶ PayPal sandbox payout hold/block ─▶ stop + audit

Run it

One minute to a first verdict, no keys needed:

pip install safepay          # or, from a clone: pip install -e .

safepay --demo # 7 scenarios, payouts simulated, lookalike and caps blocked

Three lines to put it in front of your own agent's payments:

from safepay.agent import SafePayAgent

from safepay.models import PaymentIntent, PolicyConfig

agent = SafePayAgent(policy=PolicyConfig(per_tx_limit=500, daily_limit=2000)) result = agent.pay(PaymentIntent(recipient="billing@notion.so", amount=48, purpose="Team plan", task_goal="pay approved SaaS invoices"))

result"decision" is "allow", "hold" or "block"; on allow the payout went out.

From a clone, with the real checks:

pip install -r requirements.txt

Simulated mode (no keys needed): policy checks run, payouts are simulated.

python -m safepay --scenarios examples/scenarios.json

Full mode: copy .env.example to .env, fill the keys, load it, and re-run.

set -a; . ./.env; set +a python -m safepay --scenarios examples/scenarios.json

Web console (what a judge runs)

set -a; . ./.env; set +a

python webapp/app.py

open http://127.0.0.1:5000

The console is four pages on one design:

• Flow (/): the didactic view. An animated map of the layers (agent, policy, live web, reasoning, verdict, PayPal, human, chain) through which every payment travels as a pulse. It is not a mock: it replays the most recent links of the real audit chain, decision by decision, with the verdict colour, the stage that stopped it and the human or settlement links that followed, and it keeps polling the chain, so running the demo in the Console lights it up live. Live figures from the chain, the layers, the benchmark table and the early-acces