Home / Blog / How to wire Google Ads to Claude without handing over the keys
PPC Operations  ·  May 25, 2026  ·  7 min read

How to wire Google Ads to Claude without handing over the keys.

The biggest barrier to using AI in paid media is not technical. It is operational. Most teams plug the model directly into the account with permissions that are too broad, then spend the next quarter discovering what that costs them. This post is the opposite playbook — the exact wiring we use at actcenter, step by step, and why every choice is a deliberate constraint.

L
Leonardo RochaBuilding actcenter while operating 39 client accounts at RMC PPC

I wrote a separate piece about why we do not give Claude write access to a Google Ads account. This one is about how. If you are an operator looking at the AI-for-PPC space and trying to figure out a setup you can actually defend to a compliance officer or a client lawyer, this is the assembly diagram.

The whole thing is four steps and one boundary. The boundary is the part nobody talks about.

The default mistake

Open any AI-for-PPC demo from the last twelve months and you will see the same shape: a chat agent on one side, a Google Ads MCP or API connector on the other, and a fat permissions scope in the middle. The model can read, the model can write, the model can pause, the model can change budgets. The pitch is that the strategist becomes optional.

The shape works fine in a demo. It breaks the first time the model makes a confident, wrong call on a live account. I have watched this happen — an agent decides a high-CPA campaign is "underperforming" at 11pm on a Friday and pauses the brand campaign that drives 40% of the client's calls. By Monday the strategist is doing damage control instead of strategy.

The instinct after that incident is usually "we need better guardrails on the agent." The right instinct is "we gave the agent the wrong scope." Guardrails on a write-enabled model are still a write-enabled model.

The default scope problem

If the AI's token can pause a campaign, it can pause your campaign. No prompt, system message, or guardrail closes that hole — it only narrows the failure surface. The real fix is reducing the scope, not adding rules on top of it.

The actcenter setup, step by step

Our wiring is intentionally boring. Four steps, all using primitives that already exist in your Google ecosystem. No third-party MCP, no agent broker, no token sitting in a SaaS vault.

Step 1 — Install scripts inside Google Ads

We deploy a set of Google Ads scripts that pull the metrics that actually drive operational decisions: pacing, search terms, RSA performance, conversion drift, tCPA stability. The scripts live inside Google Ads, run under Google's own permissions, and execute on a schedule you control (hourly, daily, or whatever the account rhythm needs).

The script reads. It does not modify campaigns. It does not need an external API token, an OAuth handshake with a third party, or a service-account key that has to be rotated. From a security review perspective, this is the same trust surface as any reporting script your team already runs.

Step 2 — Export to Google Sheets

Each script writes its output to a structured Google Sheet. Not a raw API blob, not a JSON dump — a tabbed sheet that an analyst could read on its own. Typical tabs:

The Sheet is the boundary. Everything upstream of it is Google's infrastructure. Everything downstream is Claude. This shape is important because the Sheet is auditable, portable, and human-readable. An admin can open it at any moment and see exactly what is being shared.

Step 3 — Claude reads the Sheet

Claude is granted view access to the Sheet. That is the entire integration. There is no API key for Google Ads, no MCP wired into the account, no agent broker holding a token. The model sees a Sheet the same way a junior analyst with view-only access would.

When a strategist asks "how is BC's Auto Repair pacing this week?", Claude pulls from pacing, reasons over it, and answers. When the question is "which RSAs need a refresh?", Claude pulls from rsa_audit. When the question is broader — "what is the highest-risk account in my portfolio today?" — Claude reads across tabs and accounts in the same workspace.

Step 4 — Outputs flow to the strategist, not the platform

Everything Claude produces lands on the strategist's desk: diagnostics in the briefcase, talking points for client emails, live dashboards stacked by risk, draft RSAs ready for human review. None of it goes back into Google Ads automatically. The strategist reads, decides, and applies the changes in Google Ads themselves — using Google Ads Editor, the UI, or a checklist of approved actions.

STEP 1 STEP 2 STEP 3 STEP 4 Google Ads MCC or single account READ Scripts read-only scheduled Google Sheets pacing search_terms rsa_audit tcpa_drift VIEW Claude read only no API token Diagnostics · Dashboards · Drafts delivered to the strategist, not the platform PERMISSION BOUNDARY — NO WRITE ACCESS blocked by design
Figure 1 — The four-step path. Read-only scripts pull data, Sheets hold the structured copy, Claude reads the Sheet, outputs land on the strategist's desk. The red boundary is the architectural guarantee.

Where you place the script: MCC vs. individual account

The first practical decision in this setup is where the scripts live. There are two options and the right choice depends on whether you are an agency or an in-house team.

MCC (agency)

  • One script deployment covers every client account under the manager.
  • Central place to update logic, schedule, and Sheet destinations.
  • Single audit point for the security team.
  • Best when you operate 5+ accounts under one roof.

Individual account

  • Scoped per client — no cross-account visibility from one place.
  • Lower-friction install when you don't manage the MCC.
  • Right shape for in-house teams running their own brand.
  • Best for advertisers who don't sit under an agency.

Both shapes hit the same Sheet structure on the other end. Claude does not care which side of the line the script lives on — it only reads the result. That is what makes the wiring portable: an agency that loses an account does not lose the architecture, and an advertiser who moves agencies takes their scripts and Sheets with them.

Why Sheets in the middle

The Sheet is not a coincidence. It is a design choice. Three reasons it sits where it sits:

It is the audit trail. An admin or compliance officer can open the Sheet at any time and see exactly what data is leaving Google Ads. There are no hidden API calls, no encrypted blobs in a vendor's database, no logs to subpoena. The data lives in the workspace the company already owns.

It is the throttle. Sheets refresh on a schedule. That schedule is the rate limit between the account and the model. A misbehaving model cannot scrape your account in a loop, because the model is reading a Sheet that updates hourly — not pinging the API on demand.

It is the portability layer. If you ever want out of actcenter, your scripts and Sheets are still yours. The data architecture is yours. The model is the part you swap. This matters a lot more than people think — every operator I know has been burned at least once by a SaaS that owned their data and changed terms.

The Sheet as a contract

The structured Sheet is the contract between the account and the model. Everything upstream is your operational data. Everything downstream is interpretation. The contract is visible, versioned, and swappable — which is exactly what a contract should be.

What this rules out by design

The point of designing a system is not what it enables. It is what it prevents. Here are the failure modes that simply cannot happen in this architecture:

Each of these is a failure mode I have seen, heard about, or read in a post-mortem somewhere in the last eighteen months. None of them are theoretical. The wiring above does not "mitigate" them — it makes them structurally impossible.

What it does not rule out — and why that's fine

This setup does not stop the model from generating a bad analysis. It does not stop Claude from misreading a Sheet, recommending the wrong RSA refresh, or flagging the wrong account as high-risk. Those failure modes still exist.

The difference is who absorbs them. In the agentic setup, a bad analysis becomes a bad change in the account. In the actcenter setup, a bad analysis is caught by the strategist on review — the same way a bad analysis from a junior analyst is caught by a senior. The cost of the model being wrong drops from "client incident" to "ignored bullet point."

That is the entire bet. Make the AI good at seeing and proposing. Keep the human good at deciding and applying. Engineer the wiring so the boundary between the two is enforced by architecture, not by trust.

If you want to wire this yourself

The fastest path is to take your current set of one-off reporting scripts, point them at a dedicated Sheet workspace, and give Claude (or any read-only AI consumer) view access. You can stand up a basic version of this in an afternoon, without buying anything.

What actcenter adds on top is the structured tab definitions (so the AI has a stable shape to reason over), the dashboards that consume them, the briefcase that surfaces what matters first, and the prompts that turn a Sheet into operating intelligence. But the underlying wiring is reproducible by hand. That is on purpose.

The takeaway

You don't reduce AI risk by adding guardrails on top of a write-enabled token. You reduce it by never issuing the token in the first place. Four steps — script, Sheet, Claude, strategist — is enough to get AI's leverage on a Google Ads account without ever giving up the keys.

AI's leverage. Your governance.

Two strategists, 30 days, no credit card. We wire scripts to your MCC, route data through Sheets, and you read the briefcase the next morning. The AI never gets a token to your account.

Request a pilot → See pricing