Guarded Agent Checkout

Inspiration

Agentic commerce is arriving fast. PayPal's own Agent Toolkit and MCP server now hand AI agents the tools to create orders and move money, but nothing in that stack checks the agent itself: no merchant vetting, no spend cap, no freeze switch. The first prompt-injected shopping agent that drains a budget will not be a model failure, it will be a missing-guard failure. This project is that missing guard, on the most mainstream payment rail there is.

AI agents are getting wallets and checkout buttons faster than they are getting brakes. A prompt-injected or simply confused agent can overpay, pay the wrong merchant, or drain a budget in minutes. I already build the brakes on-chain (Aegis, spend control for agents on Base) and in front of agent data (tgp-guard, pre-flight checks for autonomous agents). This project puts the same guard in front of the most mainstream payment rail there is: PayPal.

What it does

An AI agent proposes a purchase. Before any money moves, the guard runs: Merchant sanity (known merchant? name/amount sane?), PayPal orders v2 (create + capture in sandbox, amount and status checked), spend cap (per-merchant / per-day, from a config file), and freeze switch (HOLD). Verdicts: ALLOW / BLOCK / HOLD. Nothing is charged unless it passes.

How I built it

Node.js (zero runtime dependencies), one CLI entry point (demo.mjs). Checks ported from tgp-guard: strict input validation, amounts as integers (no floats), reason codes on every verdict. PayPal sandbox calls use the Orders v2 API with an OAuth token fetched from client id/secret. All four scenarios run against live PayPal sandbox orders, so the verdicts are real, not mocked.

Challenges I ran into

The first token grant used the wrong PayPal endpoint and failed; I corrected the path to /v1/oauth2/token and it worked. The Orders v2 API only exposes a small, clean surface in the sandbox, so I treated it as a verifier: create order, capture order, read amount + status, then let the local guard decide ALLOW / BLOCK / HOLD. That separation — PayPal as the payment rail, the guard as the decision-maker — is what makes this portable to real agents.

Accomplishments that I'm proud of

First end-to-end guard over live PayPal sandbox: four live orders, four different verdicts, all enforced before capture. Merchant vetting, spend caps and a freeze switch in one small, dependency-free CLI.

What I learned

Tooling is not safety. PayPal's Agent Toolkit and MCP server give agents the power to move money; without a guard in front of them, that power is a liability. The guard has to live between the agent and the rail, with hard rules that no prompt can override.

What's next for Guarded Agent Checkout

Wire the guard into the Agent Toolkit as a pre-tool hook so every order creation passes through it, add persistent merchant reputation, and move the freeze switch to a small web dashboard.

Built With

• aegis
• node.js
• paypal-orders-v2-api
• paypal-sandbox
• tgp-guard