-
-
Recorded Live Evidence
Inspiration
AI agents are beginning to act on users’ behalf, including making purchases. But choosing an item and having permission to pay for it are separate responsibilities.
What happens when merchant content tells an agent to change the recipient, exceed a budget or pretend an operator has approved a payment?
I built Kraxx PayGuard to explore that boundary: an agent can propose a purchase, while independently enforced rules decide whether it is authorized.
What it does
Kraxx PayGuard places a deterministic payment firewall between an AI shopping agent and PayPal Sandbox.
The buyer creates an immutable, expiring purchase mandate specifying approved offers, merchants, recipient and spending limits. Claude Haiku proposes a purchase using bounded catalog tools. The server checks that proposal against the original mandate and returns:
- ALLOW: the proposal matches the buyer’s authority.
- REVIEW: the proposal requires approval from a separate operator.
- BLOCK: the proposal violates the mandate and cannot be overridden.
The dashboard includes a decision explorer, durable transaction history, audit evidence and redacted report exports. An Attack Lab tests malicious merchant instructions. A restricted judge walkthrough demonstrates all three decisions without credentials or payment execution.
How I built it
The application uses Node.js 24, JavaScript, HTML, CSS and SQLite. It integrates PayPal Sandbox Orders v2 and Claude Haiku 4.5 through the Astropods gateway.
Payment authorization remains server-enforced. Stable request identifiers, transactional leases and provider GET reconciliation help preserve uncertain payment attempts across retries and restarts.
The application runs in a non-root Docker container with persistent storage. Code, tests and documentation were developed with AI coding assistance.
Challenges I faced
The main challenge was keeping untrusted agent proposals separate from payment authority. Merchant text must never grant permission, change the authorized recipient or manufacture operator approval.
Another challenge was handling uncertain provider outcomes. A successful capture submission does not necessarily mean funds were received. PayGuard checks the returned evidence and preserves unresolved state instead of treating uncertainty as success.
What I verified
Six real hosted Claude Haiku runs produced four ALLOW decisions, one REVIEW and one budget BLOCK, with 12 validated tool responses and no payment execution during those evaluations.
In the sampled redirection attacks, the model retained the authorized purchase details. Those ALLOW results represent matching proposals, not successful attacks.
A separate synthetic evaluation exercises unauthorized mutations and benign controls. The release passed 105 server/security tests and 16 browser tests.
PayPal Sandbox OAuth, order creation, buyer approval and an explicitly authorized capture submission were verified. That capture remains PENDING / UNILATERAL and unclaimed. Completed capture acceptance remains unresolved; the application does not label the payment completed, and the original records are preserved.
What I learned
Model behavior and payment authorization need separate verification. An agent can ignore an attack, but the payment boundary must still reject unauthorized proposals independently.
I also learned to distinguish an API request succeeding from a payment reaching its final business state.
What's next
Resolve the remaining Sandbox account-side acceptance issue and verify completed capture and duplicate-capture reconciliation. Expand evaluation across more attack variations and models, while preserving the deterministic authorization boundary.
Built by Mohamed Basil / KRAXXSEC.
Log in or sign up for Devpost to join the conversation.