One subscription, one Google login per person

The shared-login problem

The usual way a team shares a tool like this is one login, or one API key, passed around. It works until it matters. Then three things go wrong at once.

• Everyone gets the widest access anyone has. If the key was made from the agency owner's Google account, the junior on their second week has the owner's reach into every client.
• Attribution disappears. Google's change history records the identity that made the API call. With a shared credential every change in every client account is attributed to the same person, forever.
• Offboarding means rotating everything. One person leaves and the key has to be replaced everywhere it was pasted, by everyone, at once.

None of that is a policy failure. It follows from the shape of a shared credential, so the fix has to be structural too.

How per-person access works

The organisation holds what is bought once. The person holds the credential. Concretely:

Organisation settings apply on top of the individual's and can only ever narrow them. A tighter account scope wins; the earlier of the two expiry dates wins; and a person is active only if both they and the organisation are. There is no combination of settings where joining a team gives someone more reach than they had alone.

Seats, joining and leaving

1. The owner sends an invite link. One link per organisation, and it can be replaced at any time, which immediately invalidates the old one.
2. The teammate signs in with their own Google account. They complete Google's consent themselves — the owner never handles their credential — and get their own connector address.
3. Seats are counted as active people. Switching someone off frees their seat for someone else.
4. Leaving is one command. Their connector stops working on the very next request. Their email stays claimed, so they cannot rejoin themselves with the invite link they still have in their inbox.

Scoping to specific clients

A connector can be restricted to named Google Ads customer IDs, at the organisation level or per person. A call to any account outside the list is refused at our server before it reaches Google, and the refusal is written to the audit trail with the account that was attempted.

This is the control that makes a manager account safe to connect. An MCC covers every client beneath it, which is convenient and also a very wide door; an allow-list narrows it back to the accounts that person actually works on.

The audit trail

Every call a connector makes is recorded — which person, which tool, which account, whether it succeeded, and refusals as well as successes. Two questions become answerable without detective work:

• “What did our connectors do in this client's account last week?”
• “Did anyone try to reach an account they shouldn't have?”

Google's own change history answers a related question independently, and because each person authenticates as themselves, it names them rather than naming the tool. The two records corroborate each other, which is exactly what you want when a client asks.

Manager accounts

You can point a connector at a Google Ads manager account so one sign-in covers many clients. Two things are worth doing at the same time:

• Set an allow-list unless you genuinely intend every account under the MCC to be reachable.
• Start read-only. Across a book of clients, the first week is worth spending on what the agent finds before considering what it should be allowed to change. More on that sequence in earning autonomy.

What to tell a client

Agencies are usually asked some version of “so an AI has access to my account?” The accurate answer is short, and it is better delivered before the question arrives:

The team uses an AI assistant connected to your Google Ads account through Google's own sign-in, with the same access we already have and no more. It cannot delete anything. Changes appear in your Google change history under the name of whoever made them, and we can show you a log of every action on request. Your account data is not stored by the tool and is never used to train any model.

All four of those claims are things you can demonstrate rather than assert — the security page sets out how each one is enforced.

Frequently asked questions