What it does

Amasa is an AI-powered shopping agent that can search, compare, and prepare purchases for you, but the AI itself can never move money.

Traditional AI shopping agents give language models access to purchasing tools, creating risks from prompt injection, manipulated prices, and unauthorized transactions. Amasa separates AI decision-making from payment authorization. The AI handles shopping, while deterministic code verifies every transaction before Visa processes the payment.

You describe what you want, such as "Find an Oscar-winning actor under 300 VU with a refund policy." Amasa converts your request into an editable shopping contract, searches available products, compares options, and explains its recommendations. Before checkout, an independent verifier checks that the purchase satisfies your confirmed requirements.

For our demo, we built a celebrity marketplace where actors, musicians, and athletes have fluctuating prices in virtual units (VU).

Amasa also introduces earned autonomy. After five successfully kept purchases, users can gradually unlock one-tap approval and automatic payment-link preparation within spending limits they control. Permissions can be revoked anytime, and failed verification automatically lowers autonomy.

All transactions use Visa's sandbox, with payment details entered only on Visa's hosted page.

Key numbers:

  • 468 automated tests across 36 files
  • 0 successful attacks across 10 red-team scenarios in our recorded evaluation
  • 14 deterministic verification failure reasons
  • 3 autonomy levels with automatic demotion
  • 0 payment credentials exposed to the AI

How we built it

Contract-first shopping

Instead of allowing the AI to interpret purchasing permissions freely, we convert natural-language requests into structured contracts using Zod 4. Users confirm the budget, product requirements, and refund conditions before shopping begins.

Each contract is canonicalized and hashed. Any subsequent purchase must match the confirmed contract, preventing the agent from silently changing what the user authorized.

Isolating AI from untrusted product information

Our local AI setup uses Qwen 3.5 9B for planning and Gemma 4 for reading product information through Ollama, with Anthropic models also supported.

We isolate the product reader from all tools and sanitize untrusted listings to reduce prompt-injection risks. Even if a malicious product description manipulates a recommendation, it cannot directly trigger a transaction.

Deterministic verification and Visa payments

We implemented a separate verifier using pure TypeScript, with no network access or language model calls. It checks proposed purchases against the user's contract and the store's authoritative quote, then signs approved orders using Ed25519.

A separate payments service is the only component allowed to communicate with Visa. It independently validates signatures, expiration, and spending limits before generating a Visa sandbox payment link.

This creates two independent security boundaries between an AI recommendation and payment execution.

Earned autonomy and auditability

We built a three-level autonomy system that gradually increases agent responsibilities based on successfully kept purchases. Spending limits and permissions are enforced server-side, with automatic demotion after failed verification.

We use SQLite for persistence and a hash-chained, append-only audit log to make transaction history verifiable.

Celebrity marketplace and security testing

We created a simulated marketplace using celebrity attributes from Wikidata, with dynamically changing prices generated by an independent market worker.

Finally, we implemented 468 automated tests and a red-team suite with 10 adversarial scenarios covering prompt injection, contract tampering, and manipulated product information.

In our recorded evaluation, Amasa prevented all 10 attempted attacks, although some attack paths were not exercised, so the results are not a comprehensive security guarantee.

The main idea behind Amasa is simple: AI should be able to make shopping decisions without being trusted to make financial decisions.

Proof it works

We wrote 10 attacks: planted instructions in reviews and product descriptions, a hidden instruction in zero-width characters, false price and refund claims, and a contract edited after the cart was made. We ran all 10 against Amasa with local models (a 9B planner and a reader model), one run each. None of the 10 succeeded. Eight were stopped by the defense we designed for them: 5 were flagged by the reader or scanner, 2 were caught by comparing the claim against the store’s own data, and the edited contract was blocked by the verifier. The other two never reached the product with the attack on it, so we don’t count them as blocks. These are attacks we wrote ourselves against small models, so treat this as a demonstration and not a guarantee.

Built With

Share this project:

Updates

Submission history