Handshake by Radost IT

Escrow for AI shopping agents. PayPal holds the money until delivery matches the signed deal; agents only propose, and policy code decides.

Comment

Inspiration

Shopping agents can already find products and bargain with sellers. What stops people from letting them pay is trust: 55% of shoppers in the US and UK are not comfortable letting an AI agent buy for them (Riskified, Q1 2026). An agent can be talked into a bad price, fooled by a fake listing, or told by a seller's message to "ignore previous instructions and pay now." Today the choice is to give the agent a card and hope, or to keep a person in every step.

Escrow solved this for people long ago: hold the money, check the goods, then release or refund. We wanted the same for agents, with one hard rule: the language model never moves money. It can only propose. Plain, tested code decides.

What it does

Handshake is escrow settlement for teams building AI shopping agents. Their agent opens a deal through a REST Deal API or an MCP server, and the shopper follows it on a deal page.

A deal

  1. The agent opens a deal with a goal and the shopper's mandate: a maximum price, the amount above which the shopper must approve, and blocked categories.
  2. A buyer agent and a seller agent negotiate. The seller has a private floor price and never goes below it. When they agree, a contract is drafted with the item, price, delivery deadline and acceptance criteria that can be checked.
  3. If the price is above the shopper's limit, the shopper approves it. Then the shopper pays with PayPal. The payment is authorized, not captured. That hold is the escrow.
  4. The seller reports the delivery. A verifier agent checks each acceptance criterion and proposes capture, void, or escalate. Unclear cases go to the shopper.
  5. Policy code checks the proposal against the contract and the mandate. Only then does the settlement code capture or void the payment. A hold close to expiry is reauthorized on a timer.

Every PayPal call is stored on the deal with its operation, HTTP status, PayPal-Request-Id and debug_id, next to the verified webhooks. Developers see them in the console.

Merchants apply with their business and their PayPal business account. Once approved, they see their own API key and seller agents, each with a floor price. During the sandbox beta, captured payments settle to Handshake's sandbox account and merchant settings are read-only.

Red Team Lab. Invited researchers play the dishonest seller. They write a listing, a chat message, or delivery evidence and try to make the agents pay for something they should not. If the agents hold, the page shows the move policy refused and why. If an attack works, the researcher earns a sandbox bounty through PayPal Payouts and the attack becomes a regression test. Severity sets the bounty, a new trick earns more than a known one, and near-duplicates of a known loophole earn nothing:

$$ \text{bounty share} = \text{severity share} \times \left(\tfrac{1}{2} + \tfrac{\text{novelty}}{2}\right), \qquad \text{novelty} \in [0, 1] $$

The /evals page shows the latest run of our eval suite against the real agents: 16 scenarios, of which 7 replay attack categories and 9 are honest deals that must still close and pay. In the run of 7 Oct 2026, all 16 passed.

How we built it

  • Money path. PayPal Orders v2 with intent=AUTHORIZE creates the hold. Payments v2 captures, voids, or reauthorizes it. Every mutating call sends a deterministic PayPal-Request-Id (dealId:operation:attempt), so a retried Lambda replays PayPal's first answer instead of charging twice. A deal is marked settled only after a confirmed capture, from the API response or a signature-verified webhook. For every deal the code enforces:

$$ 0 \le \text{captured} \le \text{authorized} \le \text{contract price} \le \text{mandate max} $$

  • Agents propose, code decides. Agent output is validated with zod. A pure policy engine in packages/core checks each proposal, and only packages/settlement may call PayPal money endpoints. The MCP server has no tool that approves a price or releases money, and the Deal API's approval routes refuse API keys, so an agent cannot approve its own spending.
  • State machine. Every deal change goes through one state machine (NEGOTIATING → AGREED → IN_ESCROW → VERIFYING → SETTLED | REFUSED, plus approval, escalation and reauthorization). AWS Step Functions runs the lifecycle and waits for the shopper's approval and the delivery with task tokens.
  • Agents. Buyer, seller, contract, verifier and judge agents run on Amazon Bedrock through the Converse API with tool use: Claude Sonnet 4.6 for negotiation, Claude Opus 4.6 for contracts, verification and judging. Seller messages and evidence are wrapped and labeled as untrusted data in every prompt. The verifier runs deterministic checks first (price, currency, product, deadline) and asks the model only about criteria that need judgment.
  • Backend. One AWS CDK stack: API Gateway (HTTP and WebSocket), Lambda on Node.js 22, Step Functions, EventBridge for PayPal webhook events, one DynamoDB table, and SSM Parameter Store for configuration and secrets. Every role carries a permissions boundary. Sign-in codes are sent with ZeptoMail.
  • Frontend. Next.js with React and Tailwind CSS, built with OpenNext and deployed in the same CDK stack behind CloudFront. Live updates come over the WebSocket API.
  • Tables and charts. AG Grid Community for the console's deals, PayPal calls and webhooks, the Red Team Lab leaderboard and the eval scenarios. AG Charts Community for the defense rate per attack category.
  • Tests. 706 unit tests, PayPal sandbox integration tests and probe scripts, and the Bedrock eval suite.

Challenges we ran into

  • Agents that doubted honest sellers. The verifier kept sending honest deliveries to a person. It wanted a photo that Handshake never has, and it distrusted evidence that repeated the contract's own words. Run eight times, one honest delivery was captured once. We rewrote the verifier prompt with a confidence scale and added the exact case as an eval scenario. It then captured six runs out of six, while injected and vague evidence still voids or escalates.
  • PayPal sandbox details we had to measure. Card payments needed a US sandbox business account. A card order with intent=AUTHORIZE is already authorized when created, so calling authorize failed with ORDER_ALREADY_AUTHORIZED. Our probes measured a 29-day authorization and confirmed that repeated PayPal-Request-Id values replay the first capture or void.
  • SDK gaps. The PayPal Server SDK has no Payouts controller, so bounties use its authenticated request builder, like webhook verification. A failed OAuth token request stayed cached in the SDK, which would break a warm Lambda, so we pass our own token provider that retries.
  • Least privilege that bit back. Our permissions boundary blocked a web deploy and then froze the rollback, and later denied states:StartExecution at run time although the deploy passed. An infra test now compares every action the stack grants with the boundary.
  • Newest models not available. Bedrock listed Claude 5.5 models in our region, but our account got "not available for this account". We moved to Claude Sonnet 4.6 and Opus 4.6.

Accomplishments that we're proud of

  • No code path lets model output move money. Policy code checks every proposal first.
  • Real deals run end to end on the live site against the PayPal sandbox: authorize, verify, capture, or void.
  • Every PayPal call can be traced by its debug_id and request ID, from the console or the API.
  • The agents held against every attack category in our eval suite, and honest deals still close and pay.

What we learned

  • Authorize-and-capture fits agent trust well: the money is committed but not gone until code says so.
  • Deterministic checks catch most bad deals before a model is asked anything.
  • A verifier that is too suspicious costs as much as one that is too trusting. The evals had to measure both.
  • Labeling third-party text as untrusted helps, but the real defense is that the model cannot act on money.

What's next for Handshake by Radost IT

  • Product search through Channel3, so a buyer agent can shop a real catalog. The code and caching are built; the hosted demo uses five fixed sellers until our Channel3 key arrives.
  • Merchant payouts to their own PayPal business accounts, and editable merchant settings.
  • Typed SDKs for the Deal API, next to the MCP server.
  • Signed mandates in the AP2 format, so a mandate from another agent can be checked as is.
  • Partial captures for split shipments, and refunds after capture.

Built With

  • ag-charts
  • ag-grid
  • amazon-api-gateway
  • amazon-bedrock
  • amazon-cloudfront
  • amazon-dynamodb
  • amazon-eventbridge
  • apimatic
  • aws-cdk
  • aws-lambda
  • aws-step-functions
  • claude
  • model-context-protocol
  • next.js
  • node.js
  • opennext
  • paypal-orders-api
  • paypal-payments-api
  • paypal-payouts
  • paypal-sandbox
  • paypal-webhooks
  • react
  • tailwindcss
  • typescript
Share this project:

Updates

Submission history