The web has started slamming its doors on AI agents. Delta won’t let one book a ticket. JPMorgan and Schwab block them from accounts “for security.” Yelp admits only agents that pay into its data program. Amazon banned Perplexity’s shopping agent and sued. Users report Meta’s Muse, xAI’s Grok, OpenAI’s Dots, and Instinct hitting walls at Amazon and elsewhere; Cars.com and Amtrak quietly stopped working.
The coverage treats this as a messy, many-sided fight. It isn’t. There are exactly three reasons to block an agent — and in every legitimate one, the fix is on your own side, and no ban is ever needed. Here are the three, briefly, so you can hold them in your head. Then we’ll walk some real cases through them — and then, because the remedy turns out to point at a particular kind of machine, we’ll follow it there.
The three reasons
One — abuse. The agent is attacking you: hammering your server, brute-forcing a login, scraping at a scale no person could. This is a denial-of-service problem, and blocking it is completely legitimate. The solution is the oldest one in the book — standard cybersecurity: rate-limit, throttle, block. But notice what you’re blocking. You’re blocking a behavior, not a category of software. You ban the attack the same way you’d ban any abusive traffic, human or not. If Muse hammers your server, tell it to go pound sand — that isn’t “blocking agents,” that’s just running a server.
Two — your business model. Your model was built for a world where some action was hard, and the agent makes it easy. Banks earn on idle cash that sits still because, until now, moving it was annoying. It is legitimate to defend the business model you actually have. But — again — no ban is needed. Provide a proper API. Expose only the capabilities your model actually supports. Configure your own side. Your website was built for humans and never needed rate-limiting, because only humans were using it; now that bots can drive a browser, you’ll have to add the standard protections. Sorry — that’s just how it is now. (And keep this one in the back of your mind — we’ll come back to it at the end.)
Three — extraction. You’re not defending a service. You’re defending your ability to manipulate. You’re lying, and you’re at war with your own customers — wasting their time, burying the exit, nudging them into things they’d never choose. And they’re on to you. They send the agent in precisely to get what they came for without wading through your manipulation. This is the part everyone misreports as “convenience.” It isn’t. People know they’re being worked — they know an ad is an ad and a dark pattern is a dark pattern — and they are tired of it. So they send in the bot. If this is you, you aren’t blocking a piece of software. You’re a liar blocking your own customer for refusing to be fooled.
The principle under all three
You ban behavior, never a category of software. Name the behavior you object to. If you can name it — too many requests, a login being brute-forced, a scraper flattening your servers — then block that, and you never needed to mention “agents” at all. If you can’t name a behavior, and you’re reduced to banning a category — “no AI agents” — that is the tell. It means the only thing the agent did wrong was serve the customer too well.
One clean corollary: if you publish a bot-legible API and route machines to it, then blocking bots on your human-facing site is perfectly fine — keep the human door for humans and send the machines to the machine door. That’s just reason one again.
Walking the cases
- Muse hammering a server; generic anti-bot tripping on automation. Reason one. Legitimate. Throttle it. (As the coverage notes, most of these safeguards were built to stop scammers and scrapers, and agents trip the same wire — that’s fine; it’s the behavior being caught, not the agent.)
- Banks blocking account access “for security.” Mostly reason two wearing a reason-one coat. The honest fix is an API with sensible caps on what the model allows — not a blanket ban. When a bank says “security,” ask it to name the behavior. If it can, fix that. If it can’t, the real reason was the business model, and the honest answer is still: build the API, don’t ban the customer.
- Amazon blocking Perplexity. Reason three, and Perplexity said so out loud: Amazon won’t get “as many human eyeballs in front of its ads.” Amazon doesn’t sell shoes; it sells attention, and the agent buys the shoes without paying in eyeballs. No behavior to name, so it bans the category and calls it policy. People send agents to Amazon because they’re tired of the manipulation. That’s not safety. That’s a liar blocking a customer.
- Yelp’s pay-to-access. Reason two, the honest edge: the data genuinely is the product. Then sell it — a licensed API, a paid tier. That’s defending your model correctly. Banning a user’s own assistant from a page the user is already allowed to see is not.
How they actually tell
Stand at the door and ask how a site even knows an agent is there. Every method falls into one of two families, and the split is the whole story.
The first family reads what you are. A robots.txt file that names crawlers and asks them not to come in — advisory, not a lock; it stops nothing at the wire. A user-agent string that announces “I am a bot,” cut down by a one-line rule at the edge. A datacenter IP address, because real people come from home and phone networks and machines come from the cloud. A client fingerprint that gives away a headless browser pretending to be a real one. All of these catch a category. None of them watches behavior at all.
The second family reads what you do: the request rate, the volume, the inhuman cadence, the login hammered a thousand times a second. This is the family that catches reason one, and it catches it honestly — because a real abuse has a behavior, and a behavior can be named and limited.
Line the two families up against the three reasons and the whole thing snaps into place. The legitimate blocks are all behavioral — they name what you did. The illegitimate ones have no behavior to point at, because the user did nothing wrong, so they fall back on the badge: datacenter, user-agent, “you’re an AI, respect our decision.” A real safety concern names a behavior and answers it with a limit. A fake one names a category and demands a ban.
So build the thing with no badge
If every honest block watches behavior and every dishonest one reads a badge, then the right machine is obvious: one that has no badge to read. Drive the user’s own browser, in their own session, from their own IP address. Call it Waldo. There is no datacenter hop, no declared bot, no headless fingerprint, no separate third party at all — it is the user’s real browser doing what the user asked, one page at a time. Against the entire family of category blocks there is simply nothing to detect. It isn’t that Waldo is hard to catch. It is that there is nothing there to catch but a person reading a page they were always allowed to read.
Which means it leaves every honest throttle standing and dissolves every “no agents” ban. The abuse limits still apply — and should; if you make a session do something no human could, the behavioral family catches you, exactly as it should catch anyone. But the war-on-the-customer ban has nothing left to grab, because the only thing it ever had was the badge.
And here is the part that keeps it honest, because honesty is the whole point. When you are sitting at your keyboard and it drives your browser, it is Chrome — truthfully, because it is Chrome. A user-agent answers “what client software is this,” not “is a human or an assistant at the wheel,” and a site is owed the first answer, never the second — no more than it’s owed to know you use a screen reader or a password manager or reader mode. But when the same work runs unattended, from a machine in a datacenter, then it is a bot, and the honest thing is to say so: wear the badge, declare yourself, obey the robots.txt, respect the limits. Identify as what you actually are, in each case. The one move never made — the move that turns an assistant into a liar — is to run unattended automation while wearing the user’s clothes: the home IP, the real browser, a present human implied when nobody’s home.
So when a site refuses the honest unattended bot — bans it not for anything it did but purely for being a machine in a datacenter — the answer isn’t to fight or to disguise. It’s to wait for the person. The work sits in a queue marked needs you present; the next time you’re at your machine, it runs there, as you, honestly. The block stops being an enemy and becomes a routing rule: this one only runs when you’re home. No arms race, no evasion, no faking. Just the truth, told in whichever of the two modes is true at the time.
The point
The web isn’t closing its doors to agents. A handful of businesses that cannot name a single behavior to object to are closing their doors to their own customers — and hoping the word “safety” on the sign makes you turn around. Name the behavior. Everything legitimate has a fix on your own side. Everything that doesn’t was never about safety at all. Their technology can be banned for what it is; a user’s own browser can only be limited for what it does — and what it does is read the page you came to read.
And here’s the part worth staying for. If your model ran on manipulation, and manipulation has stopped working — if people will now simply send something in to route around it — then the question was never how to keep the doors shut. It’s what you build once you no longer need them shut. Nobody knows yet what banking becomes when money moves freely, or what a store becomes when no one can be tricked into the upsell. That isn’t the threat in this story. That’s the opening — and it’s going to belong to whoever stops defending the old doors and starts asking the better question.