Should You Give an AI Agent Your Resy Login?

“Give it your Resy login” hides three completely different transactions behind one phrase, and the gap between them is enormous. One grants a scoped permission you can withdraw in a click. Another copies your email address and password into a text file on a rented server. Both get described the same way in forum threads. This page separates them so you can judge the actual exposure rather than the marketing around it. Last verified 24 September 2026.

What are you really being asked for?

Three access models are in circulation, and they differ by what a breach would reach:

• A sanctioned connector. You authorize a named integration on the platform and it receives a token for a limited set of actions. Your password is never transmitted to the third party, and you revoke from the platform side. This is the model behind Resy inside ChatGPT since 10 August 2026 and the Amex-published Resy connector for Claude.
• A hosted booking service you connect an account to. The service holds a durable connection so it can act at 2am when you are asleep. Convenience and exposure rise together here, and the specifics vary sharply between vendors.
• A self-hosted script. Open-source booking bots typically want your email and password in a config or environment file so the script can authenticate as you. Nobody else holds it, and nobody else is protecting it either.

Why is a raw password materially worse than a token?

Because of what it reaches beyond dinner. A token is bounded: it does one category of thing, it can be withdrawn without changing anything else in your life, and revoking it does not require you to remember where else that secret has been used. A password is unbounded in two directions. It can do everything you can do on that account, including changing the email address on it, and if you have reused it anywhere, the blast radius includes services that have nothing to do with restaurants. Credential-stuffing attacks exist precisely because reuse is normal. The honest question is not “do I trust this developer” but “what happens on the day their server is compromised and they never find out.”

Does a scoped connector solve it?

It solves the credential problem and leaves the capability problem open. Two things worth knowing before you relax. First, scope is only as narrow as the platform made it, and you should read the consent screen rather than assume. Second, a connector that can act autonomously can act wrongly: CNN Business reported on 23 September 2026 that an Instinct agent booked a Tokyo restaurant a user had not asked for, carrying a 100 percent cancellation charge. No password was stolen in that story. The user was simply billed for something an agent decided. Ask what the tool can do unattended, not just what it can read. The builder-level view of how a connector exposes operations to an assistant is in the MCP server for restaurant reservations.

What does a self-hosted script expose that a service does not?

You, personally, become the security team. The credentials sit on a machine you patch, in a file you remember to keep out of a public repository, reachable by every other package that script depends on. There is a second cost people underrate: when the platform changes an internal endpoint, a script that authenticates as you can start failing in ways that generate retry storms, and the retries are attributed to your account. The technical realities of running one are covered in do reservation bots actually work, and the commercial alternatives in Resy sniper apps and reservation bots.

What should you check before connecting anything?

1. Can you revoke access from the platform, without emailing anyone?
2. Is a raw password requested, and if so, is that password used anywhere else?
3. What can the tool do without asking you first, and what does that cost if wrong?
4. Whose name ends up on the reservation, and on whose account?
5. What happens to the connection when you stop paying or delete your profile?

What SeatSwiper needs, and what it does not

The honest version rather than a comparison in my own favor. SeatSwiper needs your Resy, SevenRooms or OpenTable account connected, because the entire point is that the reservation lands on your account under your name rather than a house account. It does not store your password: you connect through a token handoff on Resy, or through the same email-code sign-in OpenTable itself uses, and it books through that connection. Its authority stops at the watch you set, so it will not book a city you did not name.

The parts that are still your risk to weigh: a connected account is a connected account, Resy terms restrict unapproved automation and SeatSwiper is not an approved partner, and platform security actions can disable an account and cancel reservations attached to it. I am not in a position to promise that will never happen to you, and neither is anyone else selling in this space. What I would rather you do is apply the five checks above to every option including mine. The price is published the same way, so you can see what you are agreeing to before you connect anything: your first successful booking is free, every booking after it is a flat $5 charged only when a table is actually landed, and there is no subscription. The exception is the cancellation watch, which costs $1 to arm. That dollar is charged the moment the watch starts, it is charged even if no table ever appears, and the free first booking does not cover it; a watch that wins costs the same $5 on top. For the wider trust question see whether it is safe to let AI book restaurants and the account-ban question in full.