A refresh token is the long-lived key an application holds after you approve an OAuth consent screen. It does one thing: it mints access tokens — the short-lived credentials that actually accompany API calls. Access tokens expire within the hour; the refresh token is how the app gets the next one without marching you back through sign-in. It is why an AI agent you authorised in January still runs your Google Ads account in June. It is also, for exactly that reason, the crown jewel of the whole integration.
How refresh tokens work
The division of labour is deliberate:
| Access token | Refresh token | |
|---|---|---|
| Lifespan | Short — expires within the hour | Long — lives until revoked or invalidated |
| Job | Sent with each API call | Exchanged for new access tokens |
| If stolen | A damage window of minutes | API access until revoked |
| Where it lives | In memory, transient | Stored by the application |
Short-lived access tokens limit the blast radius of interception; the refresh token concentrates the long-term trust into one storable object. Security analysis of any integration therefore collapses to a single question: what happens around that object?
Where connectors store it — and how to ask
Every Google Ads integration holds a refresh token somewhere. A local MCP server keeps it in a config file on your machine — plaintext unless you arranged otherwise. A hosted connector stores it server-side, and the vendor's answers become part of your security posture. Ask three questions, verbatim:
- What exactly do you store? The strong answer is minimal. AdCopilot stores one credential — an encrypted Google refresh token — never your password, and not your advertising data, which is read live and passed straight to your AI client.
- How is it encrypted at rest? "Encrypted" should be the immediate, specific answer. A vendor vague here is vague everywhere.
- How do I end it? There must be two paths — one on the vendor's side (disconnect, kill switch) and one that needs nothing from them: revoking the app from your own Google account's third-party access list, which invalidates the token wherever it sits.
What ends a refresh token
Revocation by you, from your Google account — the path worth rehearsing. Revocation from the vendor's side. Google-flagged security events. Extended disuse. And apps still in OAuth testing mode get tokens that expire after days — the detail that explains most mysteriously dying hobby setups. What does not usually end one: changing your password alone, a behaviour Google reserves for certain other scopes. Assume the token lives until deliberately killed, and plan custody accordingly.
Token custody as a buying decision
The refresh token is the piece of the AI stack that exists whether or not you think about it — connecting an assistant to Google Ads means someone, somewhere, is holding one for you. The AI-era shift is that custody became a product decision you can compare. Vendors who talk about tokens precisely — what is stored, how it is encrypted, how it is revoked — are showing you their security architecture. Vendors who say "bank-grade security" and change the subject are showing you something too.
Rehearse the revocation once. Find the app in your Google account's connections list, remove it, watch the connector fail, reconnect. Three minutes, and the exit is no longer theoretical.