AI Agent Governance for Airline Irregular Operations

Why IROP Response Is a Distinct Governance Problem

Irregular operations compress decision timelines and increase the operational stakes of every action an AI agent might take. When a weather event, mechanical issue, or crew disruption cascades across a network, the systems involved (crew scheduling, passenger service systems, dispatch, and maintenance and repair operations) must respond quickly, but the consequences of an incorrect or unauthorized action are amplified under time pressure. Governance controls designed for steady-state operations do not automatically hold up when an agent is making rapid, high-volume decisions during a disruption.

No airline-specific regulatory standard yet exists for AI agent behavior in these workflows. In the absence of sector-specific rules, governance leaders are applying general AI agent security frameworks, including guidance from NIST and OWASP, directly to airline operational systems. This means the burden of defining acceptable scope, escalation, and audit practices falls on the airline's own governance function rather than on an external compliance mandate.

Mapping Agent Access Across Airline Systems

Before an agent is granted any operational authority, its access must be mapped system by system. Crew scheduling, PSS, dispatch, and MRO each carry different risk profiles: a scheduling change can affect duty-time compliance, a PSS action can affect passenger rebooking and revenue, a dispatch action can affect flight safety margins, and an MRO action can affect aircraft airworthiness records. Treating these systems as a single undifferentiated permission set understates the risk of the highest-consequence systems and overstates the risk of lower-consequence ones.

A defensible approach defines the minimum function set an agent needs within each system rather than granting broad API access and relying on the agent's own judgment to stay within bounds.

Function-Level Scoping

Instead of granting an agent full read/write access to a system, governance teams should enumerate the specific functions the agent needs (for example, rebooking passengers within a defined fare class, or querying crew duty-time remaining) and grant only those functions.

Runtime Policy Enforcement at the Tool-Call Layer

Static permission lists, set once at deployment, do not account for the fact that the same action can carry different risk depending on context. A rebooking action affecting ten passengers is different from one affecting a full aircraft; a crew reassignment within duty-time limits is different from one that would breach them. Runtime policy enforcement evaluates each tool-call individually, checking the system being invoked, the type of action, and its operational severity before allowing execution.

This shifts governance from a one-time provisioning decision to a continuous, per-action control that can adapt to the specific circumstances of an IROP event as it unfolds.

MCP and the Tool-Call Governance Layer

As airlines adopt the Model Context Protocol (MCP) or similar tool-calling frameworks to connect agents to operational systems, the governance question shifts to where policy is enforced within that protocol layer. A governance-aware implementation intercepts each tool-call request before it reaches the underlying system, applies context-aware policy, and only forwards approved actions. This tool-call governance layer becomes the practical enforcement point for the least-privilege and escalation controls described above, regardless of which specific systems sit behind it.

Auditability and Accountability

Because no airline-specific standard yet governs agent behavior in IROP workflows, the ability to reconstruct exactly what an agent did, and why, after an event is central to accountability. Audit logs should capture agent identity, the system invoked, the input parameters supplied, and the resulting outcome for every action. This level of detail supports internal post-incident review and positions the airline to respond to a future regulatory inquiry, even though no such inquiry framework currently exists.

Tamper-evident logging is a meaningful distinction here: logs that can be altered after the fact undermine the value of the audit trail precisely in the high-consequence cases where it matters most.

Operational Tradeoffs to Resolve Before Deployment

Governance leaders should expect to resolve several tradeoffs before granting agents operational authority in IROP workflows:

• Speed versus escalation: stricter escalation thresholds slow agent response time during exactly the disruptions where speed matters most.
• Scope breadth versus utility: narrower function-level scoping reduces risk but may limit how much of the IROP workflow the agent can meaningfully automate.
• Credential lifetime versus operational continuity: short-lived tokens reduce exposure but require reliable renewal processes that do not themselves become a point of failure during a disruption.
• Logging granularity versus system overhead: capturing full input parameters and outcomes for every action creates a more useful audit trail but adds storage and processing considerations at scale.

None of these tradeoffs has a universally correct answer. They should be resolved deliberately, system by system, as part of the evaluation process before any agent is given operational authority.