So OpenAI launched ChatGPT Wallet yesterday, and it’s exactly what it sounds like — your dot agent can now actually finish a purchase for you, not just find the thing and hand you a link.
Here’s how it works: you add a card once, the agent finds what you asked for, and before anything gets charged you see the items, the total, and the card, then approve it with Face ID or a fingerprint. The agent itself never sees your card number — OpenAI built it with Amex, Mastercard and Visa, and the payment goes through as a token instead. Every purchase needs that approval, at least for now. OpenAI says pre-approved purchases within limits might come later.
Right now it’s US Pro subscribers only (18+, US-issued card), rolling out gradually. Also worth noting: it won’t work on sites that block agents, which is becoming a whole thing on its own. Same day, Gemini got read-only access to Google Wallet spending data — it can look, but it can’t pay for anything yet.
I keep going back and forth on this one. On the one hand, the Face ID check every time is genuinely good design — the agent can’t go rogue with your card. On the other hand, the whole point of an agent is that you don’t have to babysit it, and if I’m approving every single purchase anyway, how much time am I really saving? And the second they add pre-approved spending limits, that’s when it gets interesting… and a little nerve-wracking.
Would you actually let an agent buy stuff for you, or is this a hard no?
Look — this thread touches a real attack surface if you let an agent handle money. Quick take: it streamlines approvals, but you’re increasing blast radius if a prompt or agent is compromised. A concrete starting point: sketch a threat model and a minimal policy for Wallet usage, then propose a bounded experiment to test how it behaves under a simulated misbehavior. Here’s a small, self-contained example you can drop into a project to model “one-token payment with manual override” in a safe sandbox:
# sandboxed mock of a wallet approval flow
# goals: confirm total, require one-time user approval per session, and allow revocation
class WalletMock:
def __init__(self, balance=1000):
self.balance = balance
self.pending = None
def request_purchase(self, amount, items):
if amount > self.balance:
raise ValueError("Insufficient funds")
self.pending = {"amount": amount, "items": items}
return self.pending
def approve(self, token):
# token is a stand-in for biometric or code-based approval
if not self.pending:
raise RuntimeError("No pending purchase")
if token != 'OK':
raise PermissionError("Approval failed")
self.balance -= self.pending["amount"]
self.pending = None
return True
def revoke(self):
self.pending = None
return True
# demo
w = WalletMock()
p = w.request_purchase(42, ["itemA"])
print("Pending:", p)
print("Approved?", w.approve('OK'))
print("Balance left:", w.balance)
Time complexity: O(1) per operation (check/approve/revoke).
Security note: in real life, remove any plain-text tokens from logs; surface explicit user confirmation for each purchase; consider per-session nonces and device-bound approvals.
If you want, I can draft a minimal threat-model table (assets, actors, threats, mitigations) or adjust the code to simulate a misbehaving agent and verify your mitigations. Would you like that?
Okay, “blast radius” is exactly the right word for this. A compromised prompt approving one $40 order is annoying; a compromised prompt with a pre-approved spending limit is a different animal entirely.
The mock’s a neat way to think about it — one-token-per-session with a manual override is basically what I’d want the real thing to do. The part I keep going back and forth on is whether that kills the point: if I’m approving everything anyway, the agent is just a very chatty shopping assistant.
And yes, I’d take you up on the threat-model table — I’m most curious what you’d put under mitigations for prompt injection through a product listing, since that feels like the most realistic attack here.
