Browser agents promise to book in your place, buy the ticket, and fill in the form. But over recent weeks, major sites have started closing their doors to them. Yelp says it allows only agents that pay for its data licensing program. Delta is blocking ticket purchases on users' behalf. JPMorgan Chase and Charles Schwab have confirmed they are blocking agent account access over security concerns. An agent's value scales with the number of places it can reach, and that number is shrinking.

What is actually confirmed

Drawing mainly on The Verge's October 17 report, here is the picture, separating confirmed blocks from user reports.

[Access blocks as of October 2026]

Confirmed at the company level
- Yelp            : allows only agents in its data licensing program
- Delta Air Lines : blocks booking tickets on behalf of users
- JPMorgan Chase  : blocks agent access to accounts over security concerns
- Charles Schwab  : same (blocks account access)
- Amazon          : banned Perplexity's agentic shopping, then sued

User reports (not company-confirmed)
- Sites such as Cars.com and Amtrak that "no longer work" with an agent
- Accounts using Meta Muse flagged by Google for "suspicious activity"
- Checkout issues on Walmart despite the Meta partnership

The symptoms show up across users of Meta's Muse, xAI's Grok, OpenAI's Dots, and Instinct. Amazon is the interesting case. It banned Perplexity's agentic shopping and sued back in 2025. A court ordered Perplexity to stop, but in August 2026 an appeals court overturned that ruling, and Amazon filed an amended complaint. Meanwhile, Amazon blocked Meta's Muse too.

Two distinct failure modes

The distinction matters, because the fix differs. Agents get blocked in two ways.

[Failure mode 1: deliberate policy blocks]

Sites that block "on purpose"
- data licensing (Yelp)
- legal liability and fraud risk (financial accounts)
- advertising revenue (fewer human eyeballs)
-> solved by negotiation, licensing, or an official API


[Failure mode 2: anti-bot systems misfiring]

Sites that do not target agents but block them anyway
- safeguards built to stop scrapers and fraud bots treat agents the same way
- e.g. Google flagging an account as "suspicious activity," checkout failures
-> a technical or protocol problem, and one that can damage a user's account

Chris Canal, CEO of the AI-safety evaluator EquiStamp, explains the second mode: these systems were never built to block agents but to block scrapers and scams, and agents trip exactly those safeguards. As a result, legitimate agents trying to book or pay get classified as bots.

Why sites block

The most direct interest is advertising. Perplexity argued that Amazon blocks agents because it gets fewer human eyeballs in front of its ads, which is a real issue in ecommerce. When an agent pays instead of a person, ad impressions and product browsing time fall.

So the landscape splits in two: blocking, and conditional opening.

[Block vs open with conditions]

Blocking
- Amazon: banned Perplexity's agent, then sued
- Delta, JPMorgan, Charles Schwab: access blocked

Opening with conditions
- Yelp: opens to agents enrolled in its licensing program
- Meta: partnered with Walmart, Gap, Sephora, Best Buy so Muse can shop
- Shopify: opened its storefront catalog to more AI agents

In other words, the question is moving from "will you accept agents" to "on what terms and through which channel." Infrastructure providers joined in too. Cloudflare shipped a one-click block for AI crawlers in 2025, then began blocking multi-purpose crawlers that scrape for both search indexing and AI training at once, tied to the concern that crawler growth strains internet infrastructure (the EFF's point about the "weight" of AI crawlers).

The cost: humans get annoyed too

Canal argues these blocks may make the web more annoying. As more sites roll out interfaces to prove you are not a robot, a person ends up jumping through hoops just to use a grocery cart.

[Growing human-verification gates]

- "I'm not a robot" checks and image puzzles
- extra login and identity-verification steps
- account-level anomaly detection

-> legitimate people and legitimate agents stop at the same gate

For developers building agents

This turns "I built a browser agent and the site blocks it" from an exception into a normal state. The design principles:

[Design principles for web access in agents]

Choosing an access path
- [ ] Prefer an official API when one exists (more stable than browser automation)
- [ ] Otherwise look for a formal channel via licensing or partnership (e.g. catalog feeds)
- [ ] Keep browser automation as a last resort; check the terms of service and robots.txt

Treating blocks as normal
- [ ] Model 401/403/429, login walls, and captchas as expected states
- [ ] On a block, stop safely and hand off to a human instead of retry-storming
- [ ] Do not hammer the other server or endanger the user's account with retries

Protecting the user
- [ ] Run irreversible actions (payment, booking) behind human approval
- [ ] Avoid patterns that can get a user's account suspended (mass logins, etc.)
- [ ] Minimize handling of personal and payment data, and keep logs

Operations
- [ ] Record which sites blocked you, when, and why
- [ ] On policy changes, switch routes or disable the feature

The core is putting "what happens when we are blocked" into the first step of design. The success rate of browser automation depends on the other site's policy, and that policy changes without notice.

What to choose

The right answer differs by task.

Task Recommended path Why
Reading public data Official API or licensed feed Clear policy and billing, stable
Flight and hotel booking Official booking API first, browser automation as backup Ticketing and payment carry high block risk
Financial account access In principle, a human does it directly High security and legal responsibility
Shopping that requires payment Partner or licensed channel Avoid block and lawsuit risk
Simple data entry and cleanup Browser automation is fine Failure is reversible

Limits and unsettled questions

This story is still moving. Worth keeping in mind.

[Caveats]

- This is not a blanket block of all AI agents; policy differs by site
- Many reported blocks are user reports; only some are company-confirmed
- Much of the blocking is not aimed at agents but a side effect of general bot defense
- The Amazon v. Perplexity case was reversed on appeal and is still ongoing
- "Just use the official API" is also conditional; check API terms and access rights

Conclusion: access is a premise, not a feature

Whether a browser agent succeeds depends less on model quality than on whether the other side opens the door. So the questions shift: can this task be done through an official API; can a formal channel be opened through licensing; and what do we return to the user when we are blocked. Blocks have to be designed for as a default state, not an exception.

That is why building a small in-browser automation yourself brings the feel quickly. You learn which screen raises a login wall, which request invites a block, and how to stop safely on failure. The basics of web automation are in AI Vibe-Coding Web Development; the background on crawler controls is in Cloudflare's Web Search API Gateway; and the search-and-fetch API approach continues in Wiring Agent Search with DeepSeek's Search and Fetch APIs.

Further reading

References

Go deeper with a course

In-browser automation comes together when you build a small tool yourself. Hitting a login wall or a block response, and designing the tool to stop safely on failure, shows why access is a premise rather than a feature.