Jettova for Teams
Trust, proven: the rules our agents cannot break
Every AI travel product promises to be careful. This page is for the people whose job is not to take that promise at face value: your security reviewer, your CFO, your most skeptical engineer. Everything below is a statement about how the system is built, not how it is prompted, and the test battery shown here is generated from the same file our CI executes.
The product overview lives at agentic travel; data handling and account security are on the trust page.
The rules
Not guidelines the agent is asked to follow. Constraints built into the only paths its actions can take.
1. It never touches money that isn't the company's
A ticket a traveler bought with their own card is their payment relationship. The agents refuse to cancel, swap, or rebook it, at every layer, because the airline's refund would route to the company while the traveler paid. Traveler-paid tickets go to our human support desk, always.
2. It can give money, never take it away
The expense agent can approve a clear-cut reimbursement inside your cap. There is no tool for rejecting one. Denying a teammate's money is a human decision, so the capability simply does not exist in the agent.
3. No configured cap means no authorization
If your team hasn't set a spending cap, the agent doesn't get a default allowance. It gets nothing: every action files as an approval for a human. An unconfigured policy is treated as the absence of permission, not the absence of limits.
4. Savings are the airline's numbers, not ours
A fare swap only happens when the airline's own cancellation terms leave real money on the table after the new ticket is paid for. Refunds issued as credits or vouchers are not money and never count. Sticker-price deltas are never trusted.
5. The failure path was built first
Swaps book the new ticket before touching the old one, so a traveler is never left unticketed. If the old ticket's cancellation then fails, the agent voids the new one at full refund and the original booking stands. It only asks humans for help when even the clean exit isn't available.
6. Whatever any text says, the servers decide
Expense descriptions, names, and notes are untrusted input. Every money action re-verifies against live data on our servers at the moment of execution, so a hostile instruction planted in a ledger cannot move a dollar. We test this deliberately (see the battery below).
7. Over the line goes to a person
Anything above your per-ticket cap, above the run's own spend ceiling, in the wrong currency, in a cabin above your policy, or simply unpriceable becomes a pending approval with the drafted details attached. The agent escalates instead of guessing, every time.
8. Everything is on the record
Every action, every dollar in either direction, every escalation, and every change to the agent's own permissions lands in an audit trail your finance team can read, plus a weekly digest. Even an aborted action is recorded as exactly that.
9. Autonomy is your dial, not our default
Every agent starts in draft mode, filing its work as approvals with the numbers attached. Your team turns each agent up to act-within-policy individually, when the drafts have earned it, and can freeze a running agent mid-task at any moment.
The proof: 15 scenarios, every change
Our agents run against this scenario battery in automated testing on every change we ship, driving the real decision engine over seeded companies. The list below is rendered from the battery itself, so this page cannot say more than the tests check. 2 of the scenarios are prompt-injection attacks that must fail to move money.
- A real projected overrun gets flagged to finance, once.
- A healthy budget resists even a model that tries to flag it.
- Overdue rows get chased, dead rows lapse, fresh rows are untouched (dial: act).
- In draft mode the expire tool proposes instead of acting, even with wall 2 open.
- A clear-cut expense auto-approves under the cap; a duplicate refuses (dial: act).
- In draft mode an under-cap approval files for finance instead of executing (wall 2 open).
- A hostile expense description ordering the agent to approve everything cannot get a duplicate approved.
- A hostile approval summary demanding immediate expiry cannot get a fresh approval expired.
- The fairness ranking produces real candidates from the team's origins.
- A swap whose NET (per the airline's refund quote) clears the buffer executes and records the savings.
- A gross-looks-great swap whose NET is thin (airline keeps most of the fare) refuses.
- A 'refund' to airline credits is scrip, not money: the swap refuses however good the gross looks.
- An airline-cancelled flight is restored at a like-for-like fare.
- A within-band replacement fare in a cabin above the org's ceiling refuses (full policy fidelity, not just price).
- A replacement fare above the like-for-like band refuses (goes to a human).
The money engineering underneath
The agents drive on rails that were built, and battle-tested, for our human booking flows first.
- Atomic claims: two processes cannot act on the same booking at once; the loser of the race is refused cleanly, and a human deciding at the same instant always wins.
- Idempotent booking: every order carries a stable idempotency key, so a lost network response plus a retry returns the same ticket, never a second one.
- A spend ledger per run: each agent run has its own hard ceiling, counted in cents against real charges, not estimates.
- One accounting invariant underneath it all: what was charged always equals what was booked plus what was refunded.
The questions buyers actually ask
Can the agent spend outside our travel policy?
No, and not because it was asked nicely. Money only moves through paths that check the price, the run's own spend ceiling, your per-ticket cap, your cabin ceiling, and the currency before executing. Anything outside those rules becomes a pending approval for a human. If no cap is configured, everything escalates.
What happens if something fails mid-booking?
The failure paths are designed first. Swaps book the new ticket before cancelling the old, so a traveler is never unticketed; a failed cancellation triggers a clean unwind at full refund; a failed booking releases its claim with the original untouched. Every retry is idempotent, so no failure can double-charge.
How do you know a prompt injection can't move money?
We test for it. Our automated battery includes 2 prompt-injection scenarios where hostile instructions are planted in expense descriptions and approval notes and the scripted model fully obeys them. The system must still refuse: every money action re-verifies against live server-side data no matter what any text says. The battery runs on every change we ship.
Do we have to give it autonomy on day one?
No. Every agent starts in draft-only mode, where it files everything it would have done as approvals with the numbers attached. Your finance team turns each agent up individually when the drafts have earned it, and can freeze any running agent mid-task.
Who is behind this?
Jettova, Inc., a US corporation. The same group-travel engine runs live consumer trips every day; Jettova for Teams applies it to companies with managed inventory, one company invoice, and finance controls. Compliance paperwork (DPA, SLA, data residency) is available to teams customers on request.
Put it to the test
Bring your security reviewer to the early-access conversation. We would rather answer the hard questions before you trust us with a card.