When an AI Agent Reaches the Checkout: What United’s Restrictions Mean for Business Automation

United's restrictions on unauthorised AI booking agents reveal a practical boundary in business automation. An assistant's ability to complete a task does not establish permission to transact, making supplier agreements, approval controls and recovery processes central to adoption

An assistant that can research a journey, compare options and complete a purchase appears to offer a straightforward business benefit: less administrative work between a decision and its execution. Yet a transaction involves more than the intentions of the person requesting it. The supplier also determines which systems may access its services and under what conditions. On 11 November, United announced restrictions on unauthorised third-party personal AI agents, covering access through its own digital platforms and indirectly through travel agencies and aggregators. The airline said its booking, ticketing and distribution policies would be updated. This is a concrete reminder that technical capability and commercial permission are separate parts of automation.

United cited exposure of account credentials and the possibility of unintended purchases, account changes or use of loyalty miles. It also raised regulatory concerns. These are the airline’s stated reasons, rather than independently measured incident rates or a new law banning AI bookings. PhocusWire reported the change on the same day. For businesses, the useful question is broader than whether one airline accepts a particular tool. It is how an organisation can make an automated purchasing process dependable when permission, price, availability and responsibility are distributed across several parties. A small travel practice and a large corporate procurement team can encounter different versions of that problem.

Start with the action the business wants to delegate

The word assistant can conceal several different activities. One tool might summarise information supplied by an employee; another might navigate a supplier’s website; a third might submit a booking and charge a payment method. These activities place different demands on the business, even if they appear inside the same conversational interface. An illustrative travel agency could find value in drafting an itinerary while retaining human control of the final reservation. That would be a possible workflow to assess against the relevant suppliers’ terms, not a claim that any particular use is permitted. Defining the delegated action precisely is the first step towards deciding what information and authority the tool actually needs.

This helps avoid an adoption decision based only on a convincing demonstration. A demo may show that an agent can reach a confirmation screen under favourable conditions. A business needs to know what happens when the price changes, an option disappears or a response arrives too late. The purpose of automation should therefore be stated as a business outcome, such as reducing repetitive preparation while preserving accurate purchasing decisions. That leaves room to automate part of a task rather than its entire sequence. A deliberately limited workflow can still be valuable if it removes effort from a recurring stage without creating a larger verification burden elsewhere.

A customer’s instruction does not settle every permission

A person can want an agent to act for them while the supplier declines access through that channel. United’s statement makes that distinction visible, but the organisational lesson can be analysed without extending its policy to other companies. A business assessing an agent should examine the permissions of the services on which the task depends, as well as its own internal approval. The question is not whether the agent appears to behave like a person in a browser. It is whether the proposed interaction is supported by the parties and systems required to complete it. That assessment belongs before a deployment is relied upon for routine operations.

For an intermediary, the dependency can be especially important. A travel agency may promise service to a customer while depending on an airline and a distribution provider to fulfil the booking. An illustrative automation that works on one channel could therefore fail when another participant changes its access rules. A sensible operating design would record those dependencies, assign someone to monitor relevant policy changes and provide an alternative process. These are proposed management practices, not findings that United has validated. Their value is in making a fragile assumption visible: a task that succeeded yesterday does not necessarily remain an authorised, supported transaction route tomorrow.

Structured commerce offers a different design approach

There are efforts to make agent transactions explicit rather than have software imitate a human checkout. In its description of the Agentic Commerce Protocol, Stripe explains a programmatic flow connecting buyers, agents, sellers and payment providers, with the buyer granting permission to initiate checkout. Its agentic-commerce guide also describes shared payment tokens scoped to a seller, amount and time window. These are supplier descriptions of available approaches. They neither establish United’s acceptance of a channel nor demonstrate that a particular agent integration is safe or commercially worthwhile.

The design principle is nevertheless useful: separate the ability to ask for a purchase from unlimited access to an account or payment credential. In an illustrative business workflow, an approval could specify a particular order and a maximum cost, while changes outside that scope would return to a person. That is a proposed control, not a guarantee that every platform implements it. The business should examine how authority is represented, checked and withdrawn at each step. A narrow permission also makes a failure easier to investigate because it provides a clearer record of what the tool was allowed to do, rather than relying on a broad conversational instruction remembered differently by different participants.

Completion must mean a verified business result

A purchasing agent can encounter ambiguous outcomes: a request may have been accepted even though the response was interrupted, or a payment may exist without the expected confirmation. These are hypothetical failure cases that an organisation could include in testing. Retrying blindly could create duplicate work or duplicate transactions. The operational question is therefore how the business establishes the authoritative state of the order before acting again. A clear confirmation from the relevant supplier or system should be distinguished from the agent’s own summary of its activity. The same discipline applies to changes and cancellations, where an attempted action and a completed action can have very different consequences.

Recovery deserves attention alongside execution. A proposed pilot could examine whether staff can find the transaction record, identify who approved it and use a supported process to correct a mistake. It could also test whether the agent stops when required information is missing. Those checks would give managers evidence about the workflow they are considering, although they would not prove reliability under every condition. The practical aim is to keep an uncertain outcome from becoming an unobserved business commitment. A tool that completes routine cases quickly may still require substantial support if exceptions are hard to diagnose or if no one knows which participant can resolve them.

Evaluate the whole cost of a shorter task

The business case should include more than the minutes saved while an employee watches an agent work. Setup, access management, policy monitoring, staff training and exception handling all consume capacity. A useful evaluation could compare a clearly defined task with and without assistance, measuring accuracy, total staff effort and the frequency of unresolved outcomes. This is an evaluation proposal; United’s announcement supplies no return-on-investment figure for businesses using agents. The value of time saved would also depend on what happens next. Capacity released for customer service is different from a theoretical saving that cannot be converted into a meaningful operational improvement.

For a small firm, a bounded experiment may be more informative than a broad commitment. An illustrative agency could examine internal drafting or comparison work with non-sensitive examples while keeping transactions in an established process, subject to supplier permissions. A larger organisation might investigate supported integrations and more formal approval structures. Neither route is automatically superior. The appropriate scope depends on the volume of work, the consequences of an error and the resources available to maintain the process. The key is to avoid importing the costs of complex automation into a task whose existing method is already simple, reliable and inexpensive.

An agent strategy includes choosing where to stop

United says it will continue evaluating personal AI assistants as they evolve. That leaves the future open without establishing that a broader acceptance programme is imminent. More generally, businesses should expect agent adoption to depend on relationships between organisations as well as model performance. A better ability to navigate screens or interpret instructions cannot by itself create an agreed transaction channel. Buyers need clarity about what they have approved, sellers need confidence about the requests they receive, and intermediaries need a way to support the result. Those requirements are part of the product and operating model, not administrative details to resolve after deployment.

The practical lesson is to treat the boundary of delegation as a business design decision. An organisation can use AI to reduce preparation work, investigate supported transaction methods and preserve human approval where it remains necessary. It can also decide that a particular action is not ready for automation. Such decisions should follow evidence about the complete process rather than enthusiasm for a tool’s apparent autonomy. United’s restriction is news because a major supplier has drawn an explicit access boundary. Its broader relevance is that useful business AI must operate within a network of permissions and dependable confirmations, so that completing an action also means completing a transaction the organisation can stand behind.

Image credit: Airport seating in Frankfurt by Dennis Gecaj, used under the Unsplash License. Illustrative photograph, unrelated to United or any AI booking service. Resized for this site; WordPress may crop display versions.

See other related publications