🍸 Bone Dry Martini
Observations, sans vermouth
2026 · 06 · 12 / 1103 words /[ai] [hospitality] [security] [HITEC 2026]

Who's Asking?

The Four Doors Hiding Inside "Logged In"

A guest asks an AI assistant a four-word question: "Show me my bill."

Whether that's great service or a privacy issue comes down to one thing. Not the question, not the guest, not the AI. It's the door the question came through.

The industry is wiring its APIs into AI platforms at a remarkable pace — brand deals, GPT apps, connectors, agents. And every time the security question comes up, someone says the same eight words:

"Well, the user is logged in, so we're good."

That sentence is doing an enormous amount of unearned work. Because "logged in" isn't one thing. There are four trust contexts a guest can be sitting in, and from the chat window they look identical. The difference only shows up underneath.

Four doors. Same guest. Same question. Four different correct answers.


Door 0 — Anonymous

No account, no login. Somebody opens a public assistant and asks about your hotel.

Nobody knows who this is, and that's fine, because this door is for discovery — rates, availability, "is the pool heated." Public data, no PII, no side effects. The AI is a better search box, and a better search box is useful.

"Show me my bill" here? Can't do it. Nobody argues with that.

One wrinkle: the guest could authenticate mid-session, grab something, leave. But when the session ends, the trust evaporates with it. Every visit starts from zero. Nothing for trust to stick to — hold that thought.


Door 1 — Platform (The Trap Tier)

Now the guest is logged in. To the AI platform — a ChatGPT account, a Claude account, whatever's next.

Here's the uncomfortable part: to your brand, this is almost indistinguishable from Door 0. The platform knows who this is. You don't.

Nothing verified has reached your systems. When someone says "the user is logged in," this is the door they mean — and they're pointing at a login that belongs to someone else's company.

It's the trap tier because it doesn't feel anonymous. The product team sees an authenticated session and relaxes, and the whole weight of that comfort rests on a credential your brand never issued and cannot inspect.

But Door 1 isn't worthless. What it gives you isn't authentication — it's continuity. That platform user ID can't tell you this is loyalty member 8675309, but it can tell you it's the same someone who was here last Tuesday. Door 0 had nothing for trust to stick to. This is that thing.

That's what makes account linking work. The guest does the real authentication ceremony once — a proper handoff to brand login, servers, and checks — and the brand binds that member identity to the platform anchor. After that, on most platforms at least, the sessions arrive carrying a durable link instead of nothing.

But the link and the privilege should be separate decisions. Your bank already gets this: being logged in shows your balance, wiring money makes you re-enter your password. Good enough to hold the relationship; not good enough for a moment of consequence. Identity people call it step-up auth.

Hospitality is going to have to learn the reflex.

So "show me my bill" through Door 1 isn't one answer. It's three, set by a dial you have to consciously turn: unlinked (treat as Door 0), linked and sufficient (here's your bill), linked — step up first (prove it's you).


Door 2 — Brand-Authenticated (The Target)

Now the guest did the handshake in this session. Your systems issued a user-scoped token, and your API checks it on every request.

This is where every serious brand integration should be living. The folio, stay history, and profile are unlocked on one non-negotiable condition: ownership enforced per request, server-side, below the AI layer. Not "the user is logged in." Token says 8675309, folio belongs to 8675309, match or refuse.

This is the target. Most current integrations aren't quite here yet — they're likely Door 1 sessions calling partner-authenticated APIs wearing a Door 2 costume. The badge check might happen in the middleware, if it happens at all. That risk was at least bounded when the middleware was a rigid certified channel manager. It is not so fine when it's an AI platform mediating natural language from an unknown surface.

Door 2 done right is achievable. But it requires user-scoped tokens, per-request enforcement, and an honest reckoning with how long the delegation lives — because a connected session the guest forgot about in March could still be a live credential in June.


Door 3 — Fully Managed (The Ceiling)

The guest is on your site, authenticated to you. Your backend holds the session. The AI is a component inside your house, not the host of it.

Every question about Door 1 and Door 2 — whose login is this, how long does the delegation live, whose policy governs the transaction — has the same answer here, and the answer is you. This is the only door where full agency, up to charging a stored card, is defensible. Not because the AI got smarter. Because the architecture is accountable.

Many brands and groups may not get here for their AI platform integrations. Perfectly fine. It's the ceiling, not the mandate — it is the reference point for what full accountability looks like when you own everything.


What "Logged In" Smuggles

D0 · Anonymous D1 · Platform D2 · Brand D3 · Managed
Who issued the identity? nobody platform YOU YOU
What can your API verify per request? nothing continuity only ownership claims full context
Who owns the moment of consequence? n/a platform shared, awkwardly YOU
"Show me my bill" response? Hard pass "Link your account" or setup-auth "Here is your bill" "Here it is. Shall I close to the card on file?"

The zone of trust isn't established at login. It's established at every request, by whether your API checks the badge against the resource.