AI agents for travel document and visa compliance: the pre-departure readiness check that never overrules the border

The most expensive place to discover a document problem is the check-in desk. A passport that’s valid but expires four months out, for a country that requires six. A traveler who booked a European trip without realizing the UK now requires an ETA to transit. A dual national who used the wrong passport for one leg. None of these are exotic, they’re the ordinary friction of international travel, and every one of them gets caught at the worst possible moment, by a gate agent who has to say no, because the airline is the party that pays when it says yes to the wrong passenger.

That’s the asymmetry worth building against. IATA’s own studies put inadmissible-passenger (INAD) cases at roughly one in ten thousand travelers, with fines commonly in the four figures per case and a fully-loaded cost (penalty plus repatriation flight, escorts, accommodation) that IATA estimates can run to around $25,000 for a single case, and on the order of a million dollars a year for a busy carrier. The document check isn’t back-office hygiene; it’s a liability the airline carries on every boarding. An AI agent can’t remove that liability. What it can do is move the discovery of a problem from the gate to three days before departure, when there’s still time to renew a passport or file an authorization, and that shift is where the value is.

This is a different agent from the booking-and-disruption agent we mapped for travel, which is all about not inventing a fare. Here the stakes aren’t a made-up price; they’re a made-up ruling, an agent that tells a traveler they’re good to fly when they aren’t, or panics one who’s fine. So the design principle is the mirror image of the booking agent’s, and just as strict: the agent may assess documentary readiness, but it must never assert admissibility. The airline’s systems make the boarding call; the border officer at the destination makes the entry call. The agent’s job ends one step before both.

The rules are real, numerous, and confusing

Before any architecture, respect the domain, because underestimating it is how you ship an agent that confidently misleads people. The requirements that gate international travel are a moving, interacting set:

• Passport validity rules. Many countries (concentrated across Asia, the Middle East, and Africa) require a passport valid at least six months beyond entry. Others require three months, or only validity for the length of stay. It is not universal and not consistent, which is exactly why travelers get it wrong.
• Visa and electronic-authorization rules. Some destinations need a visa; a growing number need an electronic travel authorization short of a visa. The UK ETA became fully required in February 2026: around 85 visa-exempt nationalities, including US, Canadian, Australian, and EU citizens, now need one before they travel, and carriers refuse boarding without it. The EU’s ETIAS is the one everyone asks about and the one to be careful with: as of 2026 it is not yet in force. The EU pulled its 2026 target date, and current expectations point to a launch around 2027, with no firm date set and a transitional grace period expected before it’s mandatory. State that carefully in any traveler-facing copy, because a confidently wrong “you need ETIAS” is its own kind of failure.
• Onward-ticket and blank-page rules. Proof of return or onward travel; one or two blank passport pages. Small, real, and easy to miss.
• Advance Passenger Information (APIS). Separately from any of the above, carriers transmit passport machine-readable-zone data (name, date of birth, nationality, document number and type, expiry) to border authorities before departure, within windows the authority sets (for the US, CBP requires it between 72 hours and 30 minutes before departure). APIS is a data feed to the government, not an admissibility decision: a distinction that reinforces the whole theme: the systems around travel gather data and enforce rules, but the ruling belongs to the authority.

Here’s the detail that should make any architect humble: even trained airline staff misapply these rules. There are well-documented cases of carriers wrongly denying boarding to properly documented passengers over a misread validity rule. That cuts two ways, and both matter for the design. It means a well-grounded agent adds value, because the rules are hard enough that even experts slip. And it means the agent must never be the final arbiter, because if humans with training get this wrong, an LLM reasoning from its training data will too, unless it’s structurally prevented from reasoning about the rules at all, and made to retrieve them instead.

The one rule that makes this buildable: don’t let the model know the rules

The single most important architectural decision is that the agent must never answer an entry-requirement question from the model’s own knowledge. Entry rules change constantly, vary by nationality and transit point, and are precisely the kind of fact an LLM will hallucinate fluently. The requirement, exactly as with fares in the booking agent, is that every factual claim comes from an authoritative, current source the agent retrieves, never from what the model “knows.”

Fortunately, that source of truth already exists as a product category, and you don’t build it. Airlines have used IATA’s Timatic for decades (the curated global database of passport, visa, and health-document requirements) and its automated form, Timatic AutoCheck, returns a go/no-go boarding assessment for a given nationality, destination, transit set, and documents held, along with the specific documents required when there’s a gap. It’s reachable as an API through IATA and resold through GDSs like Sabre. Newer entrants expose the same class of data over modern, developer-friendly APIs: Sherpa° publishes an OpenAPI-standard interface used by carriers including American, British Airways, Delta, and Air Canada, drawing on thousands of government sources; TravelDoc and Amadeus Travel Ready occupy the same space. The point isn’t which one. It’s that a callable, maintained entry-requirements API is a solved problem, and your agent’s factual grounding should be a request to one of them, not a paragraph in a prompt.

The rules live in Timatic or Sherpa, refreshed daily by people whose job is to track them. The agent’s job is to ask, ground its answer in the response, and attribute it, never to remember.

The architecture on Agentforce

For a travel management company, tour operator, or airline already on Salesforce, the reason to build this on Agentforce rather than a standalone tool is the same reason grounding wins everywhere: the traveler, the itinerary, the passport-on-file, and the service history are already in the platform. The build is an Agentforce Service Agent with a tightly scoped topic, call it Pre-Departure Document Readiness, and four platform pieces underneath it.

The traveler profile in Data 360. The unified profile is what lets the agent personalize the check instead of interrogating the traveler for data you already hold: passport nationality and expiry on file, the booked itinerary with its transit points, prior trips, any earlier document flags. Grounding a prompt template on that profile, through Data 360 (formerly Data Cloud) with retrieval-augmented generation, means the agent starts from “your passport on file expires in March; you’re flying to Thailand in February” rather than a blank form. If the passport-on-file data is thin or stale, that’s the project before the agent, because an agent is only as good as the data it grounds on.

The entry-requirements call as an action. The retrieval step, ask Timatic or Sherpa what this traveler needs for this trip, is an Agentforce action, and there are three honest ways to build it. A no-code Flow HTTP Callout authenticated with a Named Credential is the fastest path, with one real caveat: HTTP Callout flows struggle with deeply nested JSON, and entry-requirements responses are nested, so a rich provider response can be awkward to parse in Flow. External Services is often the better fit here precisely because providers like Sherpa ship an OpenAPI spec. Import it and Salesforce generates the invocable action for you, no brittle glue. For complex request shaping or response normalization across providers, an invocable Apex action gives you full control. Whichever you pick, the auth lives in a Named Credential, and the choice between per-user OAuth and a server-to-server JWT bearer flow depends on whether a human is in the loop: a genuine implementation detail, not a footnote, because agents run under the platform’s permission model.

A prompt template that summarizes, and only summarizes. The agent merges the provider’s structured response with the Data 360 profile into a plain-language readiness summary: “your passport meets Thailand’s validity requirement; you do not need a visa for a stay under 30 days; you have not yet applied for the transit authorization Singapore requires.” The template’s job is to restate what the API returned in human terms, attributed and dated. It is not to reason about edge cases the API didn’t cover. This is the same grounded-prompt discipline that keeps any agent from drifting into fiction, applied where fiction is dangerous.

Guardrails and an escalation path that mean it. Agentforce Guardrails and the Einstein Trust Layer are where the “advisory, never authoritative” rule stops being a good intention and becomes enforced behavior. The topic instructions and guardrails must force three things on every answer: attribute the requirement to its source and date, never state or imply that the traveler will be admitted, and always close with the standing disclaimer that the airline decides at check-in and the border authority decides on arrival. And the agent needs a real human-in-the-loop escalation for the cases it should never touch.

Where the agent stops, and it stops early

The escalation path isn’t a nicety; it’s most of the safety case. There is a whole class of situations where the correct behavior is for the agent to not answer and route to a human visa specialist:

• Dual nationality, where which passport governs entry, and which governs each leg, is a judgment call with real consequences.
• Complex multi-transit routing, where a country you merely change planes in has its own transit-visa rules that the simple origin-destination query misses.
• Recent travel history that affects eligibility: the kind of thing that can void a visa-waiver authorization and that no passport scan reveals.
• Any ambiguous provider response. Real entry-requirements APIs can return not just “OK” or “not OK” but statuses that mean “we can’t determine this. Resubmit” or “this traveler may proceed but the authorization isn’t confirmed yet.” IATA has written about exactly this problem with electronic travel authorizations: a status that lets a passenger board even though their authorization hasn’t been granted. An agent that treats an ambiguous status as a green light is an agent generating INADs. The correct handling of “I’m not sure” is to escalate, not to guess.

The honest framing to put in front of every stakeholder: this agent is a pre-flight readiness assistant, not a compliance authority. It surfaces requirements early, personalizes them to the traveler you already know, and flags gaps while there’s still time to fix them, and then it explicitly hands the go/no-go to the airline’s own systems and the border officer at the destination. That’s not a limitation to apologize for. It’s the design that keeps the agent trustworthy, because in document compliance, the same rule holds as in fares: the failure isn’t an awkward sentence, it’s a stranded traveler and a fine, and you only get to make that mistake once before people stop trusting the tool.

What to do

Start where the pain and the volume overlap: a traveler base that crosses borders often, with document requirements that bite, and an operations team currently doing this by hand. Audit your passport-on-file data first, a readiness agent grounded on stale expiry dates is worse than none. Wire the agent’s every factual claim to a real entry-requirements feed (Timatic AutoCheck, Sherpa, TravelDoc, or Amadeus Travel Ready) through a governed action, and forbid it, structurally, from answering entry questions any other way. Ground it on the Data 360 traveler profile so it personalizes instead of interrogating. Put the disclaimer and the source attribution in the guardrails, not just the prompt. And build the escalation path first, for dual nationality, complex transit, and every ambiguous API response, because the cases the agent refuses to answer are the ones that prove it can be trusted with the ones it does. Get that right and you’ve moved the most expensive discovery in travel from the gate to three days out, which is the entire point.

Understanding the basics

Can an AI agent tell a traveler whether they can enter a country?

No, and it shouldn’t try. An agent can assess documentary readiness: whether the passport meets the destination’s validity rule, whether a visa or electronic authorization is required and obtained, whether transit points impose their own requirements. But admissibility is decided by the airline at check-in (which bears the fine for boarding an inadmissible passenger) and by the border authority on arrival, which can refuse entry even to a correctly documented traveler. A well-built agent grounds every requirement in an authoritative feed like IATA Timatic or Sherpa, attributes and dates it, and explicitly defers the final decision to those authorities.

How does an Agentforce agent check visa and passport requirements?

By calling an authoritative entry-requirements API as an action rather than answering from the model’s knowledge. On Salesforce, that action is typically a Flow HTTP Callout, an External Services action generated from the provider’s OpenAPI spec, or an invocable Apex method, authenticated through a Named Credential. The agent grounds on the unified traveler profile in Data 360 (passport nationality and expiry, itinerary, transit points), sends those to a provider like Timatic AutoCheck or Sherpa, and uses a grounded prompt template to restate the response in plain language. Guardrails and the Einstein Trust Layer enforce that it attributes the source and never asserts admissibility.

Why can’t the agent just use the language model’s knowledge of visa rules?

Because entry rules change constantly, vary by nationality and transit point, and are exactly the kind of fact an LLM will state fluently and incorrectly. Even trained airline staff misapply them, and authorizations like the UK ETA and the forthcoming EU ETIAS keep changing status and timelines. Answering from model memory produces confident, out-of-date, or hallucinated guidance, which, in this domain, means a denied boarding or a stranded traveler. The only safe design retrieves the current requirement from a maintained, authoritative source on every query and treats any ambiguous response as a reason to escalate to a human, not to guess.

---

Building a document-readiness or traveler-service agent and trying to make sure it flags gaps without ever overruling the airline or the border? Talk to us. Grounding agents in authoritative data and governed actions, with the guardrails that keep them advisory where they must be, is exactly the work we do.