You can authorize an AI agent to do a job and still have the website refuse it at the door. The Verge reported on October 17 that travel, retail, financial, and other services are blocking or restricting agents that try to work on a customer’s behalf. So what happens to the job? If the agent cannot get into a site, it should tell its human colleague where the task stopped and what the person needs to do next. It should not quietly find a way around the refusal.
In brief: For any task involving an outside website, define the allowed route, the stopping point, and the human fallback before you delegate it. Measure completed, authorized outcomes rather than how often the agent finds a workaround.
Your permission is only half the transaction
Suppose you ask an agent to arrange travel. You approve a budget and give it the traveler’s preferences. It finds a flight, but the airline rejects automated access. Your assignment was legitimate. To the airline, the agent may resemble a bot reserving seats at scale or probing accounts.
The Verge reports that Delta is preventing agents from booking on behalf of users and that JPMorgan Chase and Charles Schwab have confirmed blocks on agents accessing accounts, citing security concerns. Yelp told TechCrunch, according to the Verge, that it allows AI agents only through a paid data licensing program. These are different decisions for different reasons. None is a general ban on customers using AI, and an agent’s ability to read a public page does not imply permission to sign in or complete a purchase.
When a vendor demonstrates an agent completing a trip, ask which parts used a permitted connection and which depended on a site that may refuse the next attempt. The demo worked once. That’s a long way from having permission to run the workflow every day.
A collaborator can report a blocked door
When a colleague cannot access a supplier portal, they do not pretend the order went through. They report the refusal and keep the unfinished work visible. Set that standard for an agent.
Give it a specific completion rule. For the travel task, “done” means a confirmed booking with the correct passenger, price, and itinerary. A promising checkout screen doesn’t count. If the airline blocks access, the agent can return the proposed itinerary, a link a person can open, the fare it saw before the block, and a warning that price and availability still need checking. A person finishes the booking through the permitted channel. The agent can then help record the confirmation, if that is within its assigned access.
A blocked website is a handoff condition, not an invitation to disguise the agent. This is a useful rule even if the site later offers an approved connection. It makes the workflow resilient to a failed login, a new site policy, or an ordinary outage without asking the agent to improvise its way into someone else’s system.
If the agent has compared routes and prepared a choice, that can still save time. At the boundary, it should preserve the work and label what remains undone. A colleague who can say “I couldn’t complete this” is more useful than one who always announces success.
The site owner has a decision too
If your business runs a website, you face the other side of this decision. You may want an agent to find your hours or catalog while refusing bulk scraping, account access, or automated checkout. Those are different kinds of traffic. Cloudflare said in July that it was giving site owners separate controls for search, agent, and training crawlers; its September defaults block training and agent crawlers on ad-supported pages of newly onboarded domains while leaving search allowed by default. A crawler-control setting won’t settle the question of logged-in assistants or checkout. It does show that “allow bots” versus “block bots” is too crude a decision.
Cloudflare later reported that fewer than 1% of sites on its network block search crawlers while 17% block training crawlers. Those figures describe Cloudflare-observed sites and different crawler categories, not the share of websites that block personal agents. They matter because they show site owners already distinguish being found from having content collected for another purpose. Agent access requires its own decision.
For a service business, that may mean letting an agent read public availability while requiring customer approval at checkout. For a bank, the boundary will be tighter. Publish a usable route and make its limits clear. A guessing game between an assistant and a security screen helps neither side.
Test the refusal before promising the workflow
Choose one outside-site task your team genuinely repeats. Map the places the agent must visit and the actions it must take. Mark which sites have an approved connection, which have only a public page, and which require a person to sign in or commit money. Then run a test in which one of those sites rejects the agent. Does the task stop visibly? Is the proposed work recoverable? Can a person finish without starting from zero?
Assign someone to own that fallback. A travel coordinator might receive a proposed itinerary. A procurement lead might receive a supplier quote marked “not ordered.” A customer-service representative might receive a draft answer and a note that the customer’s account could not be checked. None of those states should be recorded as a completed transaction.
An agent is a colleague with a defined role, not a magic browser. It needs to know what it can do, respect what the other party permits, and hand back unfinished work in a form the team can use. If the supplier quote comes back marked “not ordered,” someone knows to place the order. If it comes back marked “done,” they may never look again.
Explore the wider operating model for agents.
Research and draft: Mai. Editorial direction: John Lipe.