Imagine you built the perfect travel agent. It finds the cheapest flight, asks your user to confirm, waits for the "yes", and books it. No hallucinations, no surprise upgrades, a human in the loop at every step.
As of November 11, United Airlines says that booking is against its rules. And it can cancel it.
Not because your agent did anything wrong. Because it's an agent.
What actually changed
On November 11, 2026, United revised its Contract of Carriage, the legal document every passenger agrees to when they buy a ticket. It now defines an "AI Agent" as:
"any software or service, including but not limited to an AI assistant, AI agent or AI-enabled browser that takes autonomous or semi-autonomous action, whether or not Passenger or another individual supervises or approves its actions…"
Read that middle part again: whether or not Passenger or another individual supervises or approves its actions. Your carefully designed approval step doesn't count.
The definition then names who it covers: AI assistants built into social media, messaging, search or other consumer platforms; AI-enabled browsers; and standalone AI agents.
The contract's list of prohibited practices now includes:
"The use of AI Agents to make, modify or service a Ticket, and/or to purchase any service or product."
And the list of bookings United may cancel now ends with "reservations made, modified or serviced by AI Agents."
The press release adds the scope: United is restricting access "directly within our digital platforms and indirectly via travel agencies and aggregators."
United's three reasons
United's announcement gives three:
- Sharing account credentials with personal, third-party AI assistants "can expose sensitive information".
- Actions taken by these tools "may result in unintended purchases, account changes, or use of MileagePlus miles".
- Automated actions could violate FAA and DOT rules. Their example: flight check-in "requires human acknowledgment that bags do not contain banned substances like explosives".
It also says leaders in banking and retail "have taken similar actions". So this is unlikely to be the last "no" your agent hears.
The uncomfortable questions
Most of the agent demos we see in 2026 skip these. United just put them in a contract.
1. Whose permission does your agent actually have?
Your user said yes. But the user doesn't own the airline's website, its fares or its checkout. Consent from one party was never authorisation from the other. We just got used to treating the web as if it were.
2. Is "human in the loop" a real safeguard, or a UX pattern?
United's wording says supervision doesn't change anything. That should make every builder ask what their approval step really proves. Did the human read the fare rules? The change fees? Or did they tap "Approve" on a summary the agent wrote?
3. Are you building on borrowed logins?
Many consumer agents work by logging in as the user and driving the website like a person would. That means holding someone's password, session or loyalty account. It's exactly the first risk United names. If your product only works because a user handed over their credentials, you're one policy update away from not working at all.
4. Who pays when the agent is wrong?
"Unintended purchases" is a polite phrase for a support nightmare: a wrong date, a non-refundable fare, miles spent that shouldn't have been. Today, nobody has clearly agreed who absorbs that cost. One of the biggest airlines just told us it won't be them.
5. Should an agent ever say "I confirm" on a legal declaration?
The check-in example is the sharpest one. "These bags contain no banned substances" is a statement a person makes, under rules with real consequences. An agent clicking that box is not a convenience feature. It's a person's declaration made by software.
6. What happens when everyone does this?
If airlines, banks and retailers all close the side door, agents that depend on scraping and auto-clicking will hit the same wall everywhere. The question isn't whether your agent works today. It's whether it's built on anything the other side agreed to.
What we'd build instead
We build AI agents for clients, so this isn't abstract for us. Here's where we'd draw the lines:
- Use the seller's door, not the user's keys. Official APIs, partner programmes and affiliate deals exist for a reason. They come with terms, rate limits and liability that someone agreed to.
- Never store a user's password. If a service offers scoped tokens or OAuth, use them. If it offers nothing, that's an answer too.
- Put a human tap before money and before declarations. Not "approve this plan", but "you are paying $412, non-refundable, from this card". Let the person make legal statements themselves.
- Design for "no". When a merchant blocks agents, hand the user a ready-to-finish link instead of fighting the wall. A graceful handoff beats a cancelled booking.
- Be honest about what you are. Agents that identify themselves can be given permissions. Agents that pretend to be people get banned.
The real question
United didn't ban AI. It banned AI that acts on its systems without its say-so. That's a line many more companies will draw, and it's a fair one to argue about.
So two questions, one for everyone and one for builders:
Would you let an AI book your flights?
And if you're building that AI: did the seller ever say yes?
We made a 60-second video on this story:
Sources
- United Airlines, "United Restricts Access for Third-Party AI Agents", November 11, 2026: https://united.mediaroom.com/news-releases?item=125496
- United Contract of Carriage (revised November 11, 2026): https://www.united.com/en/us/fly/contract-of-carriage.html
Cover photo: Oleg Yunakov, CC BY-SA 4.0, via Wikimedia Commons.
Logit Solutions AI is an AI product studio. We design, build and support production-ready AI products for startups and growing businesses.
Top comments (1)
The uncomfortable part isn't really about AI. A user's yes settles things between the user and the agent — it never bound the counterparty. Consent turns out to be layered: the person asking, the agent acting, the platform whose inventory it is, and each layer can veto the ones below it. I learned to design for that explicitly: before a flow goes live, list who can say no at each step, including the parties who never appear in the UI. 'The user confirmed' feels like the end of the checklist. This story is what it looks like when it was only the middle of it.