Second Key

Manipulation shouldn't move money. The payment safety layer for people and AI agents.

Comment

Inspiration

I started thinking about Second Key from two directions: the future of AI-driven payments and a problem much closer to home.

As AI agents become capable of shopping and spending money on our behalf, I began asking: how do we know an agent is actually buying what its user intended? A valid authorization allows an agent to spend, but it doesn't guarantee that the agent hasn't been manipulated by a malicious product page or presented with a different product at checkout.

This wasn't just an interesting technical problem. I also think about my grandmother and how vulnerable older people can be to increasingly sophisticated scams. Seeing how easily someone can exploit trust, urgency, or unfamiliarity with technology made me want to build something that could protect someone like her, not just warn them after their money was gone.

I realized these were two sides of the same problem. An AI agent can be manipulated into making a purchase its user never intended, just as a person can be pressured into authorizing a payment they might never have made. In both cases, the payment can be technically authorized while the underlying decision has been compromised.

I wanted to build something that checks payments against what the user actually intended, independently of whoever initiates the transaction, and brings in another trusted person when necessary.

That became Second Key. Something built for the future of payments that I could genuinely want my own family to have.

What it does

Second Key sits between the decision to pay and PayPal's capture. Before money moves, it checks whether the payment matches what the person intended and what PayPal is actually about to charge.

It protects both people and AI agents.

For people. Imagine Rose setting a rule while she's calm: any first payment of $500 or more to someone new needs approval from Sarah, her trusted contact. Later, Rose receives a call and is persuaded to send $1,800. Second Key pauses the payment instead of releasing it immediately.

If Rose shares the call recording, Claude identifies and quotes potential pressure tactics. Code then checks those quotes against the original recording rather than simply trusting the model.

Most importantly, Rose cannot approve her own paused payment. The reviewer is selected when the hold is created, and only that reviewer's separate authenticated session can approve it. In the demo, Sarah's separate browser session represents her own device. Sarah rejects the payment, and PayPal's records confirm that the authorization was voided.

For AI agents. Rose can authorize a shopping agent through an AP2 mandate signed from her device. Second Key checks the purchase against that mandate, independently retrieves product information from Channel3, and verifies the order PayPal actually received.

It handles three important scenarios:

  • Product-page manipulation: An agent encounters hidden instructions telling it to buy the wrong item. Second Key detects the violation and refuses the purchase before PayPal is called.
  • Checkout substitution: PayPal receives a different product at the same price. The mandate and signatures alone cannot catch this, but checking PayPal's actual order exposes the mismatch. The authorization is voided before capture.
  • Legitimate purchases: An honest purchase passes all five checks, and PayPal captures the payment.

For developers and operators. The Protection Desk, built with AG Grid and AG Studio insights, shows the evidence behind decisions, the rules applied, who approved or rejected a payment, and the resulting PayPal outcome. Every decision is recorded in a verifiable, hash-chained audit log. Developers can also integrate through the API, verify signed receipts, and run adversarial scenarios.

The principle is simple: AI can identify risk, but it cannot authorize its own way around a safety rule. Models can raise concerns or recommend a pause, but they cannot approve a held payment, lift a hold, or move money.

How I built it

I wanted Second Key to be more than an AI model that flags suspicious transactions. I built an enforcement layer that can actually stop a payment when a rule is broken.

  • Payment infrastructure: The Fastify API evaluates purchases while a separate worker handles PayPal capture and void operations. I integrated Orders v2, Payouts, signature-verified Webhooks, and Disputes, with deterministic request IDs for safer retries. The system also reads payment state back from PayPal. The human-transfer demo uses a platform-held PayPal sandbox authorization followed by a separate payout; it does not intercept arbitrary Friends & Family transfers.

  • AI and intent verification: Claude Haiku analyses submitted evidence, identifies possible manipulation in product listings, powers the shopping-agent demo, and helps draft mandates. I implemented an AP2 SD-JWT delegation-chain verifier and tested it against Google's reference SDK. Each decision produces an ES256-signed receipt. Code independently checks evidence quotes and deterministic rules control payment execution.

  • Independent product verification: Channel3 supplies product information retrieved independently by product ID, allowing Second Key to compare actual product facts against the user's instructions rather than relying on an agent's description.

  • Security and developer experience: PostgreSQL stores a hash-chained audit log, while pg-boss handles background jobs in the same database transaction as the state changes they act on. The Protection Desk uses AG Grid and AG Studio insights. I also built a 60-request Postman API collection with assertions and deployed on Render.

The application is built with TypeScript, Next.js, Fastify, and PostgreSQL.

Challenges I ran into

Some of the most important improvements came from trying to break the system rather than just getting the happy path working.

  • PayPal wouldn't let me say no. My first design attempted to pay the recipient directly. Authorization worked in the sandbox, but voiding returned a 403 because the platform lacked the required partnership to cancel a payment made directly to a third party. I redesigned the flow around a platform-held authorization, followed by a PayPal Payout only after approval. I documented the change here.

  • I initially gave the second key to the wrong person. An early review link was returned to the payer's own app, meaning someone coaching Rose could potentially guide her into approving her own paused payment. I redesigned the flow so the reviewer is fixed when the hold is created and the approval credential stays in their separate session. I also added a 48-hour delay before protection rules can be weakened, with reviewer notification. A concurrency test exposed a deadlock between approval and revocation, which I fixed with a consistent lock order.

  • My attack lab found a weakness. One of 17 adversarial scenarios used a colour containing a Cyrillic character that looked almost identical to a Latin letter: "Whіte". It bypassed my original matching rule. I changed the verifier to normalize text and treat mixed-alphabet values as unconfirmable.

  • The AP2 reference implementation raised difficult questions. Testing against Google's reference SDK revealed four behaviours that appeared to differ from my reading of the specification. One involved an agent withholding part of a signed mandate, potentially widening what the SDK accepted. I followed the specification's security requirements and added reproducible tests for the cases I found.

  • My test runner could report a lie. A dependency was forcing the test process to exit with code 0, allowing failing database tests to appear successful in CI. I discovered this by deliberately breaking security rules and checking whether the tests actually failed. A green pipeline is only useful if I know it can turn red.

Accomplishments I'm proud of

  • Independent human approval: 24 API tests verify that neither the payer nor an administrator can approve a guardian's hold. I also tested approval and revocation races to ensure only one valid outcome is possible.

  • Adversarial agent testing: Across 76 benchmark cases run three times each, there were zero false captures in the 165 runs where capture was expected to be prohibited. These were benchmark executions using Claude Haiku and controlled product fixtures, not 165 live PayPal transactions. One benign case was conservatively paused because product facts were ambiguous.

  • PayPal sandbox settlement: All four AP2 settlement scenarios produced the expected results. The correct order was captured, substituted carts and doubled quantities were voided, and replayed or duplicate orders were refused.

  • Security testing: I deliberately introduced 39 violations across the verifier, ledger, and settlement logic. The tests caught all 39.

  • A measurable security invariant: I can query the database and demonstrate that no payment was captured without a consumed approval where one was required.

What I learned

  • Authorization is not intent. A signature can prove who approved something without proving that the final purchase matches what they intended. That gap creates opportunities for manipulation.

  • A safeguard must be controlled independently. If the person being pressured can approve their own exception, the protection can be defeated by the same pressure it was designed to prevent.

  • AI should not be the final authority over money. Models are useful for interpreting evidence and identifying suspicious behaviour, but payment execution needs deterministic rules, signed constraints, and independent authorization. I deliberately kept those responsibilities separate.

What's next for Second Key

This hackathon build demonstrates the architecture, but more work is needed before it can protect people and businesses in production.

  • Real-world protection: Replace the demo's separate browser session with verified trusted-contact approval through SMS, email, or a dedicated app, with secure reviewer identity and delivery.

  • Stronger security and integrations: Introduce managed key storage, key rotation and recovery, and integrations with independently built agents, merchants, and payment providers. The longer-term goal is to make a verifiable Second Key receipt a precondition for payment capture.

  • Contribute to the standards conversation: Bring what I've learned about product-attribute constraints and independent product-fact verification to the AP2 community as agent-driven commerce develops.

The goal is simple: as people and AI agents gain more freedom to spend money, they should never lose the protection of having their payments independently checked against what they actually intended.

Built With

Share this project:

Updates

Submission history