AdCopilotby Atromx

Refresh Token: How AI Tools Stay Signed In

What a refresh token is, how it differs from an access token, where connector vendors store it, and the custody questions worth asking.

Updated 2026-08-10Atromx IntelligenceGoogle Ads · Search, PMax, Display, YouTube, Demand Gen
The short answer

A refresh token is the long-lived credential an application receives after you grant it OAuth access. It cannot sign in to your Google account; its single job is to mint short-lived access tokens that authorise API calls, so the app stays connected without asking you to sign in again. Where a vendor stores your refresh token, and how it is encrypted, is the most important security question about any Google Ads integration.

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:

  1. 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.
  2. How is it encrypted at rest? "Encrypted" should be the immediate, specific answer. A vendor vague here is vague everywhere.
  3. 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.

Frequently asked questions

Can a stolen refresh token empty my ad budget?

A stolen token grants the same API access the app had — for Google Ads, real reads and writes — until it is revoked. It cannot log in to your Google account or reach billing sign-in, but API-level damage is real, which is why custody matters: encryption at rest, minimal storage, and a revocation path you can execute in seconds. Revoke the app's access and the stolen token dies with it.

Do refresh tokens expire on their own?

Not on a fixed schedule, in the common case. A Google refresh token for a published, verified app keeps working until something ends it: you revoke access, Google flags a security event, the token goes unused for an extended period, or the app was in testing mode, where tokens die after days. Treat them as living credentials to be revoked deliberately, not credentials that quietly age out.

The offer

Try it on your own account for a week

The full set of tools for the week, so you can see what it actually does — and it still cannot delete anything. No cost, no card, no contract: you connect your own Google account and can withdraw the access whenever you like.

  • Up to 5 accounts
  • One week
  • Full tools
  • No card
Keep reading