When ChatGPT Voice Sends Your Email, What Did You Actually Agree To?

Everyone's talking about which GPT-6 model runs your request. Nobody's asking which OAuth scopes give it the keys to your inbox.

ChatGPT Voice can now book appointments, send email, and post to Slack while you talk to it. That’s the headline, and it’s real enough. The reporting also names three new GPT-6 variants — Astra, Sol, Luna — routed behind the scenes depending on what you ask.

Here’s the thing nobody’s asking, and the thing you should: which model handled your request is the least consequential fact in that whole arrangement.

Think of it like a courier service. You care intensely about which key you handed the courier — the one to your mailbox, or the one to your front door. You do not care which van they drove to get there. The model routing is the van. The OAuth scope is the key. Almost every write-up leads with the van.

I can’t confirm the Astra/Sol/Luna naming against OpenAI’s own documentation, and I’d treat those labels as provisional until they show up in an official model card. It barely matters. Model selection is invisible plumbing — likely a fast small model for chit-chat, a heavier one for reasoning over your calendar, all decided server-side with no knob you control. Interesting engineering. Zero bearing on what a compromised session can do to your inbox.

The authorization is the whole ballgame. When you connect Gmail, Calendar, or Slack, ChatGPT doesn’t get vague “access.” It gets a token minted against specific, published scopes. Those scope strings are the real product spec. Google, for instance, hands out granular ones: gmail.send lets an app send mail but not read your archive; gmail.readonly reads everything and sends nothing; gmail.modify does both short of permanent deletion. Calendar splits calendar.events (touch events) from full calendar (touch everything). Slack has its own zoo — chat:write, channels:read, and friends.

So the question that actually decides your blast radius is: which of these did the consent screen request, and did you read it before tapping Allow? Nobody reads it. That’s the design, not an accident.

You don’t have to guess what you granted. Once a token exists, you can interrogate it directly. For Google:

1
2
3

curl "https://oauth2.googleapis.com/tokeninfo?access_token=$ACCESS_TOKEN"
# returns the exact granted scopes, the client it was issued to,
# and expires_in (seconds) — the ground truth, not the marketing

That expires_in is the second thing worth staring at. Access tokens are short-lived — typically an hour. That is not the number that matters. What matters is the refresh token, which has no such courtesy. It sits in OpenAI’s servers and silently trades itself for fresh access tokens whenever needed:

1
2
3
4
5
6

curl -X POST https://oauth2.googleapis.com/token \
  -d client_id=$CLIENT_ID \
  -d client_secret=$CLIENT_SECRET \
  -d refresh_token=$REFRESH_TOKEN \
  -d grant_type=refresh_token
# no user present, no voice prompt, new hour-long key on demand

This answers the persistence question the cleanest way possible. Access does not re-prompt you every voice session — that would be unusable, and no product ships it. The grant survives until the refresh token is revoked or expires (Google’s can go stale after six months idle; a Slack token generally lives until you kill it). You’ll only get bounced back to a consent screen when a refresh fails or the app asks for a scope it didn’t have before. Day to day, the assistant just… keeps having the key.

Which is the whole point, and the whole risk. A voice assistant that re-authorized on every request would be useless. One that holds a long-lived refresh token against gmail.send is a standing credential that a prompt injection buried in an email you asked it to summarize could, in principle, aim back at your own outbox.

So enjoy the demo. Then go to your Google and Slack security pages, find the ChatGPT grant, and read the scopes it actually holds. That list is the real spec sheet. The model names are just what’s painted on the van.