Skip to main content

AxonFlow for Travel & Hospitality

Travel and hospitality companies are deploying AI agents that rebook flights, process refunds, modify reservations, and manage loyalty programs. Every one of those workflows handles payment instruments, passport data, and booking references -- and executes against external systems (GDS platforms, airline APIs, hotel PMSes) where a duplicate call means a duplicate charge. AxonFlow provides the runtime governance layer that prevents automated refund fraud, stops PII from leaking into LLM prompts, gates high-value actions for human review, and ensures every agent decision produces a structured audit record.

This page maps AxonFlow capabilities to concrete travel workflows, operational risks, and deployment patterns. Everything described here is shipped and available today.

The travel AI governance challenge​

The operational risk in travel AI is financial, not regulatory. A banking agent that misbehaves triggers a compliance investigation. A travel agent that misbehaves triggers a chargeback. The failure modes are different, but the financial exposure is comparable: a refund agent that retries on a timeout and issues a duplicate refund costs real money. A rebooking agent that upgrades a passenger without authorization creates a fare difference that someone has to absorb. A loyalty agent that issues points without validation erodes program economics.

These risks compound because travel agents operate across systems that were not designed for AI. A Global Distribution System (GDS) like Amadeus, Sabre, or Travelport exposes booking, ticketing, and pricing APIs that predate the concept of an autonomous caller. Airline NDC APIs have their own business rules around refund eligibility, fare class restrictions, and inventory holds. Hotel property management systems enforce cancellation windows and rate fences. When an AI agent orchestrates across these systems in a multi-step workflow -- search, hold, price, book, pay -- a failure at step four that triggers a retry at step two produces outcomes that no human agent would create.

Generic LLM gateways do not solve this. A proxy that scans prompts for PII cannot enforce idempotency on a payment call. A logging layer that captures raw requests cannot tell you whether a refund was issued once or twice. A gateway that governs LLM calls but ignores the MCP connector layer leaves GDS and airline API interactions completely ungoverned -- and that is where the money moves.

AxonFlow governs the entire agent execution lifecycle: LLM calls, MCP connector invocations (including GDS and airline APIs), multi-step workflows with retry safety, and external tool use. Policy enforcement, PII detection with checksum validation, human-in-the-loop approval gates, idempotency guarantees, and structured audit logging apply at every boundary.

Use cases​

1. Refund processing agent​

What the agent does: A customer requests a refund for a cancelled flight. The AI agent checks fare rules, calculates the refund amount (accounting for taxes, fees, and fare class restrictions), and initiates the refund via the airline's API or a payment processor.

What could go wrong: The agent retries on a network timeout and issues a duplicate refund. Or it includes the customer's credit card number in an LLM prompt when asking the model to calculate fare differences. Or it processes a refund above the auto-approval threshold without human review.

How AxonFlow prevents it:

  • Idempotency enforcement via retry_context and idempotency_key prevents duplicate refunds on retry. Each refund step carries a unique idempotency key; AxonFlow deduplicates retried steps so the downstream payment call executes exactly once. See Retry & Idempotency.
  • HITL approval gates pause any refund above a configurable threshold. The require_approval policy action routes the step to a human approval queue where a supervisor approves or rejects. Unanswered requests auto-expire after 24 hours.
  • PII detection catches credit card numbers (Luhn-validated), passport numbers, email addresses, phone numbers, and booking references before they reach an LLM. The action is configurable per path: block, redact, warn, or log. See PII Detection.

2. Booking modification copilot​

What the agent does: A customer service copilot helps agents modify existing bookings: date changes, seat upgrades, adding passengers, or switching fare classes. The copilot queries the GDS for availability, calculates fare differences, and submits the modification.

What could go wrong: The copilot sends passenger passport data to the LLM when generating a change summary. Or a GDS connector call returns availability data that the copilot forwards to an unrelated tool. Or the copilot approves an upgrade that creates a fare difference above the agent's authorization level.

How AxonFlow prevents it:

  • MCP connector governance applies three-phase policy evaluation on every GDS connector call: request-phase (before the call to the GDS), response-phase (scanning returned passenger and fare data), and exfiltration-phase (if data flows to another tool or LLM). This ensures passport numbers in a PNR response do not leak into a downstream summarization prompt.
  • PII detection catches passport numbers, dates of birth, email addresses, and credit card numbers across every governed interaction.
  • HITL gates on modification steps above a fare-difference threshold ensure a supervisor reviews before the change is committed to the GDS.
  • Audit logging produces a complete decision chain: the availability query, the fare calculation, the policy evaluation, the human approval, and the modification submission. See Audit Logging.
# Policy: require human approval on booking changes above fare threshold
name: booking-modification-high-value
category: sensitive-data
action: require_approval
conditions:
  - field: step_metadata.fare_difference
    operator: gt
    value: 500
  - field: step_metadata.step_type
    operator: eq
    value: booking_modification

3. Loyalty program agent​

What the agent does: A loyalty agent handles point redemptions, tier status inquiries, partner award bookings, and promotional credit issuance. It queries the loyalty platform, validates eligibility, and executes transactions against the points ledger.

What could go wrong: The agent issues promotional credits without validation, eroding program economics. Or it processes a points redemption, encounters a timeout, retries, and double-debits the member's account. Or it leaks member PII (email, phone, DOB, passport) into LLM context when generating a personalized offer.

How AxonFlow prevents it:

  • Idempotency enforcement prevents double-debit on points redemptions. Each redemption carries an idempotency_key tied to the transaction; retries are deduplicated at the governance layer before reaching the loyalty platform. See Retry & Idempotency.
  • HITL approval gates on promotional credit issuance above a configurable threshold ensure a program manager reviews before credits are posted to member accounts.
  • PII detection catches member email, phone, DOB, and passport numbers before they reach LLM prompts used for offer personalization.
  • Cost controls prevent runaway agent loops from consuming excessive LLM budget during batch member processing. Budget limits are configurable per tenant with warn, block, and downgrade actions. See Cost Management.
# Decision Mode: check a loyalty redemption before execution
curl -s -X POST http://localhost:8080/api/v1/decide \
  -H "Content-Type: application/json" \
  -d '{
    "stage": "tool",
    "caller_identity": {
      "gateway_id": "loyalty-agent-gw",
      "tenant_id": "loyalty-us"
    },
    "target": {
      "type": "tool",
      "name": "loyalty-ledger-api",
      "action": "redeem_points"
    },
    "query": "Redeem 85,000 points for member [email protected] on booking REF-TK4419"
  }' | jq .
{
  "verdict": "deny",
  "decision_id": "b7e2a4f1-3c9d-48e2-a6d1-5f8c3b2e9a0d",
  "trace_id": "2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e",
  "stage": "tool",
  "reasons": ["Email address detected in tool call payload"],
  "obligations": [],
  "evaluated_policies": ["sys_pii_email"],
  "expires_at": "2026-05-23T10:35:00Z"
}

4. Disruption management agent​

What the agent does: When a flight is cancelled or delayed beyond a threshold, a disruption management agent automatically rebooks affected passengers on alternative flights, arranges hotel accommodations if an overnight stay is required, and notifies passengers. It orchestrates across airline inventory, hotel availability (via GDS or direct API), ground transportation, and notification systems.

What could go wrong: This is a multi-step workflow operating under time pressure with financial consequences at every step. The agent books a hotel room, then the rebooking fails, leaving an orphaned hotel charge. Or it rebooks 200 passengers on the same alternative flight without checking remaining inventory, overselling the replacement. Or it sends passenger contact details and passport data to an LLM when generating notification messages. Or the entire pipeline stalls because the LLM provider is down, leaving passengers unnotified.

How AxonFlow prevents it:

  • Multi-Agent Planning (MAP) orchestrates the multi-step disruption workflow with plan-scoped governance. Each step (rebook, hotel, transport, notify) is a governed plan step with its own policy evaluation. If the rebooking step fails, the hotel step does not execute. See Orchestration Overview.
  • HITL approval gates with plan-scoped context let a supervisor review the entire rebooking plan before execution begins, rather than approving each step individually. The approval payload includes all planned steps, costs, and passenger counts.
  • Circuit breaker and kill switch provide deterministic fallback when an LLM provider or external API is unavailable. The disruption pipeline fails loud with a structured error rather than silently stalling.
  • MCP connector governance applies three-phase policy on every GDS, hotel, and transportation API call, preventing PII leakage across connector boundaries.
  • Audit logging captures the full disruption workflow: trigger event, rebooking decisions, hotel bookings, cost accruals, human approvals, and passenger notifications. Each record carries a decision_id that ties back to the disruption event.

Reference architecture​

The diagram below shows AxonFlow in a typical travel technology stack. The pattern applies whether your AI agents are customer-facing chatbots, internal operations tools, or automated disruption management pipelines.

Every LLM call passes through the Orchestrator, where policies are evaluated and PII detection runs. Every call to a GDS, airline API, hotel PMS, or payment processor passes through the MCP Gateway, where three-phase policy evaluation (request, response, exfiltration) applies. Multi-step workflows route through the Workflow Control Plane, which enforces retry_context and idempotency_key to prevent duplicate charges and orphaned bookings. High-risk steps route to the HITL queue. All decisions produce structured audit records with decision_id, verdict, evaluated policies, timestamp, and identity.

Why retry safety matters in travel​

Travel is one of the few industries where a single retried API call can cost thousands of dollars. Consider the sequence:

  1. An agent calls the airline refund API for $2,400.
  2. The airline processes the refund and returns a 200 response.
  3. A network timeout prevents the agent from receiving the response.
  4. The agent retries. The airline receives a second refund request with a different request ID.
  5. The airline processes the second refund. The customer receives $4,800 instead of $2,400.

This is not a hypothetical scenario. It is the default behavior of any retry-capable system that does not enforce idempotency at the governance layer.

AxonFlow's Workflow Control Plane solves this with two mechanisms:

  • idempotency_key: Each step in a workflow carries a unique key. If a step is retried with the same key, AxonFlow returns the original result without re-executing the downstream call. The duplicate never reaches the airline API.
  • retry_context: Captures the state of the workflow at each step, enabling safe retries that resume from the point of failure rather than restarting the entire sequence.

These are not application-level patterns that each team must implement independently. They are enforced at the governance layer, which means every agent that routes through AxonFlow gets retry safety automatically.

For the full technical documentation, see Retry & Idempotency.

Regulatory mapping​

Travel companies face regulatory requirements around payment data, passenger personal information, and data protection. While travel is less prescriptive than banking or healthcare, PCI-DSS applies wherever card data is processed, and GDPR/CCPA apply to customer personal data.

RequirementRegulationAxonFlow capability
Card data protectionPCI-DSSPII detection with Luhn-validated credit card scanning, configurable block/redact/warn actions
Customer personal data protectionGDPR Art. 5, CCPAPII detection for email, phone, DOB, passport; GDPR erasure endpoint (POST /api/v1/gdpr/delete)
Data processing recordsGDPR Art. 30Audit logging captures every policy decision with identity, timestamp, and verdict
Right to explanationGDPR Art. 22Decision records with evaluated policies and reasons for each AI-assisted decision
Passenger data securityAirline security requirementsMCP connector governance with three-phase policy on GDS and airline API access
Payment processing safeguardsPSD2 (EU)HITL approval gates for high-value refund and rebooking transactions

AxonFlow is not PCI-DSS certified. It provides PII detection and audit capabilities that help reduce PCI-DSS scope for AI systems that process payment data. Certification is determined by your organization's QSA assessment.

Decision Mode for travel platform teams​

Many travel platforms already run gateway infrastructure between their AI agents and backend systems -- a GDS gateway for flight inventory, an API gateway for hotel and car availability, a payment gateway for transactions. For these teams, Decision Mode lets the existing gateway infrastructure call AxonFlow as a policy decision service without changing application code.

Each gateway makes one inline call to POST /api/v1/decide before forwarding the request. AxonFlow evaluates policies and returns a verdict (allow, deny, or require approval). The gateway enforces the verdict. AxonFlow is consulted; it is never on the traffic path. This is the PDP/PEP (Policy Decision Point / Policy Enforcement Point) pattern.

For travel platforms with multi-layer gateway architecture, Decision Mode provides one policy brain across all layers, with W3C traceparent correlation stitching decisions into a single end-to-end trace per booking workflow.

Deployment options​

Travel companies range from global airlines with strict data-residency requirements to startups building the next OTA. AxonFlow supports three deployment modes:

ModeDescriptionBest for
Self-HostedYou run AxonFlow on your own infrastructure. Source-available under BSL 1.1. Full control over data, network, and upgrades.Airlines and hotel chains with data-residency or network-isolation requirements
In-VPCAxonFlow runs inside your AWS VPC. No data leaves your network boundary. Managed by AxonFlow with your infrastructure controls.Travel platforms that want managed operations without data leaving their VPC
SaaSManaged by AxonFlow. Fastest path to production.OTAs, travel startups, and teams without data-residency constraints

All three modes support the same feature set. See Deployment Mode Matrix for the full comparison and Licensing for tier details.

Getting started​

Step 1: Run locally. Follow the Getting Started guide to run AxonFlow on your machine in under 5 minutes.

Step 2: Try the trip planner example. The Trip Planner Example shows PII detection, HITL gates, and audit logging configured for a travel booking workflow.

Step 3: Follow the refund agent tutorial. The Travel Refund Agent with MAP + HITL tutorial walks through building a refund agent with multi-step orchestration, human approval gates, and idempotency enforcement.

Step 4: Choose an integration mode. Use Choosing an Integration Mode to decide between Gateway Mode, Proxy Mode, Workflow Control Plane, and Decision Mode based on your architecture.

Step 5: Evaluate with real workloads. Request a free Evaluation License for self-hosted validation with HITL approval gates, evidence export, and higher limits. If you need enterprise features, direct rollout support, or managed SaaS, apply for the Design Partner Program.

Last updated on