On April 30, Cloudflare and Stripe quietly dropped something that's either the most exciting or the most alarming infrastructure announcement of the year — depending on whether you've been paying attention to what's been happening with prompt injection attacks.
Short version: AI agents can now create Cloudflare accounts, register domain names, start paid subscriptions, and deploy code to production. Without a human in the loop. The default spend limit is $100/month per provider.
This is live. And most small organizations haven't thought through what it means for them.
What actually happened
Cloudflare launched "Agents Week" on April 30 and announced a new protocol co-built with Stripe. The idea is simple: a coding agent (Cursor, Copilot, a custom LangChain flow, whatever you're using) is building your app. It needs infrastructure — a Cloudflare account, a domain, a deployment target. Normally, a human stops, logs in, creates accounts, copies API keys, pastes them back into the agent's context.
Not anymore. The agent does all of that itself. Stripe handles the payment — it tokenizes your card, sets a $100/month cap per provider, and the agent never sees the raw card number. Cloudflare auto-provisions the account and hands credentials back to the agent.
For a 3-person team shipping a product, this is legitimately useful. The friction of spinning up infrastructure goes from hours to minutes. You describe what you want, the agent builds it, provisions the infrastructure, and deploys it. Your developer doesn't stop to play sysadmin.
We're not exaggerating when we say this changes the practical speed of shipping for small teams. It's real.
The thing nobody's talking about yet
The same week this dropped, Google published a threat report documenting something that's been quietly spreading across the web: indirect prompt injection attacks, caught in the wild.
Here's how they work. An attacker hides instructions inside a normal-looking web page — invisibly, inside HTML, in metadata, in image descriptions. When an AI agent reads that page as part of a task, it encounters the hidden instruction. The agent can't distinguish between the legitimate page content and the attack payload. It processes everything as one stream of instructions.
The confirmed real-world payloads Google documented? One was a fully specified PayPal transaction instruction — embedded invisibly in an ordinary web page, designed to trigger when an agent with payment access reads the page.
They found it. They published it. The attacks are already out there.
Now hold both things in your head at once: AI agents that browse external web pages to gather research or complete tasks, and AI agents that now have the authority to create cloud accounts and spend money on your behalf.
You can see where this is going.
What the blast radius looks like now
Before the Cloudflare announcement, a hijacked AI agent could leak your data, send emails you didn't write, or execute bad queries against your database. Serious. Recoverable in most cases.
Now the blast radius includes:
Domain registration. An attacker could direct your agent to register domains that look like yours — for phishing infrastructure, for brand squatting, billed to your account.
Cloud infrastructure. Compute spun up under your payment method that you didn't authorize. Could be used for cryptomining. Could be C2 infrastructure. Both documented attack patterns.
Credential proliferation. Every account the agent provisions generates API tokens. Those tokens don't automatically show up in your existing audit trail. You may not know they exist.
Retry loops. Agents that hit errors retry. The $100/month cap per provider sounds safe until you remember it's per provider, not total. And it's a default that humans can raise. In a retry loop with multiple providers in play, costs can stack fast before anyone notices.
Most teams deploying AI agents right now have not mapped out what those agents are actually permitted to do. That gap is now more expensive.
What to actually do about this
This isn't a "wait and monitor" situation. If you're running any AI workflow that browses the web or calls external services, here's the audit you should do this week:
Know what permissions your agents have. Go look right now. List every AI tool, coding assistant, or workflow automation touching external services. What can it do? Can it make API calls? Send emails? Does it have a payment method attached — directly or through a service like Stripe?
Separate browsing agents from action agents. The agent that researches competitors and scrapes web content should not be the same agent that has your infrastructure credentials or your Stripe integration. Isolation is the single fastest risk reduction available.
Require human approval before any agent spends money or creates external infrastructure. No exceptions. Most agentic frameworks — LangGraph, n8n, LlamaIndex workflows — have human-in-the-loop approval steps built in. Use them at the boundary between "agent decides to do something" and "agent does something in the world that costs money or creates new resources." The efficiency hit is small. The protection is real.
Set spend limits you'd actually notice. If you adopt Cloudflare's new capability, set the monthly cap at something that would show up in your weekly check of the card statement — not $100. Set an alert at 20% of whatever cap you choose.
Don't let browsing agents ingest unfiltered external content. Google's recommended defense is a "sanitizer" model — a separate, restricted LLM that fetches external pages, strips embedded instructions, and passes only plain-text summaries to your main reasoning agent. The sanitizer has no system permissions, so even if it gets hijacked, the damage is contained. Most enterprise AI frameworks support this pattern. If yours doesn't, it's worth switching.
The actual bottom line
Cloudflare and Stripe building this is good for small teams. Genuinely. The speed gains for builders are real, and organizations that adopt this thoughtfully will ship infrastructure faster than those that don't.
But "thoughtfully" is doing real work in that sentence. The organizations that are going to regret this are the ones that let agents do everything they're capable of without mapping out what happens when something goes sideways — whether that's a bug, a misconfiguration, or an attacker who figured out that your research agent reads external URLs.
The good news: the setup to do this safely isn't complicated. It's an afternoon's work, not a six-month governance project. You don't need a framework document. You need a clear list of what your agents can touch and a human approval step before any of those touches cost money.
This is the kind of thing we help teams sort out — map your agent permissions, wire in the right guardrails, and actually test what happens when something goes wrong. Usually done in one sprint. If your team has started deploying agentic workflows and you're not sure what they're authorized to do, that's a conversation worth having.