Most debates about AI in ad accounts argue the wrong line. One side wants read-only access, which keeps you safe and keeps the AI useless for half its job. The other wants full autonomy, which nobody responsible for a budget actually ships. The line that matters runs elsewhere: between actions that can be undone and actions that cannot. Draw it there, enforce it in the server rather than in the prompt, and full write access stops being brave — it becomes rational.
The wrong debate: read-only vs full access
Read-only is a real position with a real cost. An agent that can only read your account is an analyst who ends every finding with "now go do it yourself" — the wasted spend it found stays found and unfixed until a human retypes the fix into the interface. Most of the value of connecting an AI to an ad account at all sits in closing that loop: the same conversation that finds the leak kills it — the negatives go in as you speak, in seconds.
Full access is not a position so much as a shrug. An agent that can do anything includes an agent that can do the one thing no approval workflow reliably survives: destroy something permanently on a misread. The debate stalls because both camps are answering "how much should AI do?" when the useful question is "which mistakes must remain impossible?"
Recoverable vs permanent: the line that matters
Sort every Google Ads action by its way back and the safety problem gets small:
| Action | Way back | What survives a mistake |
|---|---|---|
| Read anything | Nothing to put back | Everything |
| Add keyword, negative, asset | Remove or pause the addition | Everything |
| Create campaign (arrives paused) | Never enable it | Everything — it cannot spend |
| Pause / enable | Flip it back | Structure, history, learning |
| Budget or bid change | Set the old number back | All but the interim spend |
| Delete (status REMOVED) | None | Nothing — it is gone |
Every row except the last is recoverable, and the worst recoverable case — a bad budget change running for a day — costs money but destroys nothing. The last row is different in kind, not degree. In the Google Ads API there is no delete button as such: setting an entity's status to REMOVED is the deletion, and it is permanent. A safety model that treats that row like the others, just with a sterner confirmation dialog, has misunderstood it.
The asymmetry deserves one more sentence, because it is the whole argument. A recoverable mistake costs its interim damage; a permanent one costs the entity plus its history plus every future decision that history would have informed — a deleted campaign takes its performance record, its search terms archive and its learning with it. You are not weighing two amounts of risk. You are weighing a cost against a loss.
What pause, budget and bid changes have in common: a way back
The writes that matter day to day — pausing a bleeding campaign, raising a budget before a promotion, tightening a target — share a property worth naming: each one is a state you can restore. That property is what makes an approval loop sufficient for them. Approval is a judgement checkpoint, and judgement failures on recoverable actions are correctable failures: notice, put it back, move on. The account's history, structure and learning are all still there.
This is why "the AI changed my budget wrongly" is an incident, while "the AI deleted my campaign" would be a catastrophe — and why the two must not be governed by the same mechanism. Incidents are managed with process. Catastrophes are prevented with architecture.
Why the remove tools are absent, not forbidden
As of v2.16.0, AdCopilot's underlying server implements 58 Google Ads tools: 47
in its fork of Google's MCP server, and 11 audit tools AdCopilot runs itself.
Hosted connectors are given 54 of them. The four missing ones are the
remove_* tools, and the gap is
the design: they are not disabled, not hidden behind a setting, not waiting
for an enterprise tier. They are absent from the tool list an agent ever
sees.
Behind that sits a second, independent layer. If any mutate call arrives carrying a status of REMOVED — whatever the tool, whatever the letter case, whatever creative phrasing produced it — the server refuses it before it reaches Google. And the tools that set a status — on a campaign, an ad group, an ad, a keyword or an attached asset — refuse REMOVED themselves, with a message that says to pause instead. Three layers, all server-side, none dependent on the model's cooperation.
The distinction matters because the alternative — a rule in the system prompt saying please never delete — is a politeness convention, not a safety property. Prompts can be overridden by injection, confusion or plain model error; capability absence cannot. It also survives the failure modes nobody designs for: the new teammate's over-eager prompt, the model update that reasons differently, the pasted spreadsheet that happens to contain the word "removed" in a status column. Server-side enforcement does not care how the request was produced — only what it asks.
You can verify the difference yourself in one minute: ask a connected agent to delete something, deliberately, and watch the refusal come back from the server. A system's real safety model is what it does when asked to do the wrong thing.
Defence in depth: what surrounds the line
The no-delete line is the floor, not the whole building. Around it, the same architecture stacks controls that each fail independently:
- Approval by default. The AI client surfaces every write — the exact tool, account and change — before it executes. Reads change nothing, so they can be allowed once and left to run.
- Audit trail. Every call is recorded: tool, account, success or refusal, reason, timestamp. Refusals are evidence, not embarrassments.
- Scoping. A connector can be restricted to specific customer IDs, so an agent working one client physically cannot touch another.
- Kill switch. Per connector and per organisation — access dies in one action without touching your Google password.
- Revocation at the source. The Google grant itself can be withdrawn from your own Google account at any time; the connector holds one encrypted refresh token, never your password.
Note the shape: none of these controls depends on another working. An approval mistake is caught by the audit trail; a leaked address is ended by the kill switch; and underneath all of it, the irreversible action stays impossible.
For teams the same stack scales sideways: each member connects under their own Google sign-in, an organisation can narrow a member's access but never widen it beyond what Google granted them, and every seat is individually revocable. The no-delete line does not get negotiated per seat — it is the floor under everyone, which is what makes delegating access to a five-person team the same decision as delegating it to one.
What this means for piloting AI on a live account
The recoverable-versus-permanent line changes what a sensible pilot looks like. You do not need a sandbox account, because the blast radius is already bounded: reads are free, additions arrive inert, spend changes pass through your approval, and deletion is off the table by construction. A live-account pilot in three moves:
- Read week. Audits only — wasted spend, conflicts, disapprovals. You learn how the agent reasons before it touches anything.
- Inert writes. Negatives, paused drafts, assets. Approvals are quick because nothing here can spend.
- Governed spend changes. Budgets and statuses with evidence attached, one click each, every action logged.
Somewhere in that first week, run the deletion test. The refusal you get back is the whole argument of this page, executed: write access wide enough to be useful, and a hard wall exactly where the way back stops existing. That is what a safety property looks like when it is real — silent, boring, and impossible to talk the system out of. Start free — 7 days on the full Pro plan for a new workspace, no card — and try it on your own account.