the card vault
The goal: an agent can pay for something online with your card, and the model never sees the card number. So a prompt injection, a leaked transcript or a chatty model cannot give it away.
You hand over a card for named sites. The system stores it where the agent cannot read it, and the
agent only ever holds an opaque handle. The code is vault/cardvault/.
watch a card arrive
A fixed script with the test number. The hook runs before the agent does, so the card text is replaced with a note before any model request is built.
the flow
can you order this for me on Amazon?
card_request. Then it asks
for the number, expiry and security code in one text.checkout_start, which makes it ask first: just for you,
or a group order to split before paying? Solo is cleared. A group order opens a prepay split, and the
checkout only clears once the split plugin reports it fully collected.can and cannot
| can | Ask for a card, list a person's cards, delete one, request a fill on an allowed site |
| cannot | Read a card back, fill it on another site, fill someone else's card, fill without a cleared purchase and the person's confirmation |
ours and theirs
The runtime in core/ already ships the hard part: an encrypted store, handles the model can list
but not read, a fill that only works on the exact site a card is bound to, and redaction of filled values.
That vault assumes one person adding cards from a terminal. GroupCart is many people, over text. We added:
| ours | what it does |
|---|---|
| Intake over text | Catches card details in an inbound message before the model or the transcript sees them |
| Permitted sites | The person names the sites first; the card is bound to exactly those |
| Per-person scoping | You only see and fill vault items you saved |
| Checkout gate | A card fill needs a cleared purchase: solo, or a group order whose split is fully paid |
| Second net | Card numbers are stripped from every model request and tool result |
honest limits
- The card travels over iMessage and through Photon to reach us. It is kept out of the model, the transcript and our state file, but it exists in your own message history and in transit. One-time virtual cards per purchase are the right next step.
- Not tested end to end by us: the actual fill into a live checkout page, and the confirmation prompt as it appears over iMessage. Both are runtime features.
- Exact sites only. A checkout hosted on a third domain is refused until that site is added.
- The vault key sits next to the vault file on the machine. Anyone with the laptop has both.