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 — the campaign update, the negative-keyword add — with the arguments visible, and offers allow once or always allow for that tool. It asks for reads too until you set the connector's read-only tools to Always allow under Customize, then Connectors.
- 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 change nothing, so once you allow them (Claude asks for each the first time unless the read-only group is set to Always allow) 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 can be put back, 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: adding 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 free — add the connector URL to whatever client you use, sign in with Google, and the approval workflow above is working. Seven days on the full Pro plan for a new workspace, no card.