Home MoltGuard MolTrust Sports MT Shopping MT Travel MT Skills MT Prediction Integrity Dashboard Blog API
← Back to Blog
March 6, 2026 9 min read

MT Travel: Why Autonomous Booking Agents Need Delegation Chains

Your company's AI travel agent just booked a $4,200 business-class flight. Who authorized it? Was the agent within scope? Is there an audit trail? Today, there are no answers. MT Travel fixes that.

The Corporate Travel Problem

Corporate travel is one of the first domains where autonomous agents are replacing human workflows at scale. AI assistants book flights, reserve hotel rooms, arrange car rentals — all without a human clicking "confirm." Concur, Navan, and a new wave of agent-first platforms are building exactly this.

But the trust layer is completely missing. When an AI agent books a $900 hotel room on behalf of an employee, the hotel has no way to verify:

$1.4 trillion
global corporate travel market (2025). Zero verifiable credential standards exist for agent-booked travel.

The Missing Link: Delegation Chains

Shopping is simple — one person, one agent, one purchase. Travel is different. Corporate travel involves a chain of delegated authority:

Company → authorizes HR to set travel policies

HR / Manager → authorizes employee travel budgets

Employee → delegates to AI travel agent

AI Travel Agent → books with airlines, hotels, rental companies

Each link in this chain is a trust boundary. If any link is broken — a compromised agent, an exceeded budget, an unauthorized segment — the entire booking should be flagged. No travel platform today verifies this chain cryptographically.

That's what MT Travel solves. We built the TravelAgentCredential — a W3C Verifiable Credential that encodes the full delegation chain, segment permissions, spend limits, and traveler identity into a single, cryptographically verifiable credential.

Introducing TravelAgentCredential

A TravelAgentCredential binds an AI booking agent to its principal through a verifiable delegation chain. It's not just "this agent can book" — it's "this agent can book hotels up to $500/night for this employee, authorized by this company, until this date."

Delegation Chain

Cryptographic chain from company → manager → employee → agent. Every link verified.

Segment Permissions

Hotel, flight, car rental, rail — each segment independently authorized. No scope creep.

Spend Limits

Per-booking and daily caps. A $200/night hotel credential can't book a $1,200 suite.

Traveler Identity

Credential binds to a specific traveler. Agent can't book for unauthorized passengers.

How the Protocol Works

1
Issue
Company issues VC
2
Book
Agent presents VC
3
Verify
Merchant calls MoltGuard
4
Receipt
On-chain record

Step 1: Issue a TravelAgentCredential

# Issue a TravelAgentCredential for a corporate booking agent curl -X POST https://api.moltrust.ch/guard/vc/travel-agent/issue \ -H "Content-Type: application/json" \ -d '{ "agentDID": "did:base:0x380238...5838F5", "principalDID": "did:base:acme-corp", "segments": ["hotel", "flight"], "spendLimit": 2000, "currency": "USDC", "validDays": 30, "traveler": { "name": "Jane Smith", "employeeId": "EMP-4521" } }' # Returns: signed TravelAgentCredential with JWS proof

Step 2: Agent Books Travel

The agent searches for flights, selects hotels, and initiates checkout — presenting its TravelAgentCredential as proof of authorization. The credential travels with every booking request.

Step 3: Merchant Verifies

Before confirming the reservation, the merchant calls MoltGuard's verification endpoint. One POST. Ten checks. Sub-second response.

// Merchant-side verification — 3 lines of code const receipt = await fetch('https://api.moltrust.ch/guard/travel/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ agentDID: booking.agentDID, vc: booking.travelAgentVC, merchant: 'hilton.com', segment: 'hotel', amount: 450, currency: 'USDC' }) }).then(r => r.json()); // receipt.result: "approved" | "rejected" | "review" // receipt.guardScore: 0-100 // receipt.checks: 10 individual verification results // receipt.tripId: groups multi-segment bookings

The 10-Step Verification Pipeline

Every booking passes through a 10-step verification pipeline. Each check must pass independently. A single failure produces a rejected result with a specific reason.

#CheckWhat It Verifies
1VC SignatureEd25519 JWS is valid and not tampered
2VC ExpiryCredential hasn't expired
3Agent DID MatchRequesting agent matches credential subject
4Segment AuthorizationHotel/flight/car is in allowed segments
5Spend LimitBooking amount ≤ credential spend limit
6Currency MatchPayment currency matches credential currency
7Daily TX CapAgent hasn't exceeded daily booking limit
8Trust ScoreOn-chain agent reputation ≥ threshold
9Delegation ChainAuthority chain is complete and valid
10Traveler BindingBooking is for the authorized traveler

Multi-Segment Trips — One Trip, One Receipt

A business trip is rarely a single booking. It's a flight + hotel + car rental. MT Travel groups these into a single trip with a shared tripId.

# Get all bookings for a trip curl https://api.moltrust.ch/guard/travel/trip/trip_abc123 # Returns: all segment receipts grouped together { "tripId": "trip_abc123", "receipts": [ { "segment": "flight", "merchant": "lufthansa.com", "amount": 680 }, { "segment": "hotel", "merchant": "hilton.com", "amount": 450 } ], "totalSpent": 1130 }

This gives finance teams a single audit trail for a complete trip, with every segment independently verified and anchored on-chain.

MT Shopping vs. MT Travel

MT Travel builds on the same credential architecture as MT Shopping, but adds the complexity that travel demands.

DimensionMT ShoppingMT Travel
CredentialBuyerAgentCredentialTravelAgentCredential
DelegationHuman → AgentCompany → Manager → Employee → Agent
SegmentsProduct categoriesHotel, flight, car rental, rail
Trip GroupingN/AMulti-segment tripId linking
Traveler BindingN/ANamed traveler on credential
Verification Steps710
On-Chain ReceiptsPer purchasePer segment + per trip

Why This Matters Now

Corporate travel management platforms are racing to add AI agents. Concur, Navan, TripActions — all are building or acquiring agent capabilities. But they're doing it inside their own silos, with proprietary authorization that doesn't translate across platforms.

When an employee's AI agent books a Hilton room through Navan, then a Lufthansa flight through Concur, there's no unified credential that spans both platforms. No single audit trail. No portable authorization.

The travel industry doesn't need more proprietary agent APIs. It needs an open credential standard that works across every platform, airline, and hotel chain.

MT Travel is that standard. W3C Verifiable Credentials. Ed25519 signatures. On-chain anchoring on Base. Open endpoints. No SDK lock-in.

Get Started

All MT Travel endpoints are free during Early Access. No signup, no API key, no SDK — just HTTP.

Issue Your First TravelAgentCredential

All endpoints free during Early Access. Start verifying agent bookings today.

Get Started →

MT Travel is built by MolTrust (CryptoKRI GmbH, Zurich) — trust infrastructure for the agent economy. Follow @MolTrust on X for updates.