We Gave AI Write Access to Ads. Never Delete Access

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?"

Reversible vs irreversible: the line that matters

Sort every Google Ads action by its undo path and the safety problem gets small:

Action	Undo path	What survives a mistake
Read anything	Nothing to undo	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 reversible mistake costs its interim damage; an irreversible 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: undo

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 reversible actions are correctable failures: notice, revert, 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

AdCopilot's underlying server implements 36 tools. Hosted connectors are given 32. 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. Two layers, both server-side, neither 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 flow freely.
• 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 reversibility 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:

1. Read week. Audits only — wasted spend, conflicts, disapprovals. You learn how the agent reasons before it touches anything.
2. Inert writes. Negatives, paused drafts, assets. Approvals are quick because nothing here can spend.
3. 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 "undo" 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 a free pilot — 7 days, full toolset, up to five accounts, no card — and try it on your own account.