The AI agent credential problem: a new kind of identity for Travel Operating Systems

The previous post in this series described two credential categories that the Activity Travel Protocol manages: traveller credentials and operator credentials. Both are well-understood in principle. Travel has always required that travellers prove who they are and that businesses prove they are authorised to operate. What has changed is that the Activity Travel Protocol makes these verifications machine-readable and automated.

But the protocol introduces a third credential category that has no precedent in travel — or, for that matter, in any regulated industry: the AI agent credential. When an AI agent makes a booking on behalf of a traveller, it is not a person and not a business. It is a software system acting with declared authority. The protocol defines what that authority looks like, how it is declared, how it is verified, and what happens when an agent acts outside it.

This is the most consequential new concept in the protocol, and it is the one that regulators across every jurisdiction reviewed in the Activity Travel Protocol's regulatory strategy are actively working to address.

the audit gap that AI booking creates

An AI agent confirms a ski package booking. It has assembled the itinerary, checked supplier availability, agreed commercial terms with four suppliers, and committed the booking — all without a human reviewing each step. The confirmation is sent to the traveller. The suppliers are notified. The booking is live.

Who authorised the agent to do this? What were the limits of its authority? If the agent negotiated commercial terms with the ski school that the operator later disputes, is that agreement binding? If something goes wrong during the activity and the liability chain is contested, how does anyone establish what the AI was permitted to do and whether it acted within that permission?

In the current state of travel technology, these questions have no systematic answer. AI agents are already making binding bookings — through OTA APIs, through booking widget integrations, through conversational interfaces that call reservation systems directly. But the authority under which they act is invisible. There is no machine-readable record of what the agent was permitted to do. There is no verification that it stayed within those limits. There is no audit trail that a regulator or a harmed party can inspect.

what regulators are asking for

This gap is not unnoticed. The EU AI Act, which came into force in August 2024, requires that AI systems operating with consequential autonomy be transparent about their capabilities and limitations. Japan's Cabinet Office has published AI governance guidelines that address automated decision-making in consumer contexts. Singapore's IMDA Agentic AI Framework — published in January 2026 — directly addresses AI systems that take actions on behalf of users in commercial settings.

None of these frameworks specify what an AI agent credential looks like in travel. They define the requirement — AI agents with consequential authority must have documented, verifiable scope — but they leave the implementation to the industry. The result is a situation where the regulatory requirement exists and the industry consensus on how to meet it does not.

The Activity Travel Protocol is a sector-specific answer to that requirement.

the AgentAuthorityDeclaration and the ATP Mandate Model

The protocol defines the ATP Mandate JWT as the AI agent credential. It is a cryptographically signed JSON Web Token (Ed25519/EdDSA) that carries:

• The agent's identity (a UUID-based agent identifier)
• The booking it is bound to (the Booking Object UUID — the mandate cannot be used on any other booking)
• The Cedar policy set defining exactly what actions the agent can take
• The expiry time of the mandate
• The chain of parent mandates back to the root issuer

The Cedar policy set is the substance of the credential. It names the specific protocol actions the agent is permitted to take — not categories of permission, but specific Cedar action values. An agent with CONTEXT_READ scope can call atp_get_context_package and atp_get_booking_status. An agent with HEM_INVOKE scope can call atp_invoke_hem — but only for the specific hem_id values named in the policy. The policy does not grant general HEM authority; it grants authority to invoke specific escalation mechanisms.

This specificity is what makes the credential auditable. After a booking is completed — or after something goes wrong — any party with access to the Booking Object's event log can reconstruct exactly what each agent's mandate permitted at each point in the booking lifecycle, and compare it against the actions the agent actually took. The Security Kernel's 403 rejection records are part of the event log: if an agent attempted an action outside its mandate, that attempt is recorded.

The narrowing property. When an agent delegates to a sub-agent, the sub-mandate must be a provable subset of the delegating agent's own mandate. This is enforced cryptographically by the Security Kernel. An agent cannot delegate authority it does not hold. The delegation chain is verifiable at every link.

The CONFIRMATION hard cap. Regardless of what the mandate permits, no AI agent can complete a booking confirmation without a human approval step. This is not a Cedar policy — it is a Security Kernel enforcement rule that applies universally. The protocol's position is that the moment of maximum commercial consequence is always a human decision. The AI agent can prepare every element of the confirmation; it cannot execute it unilaterally.

Conformance certification. The protocol defines a certification programme for Travel Operating System operators: the @atp/interop-tests suite tests whether an operator's implementation correctly issues mandates, enforces the narrowing property, applies the CONFIRMATION hard cap, and logs the required events. An operator whose implementation passes the interoperability test suite and submits to Foundation review receives the ATP-compatible mark. The credential that says "this AI booking system operates within the protocol standard" is as important as the credentials of the parties it books with.

what the third credential category means for the industry

The traveller credential established that the person booking has the right to travel. The operator credential established that the supplier is authorised to operate. The AI agent credential establishes that the system acting on the traveller's behalf is operating within a declared, verified, and auditable scope.

These three categories together constitute a complete trust model for AI-native travel. Without the third category, the first two are incomplete: a booking chain where traveller and supplier are verified, but the AI agent acting between them is operating with unverified authority, is not a governed booking chain.

For platform operators building on the Activity Travel Protocol, the AgentAuthorityDeclaration is the mechanism that makes AI autonomy commercially viable. Operators can extend meaningful authority to AI agents — letting them assemble itineraries, communicate with travellers, and coordinate suppliers — because the mandate model constrains that authority to what was explicitly granted and verifiable after the fact.

For regulators, the ATP Mandate JWT is the evidence base that the EU AI Act, Japan's Cabinet Office guidelines, and Singapore's IMDA Agentic AI Framework are asking for. It is not a policy document or a transparency statement. It is a machine-readable, cryptographically verifiable record of what each AI agent was permitted to do in each booking it participated in.

The travel industry has verified travellers and suppliers for as long as it has existed. The AI agent credential is new. The Activity Travel Protocol defines it, enforces it, and makes it auditable. That is the third category — and it is the one that makes AI-native travel infrastructure trustworthy rather than merely capable.