Approval Workflows for AI Google Ads Changes

Your agent works a Google Ads account at the speed of a sentence — spinning up campaigns, resetting budgets and bids, adding negatives the moment you ask. An approval workflow for AI ads changes is what keeps that power under your command, and it has three layers: the client's per-call prompt (the mechanism), your policy on which actions stay gated (the judgement), and — on teams — the split between who proposes and who approves (the structure). This page covers all three as practice; the argument for why the loop exists at all is in why your ads agent needs an approval loop.

How the approval actually surfaces, client by client

The mechanism is built into MCP clients, not bolted on: when the agent calls a write tool, the client interrupts and displays the call before it executes. What you see varies by client; what happens does not.

• Claude (Desktop and claude.ai) shows a permission prompt naming the tool — update_campaign, add_negative_keywords — with the arguments visible, and offers allow once or allow always for that tool.
• Claude Code asks in the terminal per tool call, with the same option to allowlist a tool for the session or the project.
• ChatGPT shows a confirmation for write actions on a custom connector, naming the action it is about to take; you confirm or cancel.
• Gemini CLI and Cursor ask inline in the conversation, with per-tool "always allow" available once you trust a call shape.

Two properties hold everywhere. Reads never prompt — analysis stays frictionless. And the prompt shows arguments, not intentions: you are approving "set campaign 2104 budget to 2,000,000,000 micros", not "optimise my budgets". Read the arguments. That habit is the entire skill of approval-based ads management.

Which actions should stay gated — a working policy

Gating everything forever wastes the agent; gating nothing wastes the safety. A defensible default policy:

Action class	Examples	Policy
Reads	reports, audits, search terms	Never gated — by design
Zero-spend writes	negative keywords, paused campaign drafts, assets, renames	Gate at first, graduate to allow always within weeks
Spend-shaping writes	budgets, keyword and ad group bids, device adjustments	Gate permanently
Visibility writes	enabling campaigns or ads, pausing live spenders	Gate permanently
Destructive actions	any delete	Not gated — absent; the tools are never exposed

The last row is the one to understand precisely: deletion is not a tightly-gated action, it is a missing capability, enforced server-side in any letter case. The security model explains both enforcement layers. Everything you can approve is reversible, which is what makes the whole workflow survivable when you misjudge one.

"Allow always" is a promotion — treat it like one

Clients let you stop being asked about a tool. Use that deliberately, one tool at a time, in the order the first week playbook builds trust: add_negative_keywords first — it can only stop spend — then asset creation, then paused campaign scaffolding. A tool earns allow always when you notice you have stopped reading its prompts because they are never surprising.

Budgets and statuses never graduate. Not because the agent gets them wrong, but because those clicks are cheap and the mistakes are the only expensive kind. Five gated approvals in a weekly routine cost under a minute; that is the entire ongoing price of keeping spend under human sign-off.

Team patterns: who approves what

On a team, the client-level prompt is only half the workflow — the other half is who holds which connector. AdCopilot gives every teammate their own connector under their own Google sign-in, individually revocable, with an org able to narrow (never widen) each member's account scope — the model described in how teams share access. That enables three patterns:

• Builder and approver. The builder's sessions create everything paused — campaigns, ad groups, RSAs. The approver reviews in the Google Ads UI and enables. The enable action is the approval, and change history attributes each side correctly because everyone acts as themselves.
• Analyst with read scope. A teammate whose Google access is read-only gets an agent that can audit and report but whose write calls fail at Google's own permission layer — approval workflow enforced by account permissions, not etiquette.
• Agency with per-client scoping. Each member's connector is restricted to the client accounts they run, so an approval granted in the wrong tab cannot land in the wrong account — the connector cannot see it.

Underneath all three, every call — tool, account, success or refusal, reason, timestamp — lands in the connector's audit trail. Reviewing that log weekly is the team-level approval loop: not gating individual calls, but verifying the pattern of them.

Set your policy in the next five minutes

Do this now, in your client: run one harmless write — ask the agent to add a single obviously-junk negative keyword — and read the approval prompt end to end. Then write down your gate list: which tools you will allow always, which never. Two lines in a note. Every approval decision you make afterwards inherits from those two lines instead of being made fresh at 6pm on a Friday.

Not connected yet? Start a free pilot — your own Google sign-in, a private connector address, and the approval workflow above working in whatever client you paste it into. Seven days, up to five accounts, no card.