Skip to content
whitead

Fix: Excessive admin access on a Google Ads account

finding google ads updated 2026.05.20 8 min read
// contents · 7 sections
  1. Why this matters
  2. How to verify the issue
  3. How to fix it
  4. How to confirm the fix worked
  5. Confirmation checklist — run all five immediately after the cleanup pass
  6. Related rules + concepts
  7. Sources

A Google Ads account that carries five or more Admin-role users widens the blast radius of any credential compromise, accidental misconfig, or unhappy ex-freelancer with lingering access. Fix this before the next audit cycle — it costs nothing and removes a class of incidents that no bid tuning can undo.

Why this matters

Google Ads exposes five access levels — Admin, Standard, Read only, Email only, and Billing — and Admin is the only one that can add or remove other users, change account-level settings, link/unlink manager accounts, and approve sensitive operations like uploading Customer Match lists or changing conversion actions. The principle of least privilege says you grant exactly the role each operator needs to do their job, and no more.

The Whitead rule fires LOW when an account has five or more Admin-role entries, because that's the threshold above which agency-managed accounts almost always contain at least one of: a former freelancer never offboarded, a client-side stakeholder who only ever needed Read access, a vendor tool's service account holding Admin "for convenience", or a duplicate owner login. None of these are operational emergencies — but each one is a doorway, and the rule surfaces them as a single hygiene workstream rather than scattered one-offs.

This finding does not move CPA, ROAS, or impression share. It moves the probability that next quarter's incident report mentions your account.

How to verify the issue

  1. Open Admin → Access and security → Users tab. Google Ads lists every user with their assigned access level. Count the entries showing Admin in the Access level column.
  2. For each Admin, note the email domain. Cross-reference against your active staff roster (agency side) and your client's nominated stakeholders. Anyone matching neither list is a candidate for removal.
  3. Click each Admin entry → Edit. Google Ads displays the last-active timestamp where available. Users inactive for >90 days should be downgraded or removed regardless of role.
  4. Check the Managers tab on the same screen. A linked manager account (MCC) typically grants Admin-equivalent control to multiple agency operators via the manager hierarchy — those operators do not appear in the Users tab. Confirm the manager link is current and the upstream MCC's own user list is clean.

The rule fires on the simple ≥5 Admin count, but ≥5 alone is a soft signal — agency-managed mid-market accounts commonly run agency lead + client owner + 2 ops + 1 vendor = 5 legitimate Admins. Treat the finding as actionable when ≥5 Admins is paired with at least one risk factor:

  • (a) at least one Admin is inactive >90 days (step 3), or
  • (b) at least one Admin sits outside the agency's primary domain and outside the client's nominated stakeholder list (step 2), or
  • (c) the account is single-owner with no shared agency hierarchy (no MCC link in step 4), so a single compromised Admin = full takeover with no second-pair-of-eyes recovery.

When to escalate: ≥5 Admins + any one of (a)/(b)/(c) → run the fix this week. ≥5 Admins with none of (a)/(b)/(c) and a clean roster you recognize → log it, schedule the access-policy doc (fix step 5), revisit at next quarterly review.

How to fix it

Plan one 15-minute working session per account. Do this with the client's primary contact on a short call if any removals involve client-side users — surprise revocations damage trust even when they are correct.

  1. Downgrade routine editors to Standard. Anyone who builds campaigns, edits ads, manages keywords, or adjusts bids needs Standard, not Admin. In Admin → Access and security → Users, click the user → Edit access level → select Standard → Save. Standard retains all day-to-day operational permissions while removing the ability to add/remove users and change account-level security settings.

  2. Downgrade reporting consumers to Read only. Stakeholders who only open dashboards or pull reports need Read only. Same UI path; pick Read only. They can still view all data and export reports, but cannot change anything.

  3. Remove inactive users entirely. For accounts that have not signed in for >90 days, click the user → Remove access. If they need access later, re-invite at the correct (lower) level. Do not preserve Admin "in case".

  4. Audit any non-human Admin entries. Tool-vendor service accounts (bid management, reporting, attribution) almost never need Admin — Standard is sufficient for read+write API operations and the vendor docs usually confirm this. Email the vendor to confirm before downgrading.

    # Target end-state roster for a typical agency-managed account:
- 1× agency lead    → Admin
- 1× client owner   → Admin (optional, often Standard is enough)
- 2-4× agency ops   → Standard
- 2-5× stakeholders → Read only
- 0× inactive (>90d) of any role

  5. Document the access policy. Write one paragraph in the account's runbook: who gets which role, who approves new users, the cadence of access reviews (quarterly is typical). Without a written policy, the same drift recurs in 6 months.

"Use the access level that gives users only the permissions they need to do their job. Account admins can add, remove, or change access for other users."
— Google Ads Help, About access levels in your Google Ads account (accessed 2026-05-20)

For manager-account hierarchies, the equivalent guidance lives in About user access levels for your manager account — the same least-privilege logic applies at the MCC tier.

How to confirm the fix worked

Confirmation checklist — run all five immediately after the cleanup pass

Recall the compound criterion: the YAML rule fires on ≥5 Admins, but the real fail state is ≥5 Admins AND at least one risk factor (inactive >90 days, outside-domain Admin, or single-owner with no MCC). The checklist below clears both the count and the risk factors.

  • Admin count ≤4 on the Users tab (rule threshold is ≥5; staying at 4 or below clears the YAML flag with margin before drift). If you legitimately need ≥5 Admins, items 2-5 below are what makes that safe.
  • Every remaining Admin's email belongs to an active agency-side or client-side domain — no personal Gmail of unknown provenance, no vendor service accounts. (Clears risk factor (b).)
  • No user inactive >90 days at any role level (Admin, Standard, or Read only). (Clears risk factor (a).)
  • Manager-account link in Admin → Access and security → Managers points to your current MCC, not a legacy one. Stale MCC links are a quiet way for outsiders to retain control; a current MCC also clears risk factor (c) by ensuring the account isn't effectively single-owner.
  • Written access policy added to the account runbook with a named owner and a review cadence.

If all five pass, re-run the audit — the excessive_admin_access rule moves from warning → passed (when count ≤4), or stays at warning but is safe to dismiss as a known-good configuration (when count remains ≥5 with zero risk factors and a documented policy).

Methodology note. Whitead's excessive_admin_access rule is a single-flag count check evaluated at account scope on the account.users data source. Implementation detail (per audit_skills/core/rules/excessive_admin_access.yaml): a pre-aggregation filter access_role: ADMIN restricts the population to Admin entries only, then aggregation: count compares the result against the threshold (status warning at >=5, passed at <5). Without the filter, the count would include Standard and Read-only entries and the rule would fire on harmless multi-stakeholder setups. min_data_points is overridden to 1 (default 5) so that small teams with 1-4 Admins resolve to passed instead of insufficient_data. The rule is global (applicable_geo: [global]), runs on all campaign types, requires no history (requires_history_days: 0), and applies only to standard accounts (applicable_account_kind: [standard]) — manager accounts have their own access model and are evaluated separately. Severity is low by design: this is security hygiene, not ad delivery risk, and Whitead presents it as an informational warning rather than a remediation blocker.

  • Customer Match — the most sensitive operation Admin-role users can perform; tight Admin control is the upstream defense for first-party list governance.
  • Conversion tracking — Admins can edit conversion actions, so excess Admins also widen the surface for accidental conversion-config drift.
  • Server-side GTM for Google Ads — when measurement moves server-side, the inventory of "who can change the conversion endpoint" extends beyond Google Ads itself, and access policy needs to follow.
  • Fix: Conversion tracking missing — a sister governance finding when access drift correlates with misconfigured tracking.

Sources

// was this useful?
// anonymous · no personal data stored
← Back to Wiki