Translated from the Japanese original on mureo.jp.
When you hear “hand ad ops to an AI,” the first worry is probably whether it will move budgets on its own or change settings into something strange. To put the conclusion first: the risk is real. But that risk can be held down considerably by how you design the mechanism. This article lays out what is dangerous about delegating ad ops to Claude Code, and how to design for delegating safely.
The overall picture is covered in Can you automate ad ops with Claude Code?, so here we go deeper on safety alone.
What is dangerous
Being wrong, faster, with no criteria for judgment This is the most fundamental risk. The AI looks only at the surface of the numbers and quickly executes changes that look plausible. It can shift budget toward a product you do not want to grow as a business purely because its CPA is low. The faster the hands, the faster the mistakes spread.
Hallucination, and execution that does not stop Claude Code’s agent is capable and will try to write its own code to get things running. A GAQL syntax mistake fails with an error, so you notice it; the more troublesome case is a wrong change that passes as plausible. If bids or budgets get touched on a “this seems about right” basis, undoing it later takes work.
Losing the ability to explain Without a log of changes, you cannot answer “why did this move?” after the fact. Being unable to discharge accountability to a client or a manager is a serious problem in ad ops.
Handling of credentials Where you put your ad account credentials is also a concern precisely because the party you are delegating to is an AI.
Pitfalls people actually hit
Everything above is what to think through before you delegate. What people actually hit, once they have delegated, sits a little earlier and closer to the work itself. Five common shapes.
Mistaking a failed fetch for zero results Did the API return nothing, or was that day genuinely zero? An agent will sometimes treat both as “0.” Read a zero as a real result and carry it into a budget decision, and you stop a campaign that was running. When a fetch fails, do not return zero — treat it as a failure. This has to be settled on the mechanism side.
Stopping something mid-learning with a mechanical rule A campaign that has just started delivering has neither the spend nor the results yet. Apply a rule like “cut the budget if CPA exceeds the threshold” as written, and you kill delivery before it gets off the ground. Unless you write the exception up front — nothing in its learning phase gets judged on efficiency — the AI will execute the rule exactly as stated.
Handing over write access and autonomous execution together Read-only means a mistake is only a misreading. Let it act on its own with write access and irreversible changes go in. With an ad account, neither the delivery you stopped nor the budget you spent comes back. Start read-only and hand over write access once the scope is settled. Do not reverse that order.
Raw numbers, AI proposals, and human decisions mixed together When all three sit in the same place, after a while you cannot tell which ones were settled. It bites hardest at handover. Keep the numbers pulled from the API, the proposals the AI made, and the decisions a human approved in separate places.
Answering that something exists when it does not It will report that a capability is available when the official API has no such thing, or produce numbers without showing the source. Design does not fully prevent this. Building on the assumption that a verification step against the platform’s own specification stays with the human is, for now, the realistic approach.
Of the five, three — the learning-phase exception, write access, and separating human from AI — can be held down considerably by the design below. The other two, failed fetches and hallucination, can be reduced but not removed. When you decide how much to delegate, factor in that those two remain.
Approval alone does not make it safe One more thing, about approval itself. Requiring a human to confirm before execution is an easy safety device to understand, but as the number of confirmations grows, approval becomes a formality. Wave a queue of changes through together and it is no different from having no approval at all. What works is deciding, separately from approval, on lines that cannot be crossed, in numbers. A daily budget ceiling, the range of accounts that may be touched, operations that are forbidden. These stop the machine before a human judges, so they keep working when attention slips.
Designing for safe delegation
The dangerous points, flipped around, can be held down by design. Settle these four in advance and the range of what you can delegate changes.
1. Hand over the criteria for judgment, in writing, up front Write out persona, strengths, brand thinking, and goals once, and make every diagnosis reference them. The AI then proposes in order of “closest to the business goal” rather than “cheapest CPA.” The idea is to close the gap between optimizing numbers and optimizing the business with criteria articulated in advance.
2. Narrow the scope of permitted changes in advance Read-only by default. For anything that touches budgets or bids, require approval and set a ceiling as well. As noted above, approval turns into a formality easily, so neither one is enough on its own. With a trainee at the controls or during a sensitive delivery window, this “do not act on your own” design is what lets you delegate with confidence.
3. Keep every change in a log Record what was changed, why, and when, in a form you can revert. If you can answer “why did the budget move?” with a record, you can discharge accountability. Explaining ad ops is something you do with records, not memory.
4. Do not let credentials leave Keep account credentials inside your own environment as much as possible, with no cloud relay, sending them only to the official APIs. Precisely because the party you are delegating to is an AI, this part needs to be firm.
Summary
Handing ad ops to Claude Code is not, in itself, dangerous. What is dangerous is delegating with no criteria for judgment, no safety mechanism, and no log. Design the four points above and you keep the advantage of speed while holding accidents down. We built mureo precisely to have this “design for safe delegation” built in from the start. For concrete usage, see also Driving Google Ads from Claude Code. If the worry is the platform’s own enforcement rather than the operational risk, that is covered separately in Can connecting your ad account to Claude get it banned?.