← All posts

  • claude-code
  • mcp
  • safety
  • governance
  • ad-ops

Can connecting your ad account to Claude get it banned?

The rumour says accounts get suspended for wiring ads into an AI agent. What the Google and Meta terms actually prohibit, which route puts the account at risk, and the checks to run before you connect a client.

Can connecting your ad account to Claude get it banned?

The question arrives in almost the same words every time. Someone saw a post claiming an ad account got suspended after being wired up to Claude, and wants to know whether that can really happen before connecting an account of their own. Often it is a client’s account, spending six or seven figures a month, which makes the question considerably less casual.

The honest answer is that the question is underspecified. “Connecting your ad account to Claude” covers two integrations that have nothing in common but the sentence. One is explicitly permitted and governed by terms you can read in an afternoon. The other is explicitly prohibited, and it is the one that puts the account itself at risk. Which of the two you are buying is frequently not obvious from a product page.

Two routes, and only one of them is authorized

Meta’s Terms of Service prohibit accessing or collecting data from Meta Products through automated means without prior permission, and the clause applies whether or not the person is logged in. The same section prohibits misusing access tokens or collecting other people’s credentials. That sounds at first like it bans every integration, but the terms point at the authorized route in the next breath: the Platform Terms, which is the developer agreement covering apps, permissions, app review, and the Marketing API.

So the dividing line is not “automation, yes or no.” It is whether the automation goes through a registered app that Meta has granted permissions to, or through your logged-in browser session. A tool in the first category is doing what the terms describe. A tool in the second category is doing the thing the terms name as prohibited, using your cookies, from your machine, under your identity.

Google draws the same line in a different place. The Google Ads API has its own published policies, which run to a list of obligations and prohibitions for token holders: no scraping Google properties, no letting third parties use your token so they can avoid applying for their own, no attempts to conceal API activity from Google’s monitoring. Separately, the advertising policies prohibit “practices that circumvent or interfere with Google’s advertising systems and processes.” A script driving the Google Ads interface as if it were a person is a much easier fit for that sentence than a client calling a documented endpoint with a token Google issued.

What the official route actually risks

Take the authorized route and the enforcement surface changes shape. It stops being your ad account and becomes your API access.

On Google’s side the unit of enforcement is the developer token. Tokens come in access levels: Test, Explorer, Basic, and Standard, with different daily operation caps and different application processes. Basic review is quoted at five business days, Standard at ten. Standard access additionally carries Required Minimum Functionality, a list of features a full-service tool has to implement, which does not apply to the lower levels.

The enforcement Google states for that token is graduated. It can monitor and audit API activity, downgrade Standard access to Basic, impose quota limits, levy non-compliance fees, revoke tokens left unused for more than ninety days, and terminate a token entirely. There is one place where the two surfaces touch: if the manager account behind your developer token gets suspended for policy violations, your API access stops until you fix the account. The causation runs from the account to the token, not the other way round.

Meta’s version is comparable. The Platform Terms let Meta suspend or terminate developer access, with or without notice, for violations, non-responsiveness to an audit, or suspected misuse, and unused API access gets suspended after twenty-eight days. Again: the app loses access. That is a different event from an ad account being disabled.

None of this means the official route is consequence-free. It means the consequences are published, graduated, and aimed at the integration rather than at your advertising.

Where account suspensions actually come from

The suspensions people are afraid of are real, but the search for their cause usually ends somewhere other than the AI. Accounts get disabled for what the ads say, where they land, how they are paid for, and for evasion: cloaking, obscuring the destination, opening fresh accounts after an earlier suspension. Platforms link those accounts back together through payment methods, addresses, and device signals, which is why the second account tends to go the same way as the first.

An agent that reads yesterday’s spend and proposes a budget change does not appear anywhere in that list. What an agent can do is commit a violation on your behalf, at speed, which is a genuinely different worry and worth separating out.

The risk that is real

Strip out the rumour and one substantial concern remains, and it is not about permission. It is about what an autonomous process can do once it holds a credential that mutates live spend.

The failure modes are unglamorous. An agent misreads an instruction and raises a daily budget by an order of magnitude. An agent pauses the branded search campaign because the keywords looked redundant. An agent uploads a customer-match list carrying data that trips a policy check, and that suspends the account — not because AI touched it, but because of what got uploaded. And because these agents read untrusted text all day, a campaign name or a landing page can carry an instruction the agent will earnestly try to follow. We wrote that up separately in the threat model of AI agents touching ad accounts.

This is why the most useful advice circulating on the topic is also the least dramatic: keep raw API tokens out of autonomous agents. Not because a token in an agent breaks a rule, but because a token in an agent’s context is a token that can leak, and a token with no bounds on it is a token that can do anything the API allows.

What to check before you connect a client

Six questions, in rough order of how much they tell you.

  1. Does it call the official API, or drive a browser session? Ask directly and expect a direct answer. A vendor that cannot say which one it is has answered.
  2. Whose token or app is it? If a tool routes your account through the vendor’s Google Ads developer token so you do not have to apply for one, that is the arrangement Google’s policies name as prohibited.
  3. Does the model see the credential? There is a real difference between an agent that holds a refresh token in its context and a framework that reads the token in its own transport layer and never puts it in front of the model.
  4. What can it change without asking? Read-only access is a defensible starting position for a client account, and most of the value in the first month is reporting anyway.
  5. Is there an inverse for every mutation? Not a log of what happened, but the data needed to put it back, recorded before the change fires.
  6. What happens on a burst? Twenty pauses in a minute is a different event from one pause, and a system that treats them the same will let a bad run finish.

How we build against this

mureo takes the authorized route on every platform it supports, and the four mechanisms it puts around the agent map onto the questions above. Credentials are read by the framework’s transport layer and never enter the model’s context, with a runtime hook refusing file-system reads against the credential paths. Every mutating call carries its own inverse, written to an append-only log before the forward action fires, and mutations whose inverse is not on a curated allow-list are refused rather than warned about. Queries are validated against the published API surface before they execute. The rate and shape of the agent’s own actions are monitored, so a run that has started pausing everything is halted rather than completed.

The safety design and threat model posts go through each of these in more detail.

What we would not claim

That a compliant integration makes an account unsuspendable. Platform enforcement is automated, it does not always distinguish intent, and plenty of accounts get caught by it for reasons that have nothing to do with any tool. What a compliant integration does is keep your setup out of the category of things the terms actually prohibit, and keep the blast radius narrow when something goes wrong inside it.

That is a smaller claim than the rumour deserves, and it is the one that holds up.