Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Book Travel on a Corporate Card?
No, not while the booking screen shows the traveler's passport, date of birth and card; Navan's privacy policy carries all three, and a travel profile keeps them for the next trip. Ask for placeholder values on the rendered page, a named approver for the charge and a record of what the model read.
A booking agent does the work of a traveler: it searches fares, opens a profile, fills the payment page and confirms a seat. The task is narrow, so the exposure is easy to miss. The profile it reads was built for reuse, so it holds the passport number, the date of birth and the corporate card the next trip will need again. A person opening that page sees a form. A model opening the same page receives every field on it, keeps the values for the rest of the run, and carries them into the fare comparison, the confirmation and the next page it visits.
Three questions settle the answer: what the model receives on the booking screen, who approves the charge, and what the tool keeps after the trip. Travel sharpens all three. The card can be scoped to one merchant or one trip, and the pages that issue virtual cards say so, but scoping a card changes nothing about the text on the profile page. A booking tool's privacy policy can describe the card and the date of birth as account data and the passport as a travel-profile field, and that is accurate about storage while saying nothing about what a model reads while the page is open.
Key findings
- For an agent to book travel on a corporate card safely, the values on the booking page would have to be replaced with consistent tokens before any model reads it, so the traveler appears as TRAVELER_014 and the card as CARD_001, with real values resolving only at the submit a named person approved (What Is Render-Layer Tokenization?).
- It would also require a named person approving each fare and each change, a spend cap the organization sets per trip, and a record of every screen, booking and approval that the organization exports (What Is an Approved Destination for AI Agent Output?).
- Navan's privacy policy lists the payment card, the date of birth and the passport the booking tool keeps, and it does not state that any of those values is replaced on the page before a model reads it (Navan, Privacy, 2026).
- BILL's role page separates preparing a bill from paying one, so a role can carry the authority to pay without recording who approved a given trip (BILL, Roles, 2026).
- A University of Kentucky Concur guide says passport data entered in the profile "allows it to be available when booking travel", which puts the passport in front of whatever reads the booking page for an international trip (University of Kentucky, 2026).
What does an agent receive when it books a flight on a corporate card?
Horton and co-authors define the class as "autonomous software systems that perceive, reason, and act in digital environments", which is the class a booking agent belongs to (MIT Sloan, 2026). The record here is a flight booked on a corporate card: a route, a date, a fare and a card, with a traveler profile behind all of it.
Four screens carry it. The search results render the fares and the traveler's name. The profile renders the passport number, the date of birth and the Known Traveler Number stored for the next trip. The payment page renders the card, and the confirmation renders the fare. An agent needs the route, the dates, a fare class and a card field to submit, and it receives the profile because the tool draws a stored record, not an empty checkout.
A person skims the page and remembers the fare; a model receives the field values on the rendered page, as the text a DOM reader returns or the pixels a screenshot reader captures, and holds them for the rest of the run (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?). The page does not mark the passport as out of scope for a task that needs a seat, and nothing tells the agent to ignore a date of birth it was not asked about.
Where a value is substituted before the model reads the screen, the booking proceeds on TRAVELER_014 and CARD_001, and the fill needs nothing else (Can a Browser Agent Fill In a Form Without Seeing the Values?). That is the difference between an agent that books a flight and one that carries the traveler's identity through it.
What do the vendors themselves say?
Navan's privacy policy says that when an account is registered the company collects "financial data (payment card information and billing address), date of birth, gender, and emergency contact information", which states what the tool stores and not what its booking page shows a model (Navan, Privacy, 2026). The policy calls the rest optional self-entry: "You may customize your travel profile by providing additional Personal Information, such as passport data", a field a traveler added rather than one the tool demands (Navan, Privacy, 2026).
When a traveler connects an assistant, the same policy says information "retrieved from Navan, such as booking itineraries, user profile details, may be processed by the third-party to fulfill your prompts", which covers a connected assistant, not the page an agent renders (Navan, Privacy, 2026).
A University of Kentucky Concur quick reference tells travelers to update the profile "Before creating any travel requests or expense reports", and it says passport data entered there "allows it to be available when booking travel", a profile built for reuse rather than a page built to withhold values (University of Kentucky, 2026). The same card says the Secure Flight fields are mostly pre-filled, because "Gender and Date of Birth will auto populate", one more stored value on the page (University of Kentucky, 2026). It treats the card as a profile field too, since "A UK procurement card is recommended for travel" (University of Kentucky, 2026).
The reviews leave the booking screen out: Navan was not among the 15 AI agents or 86 AI security products they covered, and no product in that set describes giving an agent tokens it can use in place of the customer data on a page (Do AI Agents Ask Before Making a Payment?; How Many AI Security Products Control What an AI Agent Sees?).
| Dimension | What the pages reviewed state | What a buyer should verify |
|---|---|---|
| What the profile holds | Navan: contact data, "payment card information and billing address", date of birth; passport and traveler numbers as optional fields | Which fields the task needs |
| How a profile reaches the page | The Concur guide: passport data is "available when booking travel" | Whether values are substituted first |
| What the card limits | Ramp: a limit by transaction, day or month, a single-vendor restriction, a single-use card | Whether the limit is set per trip |
| Who approves a charge | Not described in the pages reviewed | A named approver, not a role |
| What the tool keeps | Navan: card, date of birth, optional passport and traveler numbers | Whether anything is deleted after the trip |
Who approves the charge, and what record does the approval leave?
BILL's role page separates preparing a bill from paying it: "The Accountant role can manage the payables processes, but cannot pay bills", and that role "is not able to manage users or view/manage banking information" (BILL, Roles, 2026). Administrators on the same page "typically have signing authority on your bank account because they can authorize bill payments", so the authority to pay sits with a role, not with the person who approved a given trip (BILL, Roles, 2026). A permission to pay is not a record of approval.
Google's Agent Payments Protocol announcement describes mandates as "cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions" and says the design addresses "Determining accountability if a fraudulent or incorrect transaction occurs", a record of authorization rather than a limit on what the agent read (Google Cloud Blog, 2025). A signed instruction proves a booking was asked for, not what the model saw while it assembled one.
Approval defaults are settings, and settings move. The AI Agent Index entry for Breeze Agents reports that "The default is that approval is required", and the same entry notes that users can switch it off and that automatically triggered agents run without approval (AI Agent Index, Breeze, 2026). A control a user can turn off is a configuration, not a property of the booking screen.
The argument for a person in the loop is about stopping, not reading. The Off-Switch Game argues that "giving machines an appropriate level of uncertainty about their objectives leads to safer designs", which is a property of an agent a person can stop and not a statement about what it read first (Hadfield-Menell et al., 2016).
What do the card controls cover, and what does the model still read?
The card is the part of the record a finance team can already control. Ramp's page says a card can be restricted "to a single vendor or merchant category" and issued as "a single-use card that automatically closes after one payment", both of which bound the loss from a wrong booking rather than the exposure on the page (Ramp, 2026). Neither changes one field on the profile.
Where identity data is handled as a regulated asset, the split is explicit. Stripe Identity puts the more sensitive verification fields behind restricted keys, which allow access "for verifications processed in the last 48 hours", a retrieval control on an API, not a rule for a travel profile that keeps a passport on file (Stripe, Access, 2026).
Least privilege does not close that gap: it governs which actions an agent may take and which credentials it may use, not the content of the screen it reads (What Is Least Exposure?). An agent can hold a permission set any auditor would approve and still receive the traveler's date of birth on a page it opened to compare two fares, which is what a hijacked agent would then carry (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
Masking for a person does not answer it either. A display that hides a field from the traveler's eye and leaves the value in what the model receives has changed the screen without changing the exposure (Does Masking Data on Screen Break Browser Agents?).
What does a governed environment change?
A governed environment changes what the model receives from the page, and the approval and the record follow from that change. The values a policy names on the rendered booking screen, the passport number, the date of birth and the card, are replaced with consistent tokens before any model reads the page, so the traveler appears as TRAVELER_014 on the search results, in the profile and on the confirmation, and the card appears as CARD_001. The real values resolve only at the approved destination, at the moment of an approved action: the booking posts to the airline or the tool with the real identifiers when a named person approves the fare.
The tool keeps its place. The profile still stores what it stored, the card limit still limits, and the approval prompt still asks. What it adds is the layer those controls do not cover, the content of the page while the model is looking at it. Every screen the model received as tokens, every action and every approval is written to a record the organization exports to its own logging.
Applied to a flight booked on a corporate card, the route, the dates and the fare reach the model, the identity and payment fields reach it as tokens, and the authority to submit moves to a named person (What Is Render-Layer Tokenization?). The booking tool receives the real values at submit, because the tool is where they belong.
What the record shows
Three facts settle this for a travel program: what the model receives from the booking page, who approves the charge and what record the run leaves. Navan's policy and the Concur guide describe profiles built to carry the passport, the date of birth and the card from one trip to the next, and no page reviewed says those values are replaced before a model reads them. The card controls and the approval defaults bound what a wrong booking costs. They do not change the text of the profile. A finance team should check its own workflow with one test trip: book a refundable fare with test values, read the exported record, and list every field the model received against the fields the booking needed. The difference is the exposure the approval never covered.
Methodology and limitations
This page rests on Navan's privacy policy, a university Concur quick reference, Ramp's virtual card page, Stripe's Identity access page, BILL's role page, Google's AP2 announcement, the AI Agent Index entry for Breeze Agents, MIT Sloan's explainer and one preprint. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page.
The products on this page are described from documentation and none was tested for this page; "not described" means the pages reviewed, vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The flight describes a record type, not an organization, and no traveler data is real. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one booking on the organization's own screens.
Frequently asked questions
Is it safe to let an AI agent book travel on a corporate card?
No, not while the booking page renders the profile. The agent receives the passport number, the date of birth and the card because the tool pre-fills them from a record built for the next trip. The card limit, the approval prompt and the vendor's own settings govern what the agent may spend and whether it must ask. They leave open what its model holds. It becomes safe when those values are replaced before the model reads the page, a named person approves the fare, and the record is exported.
What does the model receive on a booking screen?
Whatever the page renders, which starts with the profile. Navan's policy lists payment card information and date of birth as account data and passport data as an optional profile field, and a Concur guide says the stored passport is "available when booking travel". An agent that opens the page to compare fares receives all of it, and a screenshot agent receives it as an image. The task needs a route, a date and a fare, not an identity document.
Does a virtual card limit change what the model reads?
No. A limit set on the card decides how much a wrong booking can spend and how long the card stays usable. Ramp's page describes a limit by transaction, day or month, a single-vendor restriction and a single-use card, and each is a control on spending. None changes a field on the profile page the agent reads before it submits the fare, so the passport and the date of birth reach the model either way.
Who should approve a booking an agent prepares?
A named person at the organization, with the approval attached to the fare and the itinerary. BILL's role page shows why a role is not enough: a role carries authority to pay without recording who approved a given charge. Google's mandate design records a user's instruction in a signed contract, which proves the booking was asked for. Neither arrangement says what the model read while it prepared the booking, and that is the part an approver should see.
What record should the organization keep of the agent's booking?
A per-run record of the screens the model received, the fields it used, what it submitted and who approved it, exported to the organization's own logging. The booking tool's own record answers for the tool, and the card statement answers for the money. Neither lists the identity fields that were on the page. The record that matters names the traveler as the model saw them, the action and the person who approved it.
What should a travel manager ask for in writing?
A list of fields the model receives from the rendered booking page, the substitution that applies before it reads the page, the spend cap per trip, the named approver and the exported record. Ask also which profile fields the task can do without and what the tool keeps after the trip. A vendor answer that names the login and the card but not the passport answers a narrower question than the one that decides the risk.
How RedactSure Keeps the Passport and Card Out of the Booking Screen
A booking agent reads the passport, the date of birth and the card to fill three fields and one fare. Ramp's page says a card can carry "its own limit by transaction, day, or month", a ceiling on spend and not on what the page shows (Ramp, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the page rendered the passport, the date of birth and the card, and the model carried them into the fare comparison. Inside the governed environment it renders TRAVELER_014, DOB_002 and CARD_001, the agent books on those tokens, real values resolve only on a named person's approval, and the AI Control Record keeps the screens.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
An agent that reads the passport and card carries both into the model, and the fare is the smallest part. Bring one trip from your own workflow and see, with test values, what the model reads and who approves the charge. Book a demo