All posts

記事AI agents

How to let an AI agent into your ad account without losing money

An approval gate is a step that holds every change an AI agent proposes until a person has read a preview of it and said yes.

An AI agent with write access to an ad account can spend real money in minutes. The risk is manageable, and most of the controls already exist in the ad platforms. This checklist covers what to set up before an agent touches anything, whichever tool you use.

Ruslan10 min read

What can go wrong when an AI agent has access to your ads?

Three things, and all of them cost money. The agent misreads the request and changes the wrong object: a budget raised on the campaign next to the one you meant. It repeats a call after a timeout and creates the same campaign twice. Or it does exactly what you asked, and what you asked was wrong, because a number it read was stale or incomplete.

None of these are exotic. A person working in a hurry makes the same mistakes. The difference is speed: an agent can make forty changes in the time it takes you to read one. So the controls below are not about trusting the model less. They put a person and a platform limit between a mistake and the spend.

1. Start read-only

Give the agent read access first and keep it that way for a week or two. Reading is where most of the value is anyway: performance questions, search term reviews, finding campaigns that stopped serving. None of it needs write access, and a read cannot spend anything.

The platforms have a read-only level built in:

  • Google Ads. Under Admin → Access and security, a user with Read only access can view campaigns and run reports but cannot edit anything. Standard adds editing; Admin adds managing users and links.
  • Meta Ads. In your business portfolio settings, ad account access is granted per task. A person or system user given View performance only can read results without managing campaigns.

If the tool connects with your own login, the access it gets is the access that login has. Connecting with an admin login and hoping the tool only reads is not the same as read-only.

2. Ask for permission per tool, not per session

Most AI clients ask before they call a tool, and most let you allow a tool for good. That setting is only useful if reads and writes are separate tools. Suppose one tool both lists campaigns and changes budgets. Allow it once to save clicks, and you have also allowed every change it can make.

Check how the tools you connect are split. You want to be able to allow everything that reads, permanently, and still be asked before each call that writes.

3. Require a preview with a diff before any change

A change you cannot see before it happens is a change you cannot approve. Before a write runs, you should see the object it touches, each field before and after, and what the change is expected to do. “Updating budget” is not a preview. “Campaign Brand, daily budget $50.00 → $75.00” is.

Both big platforms can check a change without applying it. The Google Ads API takes a validate_only flag on mutate requests, and the Meta Marketing API takes execution_options=["validate_only"]. The platform applies its own rules and creates nothing. A tool that uses them finds a rejection before you approve, instead of after.

4. Keep a person on the approve button

The agent proposes; you decide. That split is the single most useful control on this list, because it moves the judgement call to the person who knows what the business can afford. An agent can tell you a keyword costs $140 per conversion. Whether $140 is too much depends on what you sell.

Read the preview before you approve it. The agent writes the analysis and the copy, and it can be wrong. Approving without reading turns the gate back into a formality.

Watch for approvals that pile up. If you approve twenty changes in a row without opening one, ask for fewer, larger proposals, or narrow what the agent is asked to do.

5. Make sure a change runs exactly once

Networks drop connections. When a create times out, the agent cannot tell whether it failed or succeeded without a response. Retrying blindly is how one campaign becomes two, both spending.

Two safeguards close this. Each approved change should carry an idempotency key, so a second attempt with the same key is ignored. And after a timeout, the next step should be a read that checks what exists, never another create. Ask any tool you evaluate what it does after a create times out. “We retry” is the wrong answer.

6. Create everything paused

A new campaign should arrive paused, so that nothing can spend until a person turns it on. The objects inside it can be active: a paused campaign delivers nothing, so its ad groups and ads wait with it, and turning the campaign on is the whole launch.

The rule is about the topmost new object. An ad group added to a campaign that is already running should itself be paused, and so should an ad added to a running ad group. Otherwise a “draft” goes live the moment it is created.

7. Put a hard cap on spend at the platform level

Every control above lives in the tool. A platform-level cap still holds if the tool, the agent or you get something wrong.

PlatformControlWhat it does
Google AdsCampaign daily budgetA day can spend up to twice the average daily budget; a month no more than 30.4 times it
Google AdsAccount budget (Billing → Account budgets)Caps all campaigns together over a period. Available on monthly invoicing accounts
Meta AdsAccount spending limit (Payment settings)Pauses all ads when lifetime spend reaches it. Does not reset monthly on its own
Meta AdsCampaign spending limitCaps one campaign’s total spend

Set the account-level cap to what you are willing to lose in the worst week, not to what you plan to spend. On Meta, remember the limit counts lifetime spend: when you reach it, you reset the amount spent in Payment settings, and the limit applies again from zero.

8. Keep an audit log you can read

You should be able to answer “what did the agent change last Tuesday” in under a minute. Google Ads Change history covers two years and lists changes made through the API as well as the interface. Meta’s Activity history in Ads Manager does the same.

The platform logs show what changed. They do not show why, or which request led to it. A tool worth using keeps its own record: the request, the preview you saw, your decision, and what the platform stored afterwards.

9. Know where the tokens live

Access to an ad account is a token. Whoever holds it can act as you, within the access it was granted. Ask three questions of any tool: where is the token stored, is it encrypted, and does it ever reach the AI client? The right answers are on the tool’s server, yes, and never. A token pasted into a chat lives in that chat’s history.

10. Know how to revoke access

Before you connect anything, find the off switch. On Google, third-party access is listed in your Google Account under Security → Your connections to third-party apps and services, where you can remove it. On Meta, remove the app from the business portfolio or from your Facebook Settings → Business integrations, and revoke any system user token you generated. Removing a user from the ad account also ends their access.

Revoking access changes nothing in the account. Campaigns keep running exactly as they are, so pause anything you need paused first.

How does Adako handle each of these?

Adako is an MCP server that connects Claude, ChatGPT and other assistants to Google Ads, Meta Ads, LinkedIn Ads and ChatGPT Ads. The checklist above is how it is built:

  • Reads are free and separate. Each platform has a read router, such as google_ads, and a write router beside it, google_ads_write. You can allow the first for good and still be asked before each call to the second.
  • Every write is a proposal. Google Ads and Meta checks run in the platform’s validate-only mode, and you see a field-level diff with the expected impact. Nothing reaches the platform until you approve, in the chat or on the Approvals page. A pending proposal expires after 48 hours.
  • Execution happens once. Each proposal carries an idempotency key and is claimed atomically. A create is never retried after a timeout, and an identical create on the same day is refused until the assistant has checked what already exists.
  • Creates are paused. The topmost new object is paused, always, with no flag to skip it. The result names what is paused and gives the one call that turns it on.
  • Read-back and a record. After a change, Adako reads the object back from the platform and reports what exists. Every proposal keeps its preview, decision, result and read-back.
  • Tokens stay on the server. Platform tokens are encrypted and never sent to the assistant.

Adako does not replace the platform caps in step 7. Set those as well. The full detail is in the safety model, and Google Ads with an AI agent shows what the day-to-day work looks like.

The short version

  • Read-only access first. Most of the value is in reads, and reads cannot spend.
  • Allow read tools for good; get asked before every write.
  • Approve only what you have seen as a diff, and read it before you click.
  • One approved change runs once. After a timeout, check before you create.
  • New campaigns arrive paused, and turning them on is your call.
  • Set an account-level spend cap on the platform, whatever tool you use.
  • Know where the change log is, where the token lives, and how to revoke it.

Ruslan builds Adako, the MCP server these guides are written alongside, and writes up the ad-ops procedures behind it.

Keep going