Cloudflare and Stripe Have an Abuse Problem. The Email Industry Should Be Paying Attention.

Last month, Cloudflare and Stripe announced something new. They built a way for AI agents to set up internet services on their own. An agent can now register a domain, pay for it, get an API key, and deploy code. A human only has to accept the terms once. After that, the agent does the rest.

They called it “zero to production.” We see it differently. An agent can now build a real, working, paid website on a fresh domain in minutes. It can do this over and over. The only cost is a credit card.

Many things could go wrong with this. Most of them are not our problem. But some of them land directly on hosting providers, deliverability teams, abuse desks, and the people who run blocklists. Those problems are not getting enough attention.

We have spent twenty-two years running multi-tenant abuse-prevention infrastructure. That experience shapes what we see here. We have watched the email version of this story play out many times. It is worth saying clearly what the new version looks like.

The “born clean” problem

For twenty years, email defenders have built layers of trust. SPF. DKIM. DMARC. IP reputation. Domain age. Sender history. Every layer makes the same basic bet: new senders are riskier than known ones. Fresh domains have to earn trust slowly. New IPs warm up over time.

Agentic provisioning breaks that bet. When an agent can register a domain, set up DNS, deploy a sending app, configure SPF and DKIM, and get a TLS certificate in one workflow, the new infrastructure passes every check on day one. It looks clean. It has no bad reputation yet, but it has no good one either. It is born clean.

This is not a new problem in theory. Bad actors have always been able to set up new infrastructure. What changes is the speed and the cost. Disposable phishing infrastructure becomes much cheaper when an agent can build the whole stack in an afternoon. Domain. Hosting. DNS. TLS. Sending. All of it. Used once, then thrown away. Then built again.

Mailbox providers will adapt. They always do. But when they adapt, they tighten the rules for everyone. That means more legitimate new senders get caught in the filter. Warm-up gets slower. Honest businesses pay the price for an abuse problem they did not create.

Budget caps are not abuse controls

Stripe’s protocol sets a default spending cap of $100 per month per provider. That is fine as a fraud control. It is not an abuse control. The email industry should not treat it as one.

A hundred dollars buys a lot of throwaway domains and cheap hosting. It buys plenty of room to test and iterate. More importantly, the cap only limits one billing relationship. It does not stop an attacker using stolen cards, mule accounts, or many small agents working in parallel.

Anyone who has worked an abuse desk knows this pattern. The control that protects the provider’s books is not the same as the control that protects everyone downstream. Per-account rate limits protect the API’s billing. They do not protect Spamhaus, Gmail, Microsoft, or the next sender sharing an IP. Not when an attacker has fifty accounts, each running at 90% of its limit.

The framing matters. Budget controls are being sold as a safety feature. They are not. They are a fraud control. The real abuse question — how do you stop one bad actor from poisoning shared infrastructure — has not been answered. The email industry is downstream of that gap.

The speed gap

Email abuse handling is built around certain timelines. A report comes in. Evidence gets reviewed. Someone takes action. Sometimes it is the registrar. Sometimes the host. Sometimes the network. Sometimes the receiver. Even fast pipelines take hours. Blocklist updates add more hours after that.

This works against human-paced abuse. It works less well against scripted abuse. It fails against agentic abuse that can build, send, and abandon infrastructure faster than the abuse-reporting cycle can run.

The real concern is not that a single agent will outrun abuse handling. It is that the bar for running a “sophisticated” campaign drops sharply. Things that used to need a human operator with time and skill become easy. Anyone who can write one paragraph of instructions can run one. The number of campaigns goes up. The lifespan of each one goes down. Both trends hurt.

We have seen what happens when account-creation friction at one provider meets email infrastructure at another. Removing that friction at the provisioning layer pushes the abuse burden downstream. For outbound email, downstream means deliverability teams, mailbox providers, blocklist operators, and the hosts whose IP ranges end up next to disposable senders.

Reputation pollution is the downstream cost

The bill for all of this comes due somewhere. It usually comes due in shared reputation systems.

When a fresh domain with valid SPF and DKIM sends a convincing phishing campaign, the targets get hit first. But the deeper damage is to the reputation system itself. Trust scores. IP pool history. Domain-age signals. The basic assumption that “authenticated mail is legitimate mail.” Every successful “born clean” campaign weakens those signals for everyone.

Hosting providers know this pattern. The phrase “one compromised customer can blocklist a shared IP” is not marketing copy. It is the daily reality of multi-tenant sending. The answer to it is exactly the kind of detection, isolation, and cleanup infrastructure that does not yet exist at the agentic-provisioning layer. We have customers who saw email-related support tickets drop from 300 per week to about 10 after moving the abuse work upstream. Others saw a 90% drop in delivery tickets within weeks. That is what it looks like when the operational layer catches up to the problem.

The agentic-infrastructure conversation is years behind that. The protocol-level controls being announced are about identity and payment. The infrastructure-level controls are missing. Who is responsible for noticing an agent running an abuse campaign? On what timeline? With what evidence? With what way to shut it down? Nobody has answered these questions yet.

What the email industry should be asking for

There is a reasonable position the email-security community can take here. It is sharper than a normal vendor blog post. It is this:

The companies building agentic provisioning owe the downstream ecosystem more than spending caps. They owe identity that follows the agent across the whole chain. An agent operating across domain, hosting, DNS, and email should be trackable as one actor — not as a series of separate, individually-compliant resources. They owe abuse response that runs on the same timeline as the provisioning itself, not the old registrar-and-host cycle of hours and days. They owe transparency about what an agent has built, on whose behalf, with what permission. Reputation systems need something to attach to other than the fresh infrastructure itself.

One useful direction here is AAuth, a proposed standard written by identity pioneer Dick Hardt as an IETF draft. It would not solve abuse by itself, but would make the problem easier to manage by giving providers a protocol-level place to attach identity, authorization, audit, and revocation. Instead of treating a fresh domain, DNS change, hosting account, API key, and outbound-mail setup as separate clean events, each provider could see that the same agent is acting on behalf of the same accountable person or organization, under the same approved mission. A registrar, DNS provider, host, payment processor, or mail platform could then ask whether the requested action fits that mission, require stronger approval for higher-risk steps, log what happened, and revoke access when behavior changes. That moves the abuse problem upstream: defenders would no longer have to infer intent only from brand-new infrastructure; they could manage a chain of scoped, attributable, revocable authorizations across the whole provisioning path.

Where MailChannels sits in this

We are not a neutral party here, and it would be strange to pretend otherwise. We have spent twenty-two years building infrastructure that assumes the senders are only semi-controlled, the abuse is constant, and a real share of the safety work has to live in the operational layer. That experience shapes how we read announcements like this one.

What we would offer to the broader conversation is this. The protocols being written now will set defaults that are hard to change later. The email-security community has useful experience to share. We know what shared-reputation systems can handle. We know how abuse-response timelines really work. We know what “safe” tends to mean in multi-tenant environments where many independent actors share infrastructure. We would like to see that experience reflected in the agentic-infrastructure conversation while it is still being shaped.