On April 30, Stripe updated Link, its digital wallet, so autonomous AI agents can use it to transact. I’m not talking about a human clicking a button with an agent’s recommendation in the loop. The agent itself, holding payment credentials and completing a purchase. A few weeks later, on June 10, a startup called Jedify raised $24M to arm AI agents with structured context about a company’s business so they can act with more authority on its behalf.
Put those two together and you get the thing I’ve been circling in my writing for the last six months: an agent that knows your vendors, budgets, and approval norms is useful, and an agent that can move money is convenient, but combining them is what makes either one dangerous.
I’ve written about the agentic loop: a system that senses, thinks, acts, and remembers, then repeats forever, without waiting to be asked. I’ve also written that the AI agent security story is a disaster, full of frameworks that optimized for capability and treated permissions as an afterthought. Those two posts used to live in separate corners of my head, and Stripe has now connected them: the “act” step includes spending your money.
Acting on the world is different from talking about it
For most of the agentic era, the “act” step has been comparatively forgiving. An agent drafts a message a human approves. It opens a ticket someone triages. It reroutes a shipment that a dispatcher can override. When the act is reversible or supervised, a bad decision is an annoyance you can clean up later.
Payment is the first action in the mainstream agent stack that is irreversible by default and quantifiable in dollars. A wrong purchase can’t be retracted the way a bad message can; it becomes a chargeback, a vendor dispute, and money that has already left the account. The loop is no smarter than it was last month, but now it can lose real money when it gets something wrong.
The same property that makes agents useful, that they run continuously without a human in every cycle, is what makes a spending agent risky. A loop that transacts a thousand times an hour will transact a thousand wrong times an hour if the “think” step is off or the “sense” step gets poisoned.
The blast-radius problem, now denominated in money
When I was building Xively, the IoT industry learned the hard way that “connected” and “secure” are different properties, and it took botnets like Mirai to drive the lesson home. We’re at the same point with transacting agents, except this time a device joining a botnet would be the easy version. The failure mode is a corporate card draining at machine speed.
Prompt injection is the obvious vector. An agent that reads a webpage, an invoice, or an email to decide what to buy can be told what to buy by whoever wrote that content. We already knew injection could trick an agent into calling a tool it shouldn’t. Now one of those tools is a payment rail. A poisoned product listing or a forged invoice becomes a direct instruction to spend.
The Jedify development sharpens this. The more business context an agent carries (vendors, budgets, approval norms, who usually signs off on what) the more convincingly it can be manipulated into a transaction that looks legitimate. Rich context makes a competent agent, and it makes a competent forgery target. An attacker who learns how your agent reasons about spending has learned how to spend your money.
What I’d require before an agent of mine touches a payment rail
I run technology for a wealth management company supporting over $2 trillion in assets. In our world, an agent transacting wrongly means a bad trade, a fee, a movement of client funds, and a regulator who will want to know exactly how it happened. Here’s the bar I’d hold any spending agent to before it goes near production.
Scoped, revocable capability grants. The agent gets payment authority for a specific purpose, a specific set of merchants or merchant categories, and nothing else. No standing access to a general-purpose card. The grant is a token I can revoke in one call, and revoking it stops the next cycle of the loop cold. Default is no spend; every dollar of authority is explicit.
Hard, enforced spending boundaries. Per-transaction caps, per-day caps, and a global ceiling, enforced on the rail itself rather than in the prompt. An instruction in a system prompt is just a suggestion, and a model can be talked out of a suggestion. A spend limit enforced on the card can’t be argued with. Lean on Stripe’s own controls and virtual card constructs to do the enforcement, because the LLM’s good judgment won’t hold up under attack.
A human gate above a threshold. Below some dollar amount the agent acts autonomously. Above it, the act becomes a draft that a person approves. Treat the threshold as a business decision rather than an engineering default, and set it deliberately low when you first deploy.
Comprehensive audit trails. Every transaction logged with the full decision chain: what the agent sensed, what context it pulled, what it concluded, and what it spent. If I can’t reconstruct why the agent bought something, I can’t defend it to a regulator or a board, and I shouldn’t have shipped it.
Containment on the rest of the loop. The payment capability rides on the same security posture as everything else: sandboxed execution, no ambient credentials, and sub-agents that can never hold more authority than the parent that spawned them. The card is just the most expensive capability in a system that needs least privilege everywhere.
Don’t wait for the cautionary tale
Stripe shipping agent payments is the right call. This is where the technology was always going, and the companies that figure out autonomous commerce will have a real advantage. I’m not arguing against agents that spend money. I’m arguing that they need a wall around them before they do.
If you’re standing up an agent with any payment authority this quarter, do one thing this week before you write another line of orchestration code. Write down the exact spending envelope: per transaction, per day, total, allowed merchants, and the threshold above which a human has to approve. Then go verify that every one of those limits is enforced on the payment rail, not in a prompt. If it only lives in a prompt, it isn’t really a limit. It’s a hope that the model behaves, and no auditor I’ve ever sat across from will accept hope as a control.