When the Counterparty Says No: Agent Identity as the Real Blocker

On 11 November 2026 United Airlines published a policy restricting access for third-party AI agents. Read as travel news, it is a carrier tightening its website. Read as an architecture signal, it is the first well-documented case of a counterparty withdrawing consent from an agent it could not identify.

Enterprise agent programmes rest on an assumption that has never been tested at scale: that the counterparty is passive. The API answers, the portal accepts a session, the supplier takes the order. United's announcement breaks that assumption by treating access as a privilege the counterparty grants and can withdraw. Nothing in a typical readiness assessment covers this, because the assessment measures reachability, and a refusal is not a reachability problem.

The Refusal Is About Identity, Not Capability

United's stated concern is specific. The release warns that “sharing account credentials with personal, third-party, AI assistants can expose sensitive information”. That is narrower than "agents are bad at booking", and worth taking literally, because the mechanism it describes is the one most enterprise agents still use.

To act on a system built for people, an agent needs a person. It gets one by borrowing that person's session — a stored login, a delegated cookie, a password in a vault, a service account with the operator's entitlements. From that moment the identity question has no answer. The system sees the employee; the employee sees an outcome; nobody sees the agent.

This is not a nuance of consumer travel. The same pattern appears wherever an agent is given a shared admin login because provisioning a proper principal would take a quarter, wherever a bot user is created with the operations lead's role because role design is slower than onboarding, wherever an agent holds a team-scoped token rather than one of its own. In each case the agent has permissions but no identity: every entitlement of the human it stands in for, none of the accountability.

The consequence is an evidence gap more than a control gap. A disputed purchase, a reversed profile change, a clawback of loyalty currency — each requires separating what the human decided from what the tool did. Where the credential is shared, that separation cannot be reconstructed after the fact.

Three Failure Modes, One Root Cause

United names three categories of harm: actions that may result in unintended purchases, account changes, or use of MileagePlus miles. They read as airline-specific. They are the general shape of what goes wrong when an agent holds a credential it was never separately granted.

None of these is exotic; each is an ordinary write, an ordinary redemption, an ordinary profile update. They are dangerous in aggregate because every one of them is individually indistinguishable from an intended action. An agent that transacts without a separate identity produces a record that is internally consistent and externally useless.

The Regulator Asked for a Person

The sentence that will outlast the rest is the regulatory one. The carrier says automated actions have the potential to violate FAA and DOT regulations, and gives an example: flight check-in requires “human acknowledgment that bags do not contain banned substances like explosives”.

Consider what kind of requirement that is. It is not a preference, a risk appetite or a commercial posture. It names a human act and presupposes a person capable of making it, so no capability improvement moves the agent into the position the rule describes. The agent can prepare the check-in, verify the itinerary, assemble the disclosure — but the acknowledgment is reserved, and a workflow that automates it has automated a compliance attestation.

Architects should generalise this rather than file it under aviation. Most regulated industries contain a class of act that a rule, a contract or a certification scheme assigns to a person: an attestation, a signature, a filing, a consent, an identity verification, a safety confirmation. Those acts do not become automatable when the model improves. They become automatable when the regulation changes, which is not a roadmap item.

The design consequence is concrete. A regulated act has to be a step only a named human can complete, with that human's identity bound into the transaction record. Not a confirmation dialog at the end; not a checkbox a service account can tick. A checkpoint the runtime enforces because the step type requires it, and which fails closed when no human has approved it.

Authorized Is the Operative Word

It is easy to read the announcement as a ban, and wrong in a way that produces bad architecture. United restricts “unauthorized, third-party personal AI agents or assistants”. Every qualifier carries weight: internal automation is untouched, and the agency and aggregator channel continues to sell inventory.

What is refused is not autonomy but automation nobody has authorized — and that tells you what would have to be true for an agent to be acceptable. Authorization has three components, all of them artefacts rather than behaviours: an authorizer entitled to grant it, a scope that bounds what is granted, and a record showing the grant occurred. A programme unable to produce all three for a counterparty is not operating under permission. It is operating under tolerance, a temporary condition maintained by the other party's current priorities.

Your Counterparty's Counterparties

The clause most readers will skip is the scope one. United restricts access “directly within our digital platforms and indirectly via travel agencies and aggregators”, and the work includes updates to “booking, ticketing and distribution policies”. The restriction is not enforced only at the carrier's own front door; it is pushed onto intermediaries and expected to arrive there.

This turns an identity problem into a vendor-management problem, and most organisations are organised for only one of the two. Your agent may never touch the counterparty's systems: it may reach the inventory through a travel management company, a distribution system, an expense platform or a marketplace. The restriction still binds, because the counterparty made its intermediaries responsible for carrying it. A policy that lives only on your own website is a suggestion; one that rides the distribution chain is a control.

There is no published detail yet on enforcement, on what a false positive looks like, or on how an aggregator would recognise an agent-driven transaction. That absence is a design input. You cannot build against a rule whose implementation is unpublished, so you build for refusal at any hop: detect it, surface it, route around it where a sanctioned path exists, escalate where none does.

The practical rule is unglamorous. Any counterparty that can refuse your agent belongs in the architecture diagram with an owner, an assumption about how long the access lasts, and a fallback. Dependencies that can say no are dependencies, whether or not they have an API.

What Agent Identity Would Have to Be

The cleanest response came from outside the airline. Raj Ananthanpillai of Trua argued that blocking agents or forcing more data sharing “just delays the inevitable”, and pointed at verified identity tokens. The instinct is right, and the phrase is worth pinning down, because it is easily mistaken for a vendor feature.

Notice what a workable scheme does not mention: reasoning quality, tool use, planning, guardrails, evaluation. Those are real problems, and none of them answers "who is acting". Agent identity is a distributed-systems problem wearing a governance costume — a principal, a credential format, a verifier, a revocation path. Four things that must be agreed between parties, which is why no single vendor can ship it unilaterally.

A token alone is not a solution either: verification stays bilateral until both sides of a transaction accept a scheme. An enterprise can build the internal half today — principals, scopes, records, human anchors — and should, because that half is the one it controls. The external half is a standards problem with a longer clock.

Two Concessions Before the Recommendations

The security framing is not the whole story, and pretending otherwise produces a bad reading of counterparty behaviour. United has an obvious commercial interest in the volume and cost of automated traffic reaching its systems. Analyst Henry Harteveldt put the motive plainly: the carrier wants to avoid “yet another, and potentially even more powerful, intermediary”, and “flight searches cost airlines money”.

That matters because it changes the forecast. A counterparty motivated only by security can be satisfied with evidence of control. One also motivated by cost has a reason to keep the door shut after the identity problem is solved, and will price access or trade it. Assume both motives, then ask what your programme offers against each: evidence answers the first, and being a channel worth carrying answers the second.

The second concession is that blocking cuts both ways. As Harteveldt also noted, by blocking the bots United “won't make it any easier to find its fares”. Refusal costs the refuser, which is why it tends to be temporary rather than absolute — and it is not a solution. Ananthanpillai is right that blocking delays the inevitable. Unless identity is solved, one of two unstable states persists: agents keep borrowing credentials informally, or counterparties keep building walls.

Nor is this an outlier. Bank of America had cautioned customers the previous week against sharing user IDs and passwords with AI agents, and United cites similar actions among banking and retail leaders. The direction of travel is not ambiguous, which is why the identity work is worth starting before your own counterparties publish.

Six Questions for the Next Review

The useful output of this news is not an opinion about airlines. It is a short list an architecture review can run, and which surfaces the gap between what a programme can do and what it is permitted to do.

There is a strategic version of the point. Enterprises have spent two years optimising the agent's relationship with the model — context, tools, retrieval, evaluation — and comparatively little on its relationship with the parties it transacts with. That second relationship is where the next blockers come from, because the enterprise does not own it. The counterparty does, and the counterparty has begun to say no.

The reframe worth carrying into the next design review is small and load-bearing: the question is not whether the agent can reach the counterparty. It is whether the agent can be identified, scoped and held to account when it arrives — and whether you can prove all three after the fact.

Elatify builds agent workforces in which each action carries a principal, a bounded scope and a durable record: L7 for orchestrating supervised agent teams, and AI Guardrails for the controls an auditor can actually test.