Defender Impact
United Airlines’ decision to block third-party AI agents from completing transactions on its platform provides a replicable, compliance-grounded model for access control at the agentic boundary — a space where defenders have had limited precedent and even fewer deployed controls. For security teams grappling with how to scope AI agent permissions in their own environments, this is a concrete reference implementation worth examining.
Capability Overview
United Airlines has explicitly restricted personal AI assistants — including OpenAI’s Dots and Meta’s Muse — from executing flight bookings on behalf of customers. Agents may still surface United flight information, but the transaction layer is off-limits. The rationale is dual: privacy risk from agents handling sensitive customer data, and regulatory obligation — specifically, federal requirements that passengers personally attest to baggage contents. These aren’t edge-case concerns. The attestation obligation is a live compliance requirement that an AI agent, acting autonomously, structurally cannot fulfil with legal equivalence to a human affirmation.
This positions United’s stance not merely as a commercial preference but as a compliance-driven access control decision — one that other organisations in regulated sectors can directly reference when designing their own agent permission frameworks. The decision also reflects a broader pattern noted in the article: other platforms including DoorDash and banks are encountering similar friction with AI agents operating in transactional contexts.
Defensive Advances
For defenders, this development surfaces three actionable advances:
Transaction-boundary access control as a first-class control. United’s approach — allow agents to read, disallow agents to write/transact — is a least-privilege pattern applied directly to agentic systems. This is a usable template for any organisation assessing how to integrate AI agents without granting excessive agency over consequential actions.
Regulatory obligations as natural enforcement gates. Compliance requirements that mandate human attestation (hazardous materials, consent forms, identity verification) provide a defensible, auditable reason to restrict agent scope. Security teams can inventory these requirements and use them proactively to define where agentic automation must stop.
Industry-level precedent that reduces adoption pressure risk. When major enterprises publicly define agent boundaries, it normalises the posture and reduces the internal pressure organisations may feel to allow full agentic delegation in order to stay competitive. This is a soft but real defensive benefit.
Residual Gaps
The limitation of this development is that it is a policy control, not a technical enforcement mechanism. United can decline to surface booking APIs to agents, but there is no industry-wide standard for how platforms communicate agent permission scopes, how agents are authenticated and attributed, or how transactional boundaries are enforced programmatically across the agentic ecosystem.
Key maturity questions remain:
- Agent identity and attribution: How do platforms reliably distinguish an AI agent acting autonomously from a human-initiated browser session? Without agent identity standards, policy enforcement is fragile.
- Interoperability of permission models: United’s approach is bespoke. There is no shared framework (akin to OAuth scopes for agents) that would allow consistent, portable agent permission declarations across platforms.
- Coverage of less visible transaction surfaces: High-profile platforms like United can enforce boundaries clearly. The same rigour is unlikely to be applied uniformly across smaller vendors where agentic integrations are less scrutinised.
Framework Mapping
This capability is most directly relevant to LLM08 (Excessive Agency) — the OWASP category addressing AI systems that take consequential actions beyond their intended scope. United’s access restriction is a direct countermeasure to the excessive agency risk profile. It also touches LLM06 (Sensitive Information Disclosure) by limiting what customer data agents can access or transmit, and LLM07 (Insecure Plugin Design) by establishing that not all platform functions should be exposed to agent integration.
In MITRE ATLAS terms, the control reduces exposure to AML.T0086 (Exfiltration via AI Agent Tool Invocation) and AML.T0083 (Credentials from AI Agent Configuration) by constraining the tool surface available to agents operating in the platform context.
Deployment Considerations
Organisations assessing their own agentic integration posture should treat United’s approach as a starting-point policy template rather than a finished solution. Begin by inventorying all workflows where AI agents could initiate consequential actions — financial transactions, data exports, communications sent on behalf of users — and apply a default-deny posture to that transaction layer until agent identity, audit logging, and rollback capabilities are confirmed.
Complement access restrictions with logging: if agents can query but not transact, ensure query-layer interactions are still logged for anomaly detection. This preserves investigative value without blocking the read-only utility that agentic tools can legitimately provide.
Defender Checklist
- Map all AI agent integration points in your environment and classify each as read-only or transactional
- Apply a default-deny posture to transactional agent access; require explicit business justification and compensating controls before enabling
- Identify regulatory attestation requirements in your workflows and use them as hard stops for agentic delegation
- Ensure agent-layer interactions are logged separately and reviewed for anomalous query patterns
- Monitor emerging agent identity and authorisation standards (e.g., OAuth for agents) and plan for adoption as they mature
- Review third-party AI assistant integrations for PII exposure risk in the data passed to and from agent sessions