On August 31, 2026, Google updated its Google Ads Developer Policies to prohibit “programmatic proxies” and to require every integration to reach the Ads API through its own dedicated Google Cloud project. In plain terms: any shared tool that re-exposes your Google Ads account to third parties — an AI assistant, an MCP server, a wrapper dashboard — through one common connection is now non-compliant. PPC Land reported that Google is banning programmatic proxies from Ads API access, and the change lands squarely on the wave of “connect AI to your ad account” tools that many B2B SaaS teams were experimenting with in 2026.
This is not a niche developer footnote. If you run paid acquisition on Google Ads, the tools that read your account, sync your CRM, and increasingly the AI copilots that summarise performance all depend on how they authenticate — and Google just redrew the line on what is allowed. This guide covers exactly what changed, what a programmatic proxy is, which tools are exposed, and the concrete governance steps a B2B SaaS growth team should take before Google’s compliance review reaches its stack.
What actually changed on August 31, 2026
The updated Developer Policies add an explicit prohibition on programmatic proxies and a matching requirement: each integration must connect through its own verified Google Cloud project, not piggyback on someone else’s. Google’s policy language is direct — developers “can’t allow agencies, end-advertisers, or other third parties to access Google Ads access in a way that would allow those third parties to avoid applying for their own Google Ads developer access and Google Cloud Platform project.” The trust boundary moves from a loosely held developer token to a verified, per-integration project that Google can attribute and revoke.
The shift compounds a second change. On September 9, 2026, Google dropped developer tokens from Ads API access decisions, meaning the token you once treated as the credential is no longer the thing granting access. Together the two updates say the same thing from different angles: access now hangs on a verified Cloud project tied to a specific integration, and shared shortcuts that blur whose access is whose are being closed. Google’s Ads API Compliance team has said it is reviewing existing integrations and will contact developers who need to make changes, so this is an enforced policy with a rollout, not a suggestion.
What Google means by a “programmatic proxy”
Google’s definition of a programmatic proxy is deliberately broad: a third-party hosted interface, secondary API, wrapper service, Model Context Protocol server, or similar intermediate layer that re-exposes Google Ads capabilities without routing each end user through a direct, verified connection. The common thread is indirection — many advertisers reaching the API through one shared piece of infrastructure that stands between them and Google. It is the first time Google has folded MCP infrastructure, the interface standard AI assistants use to reach external systems, explicitly into its programmatic-access rules.
The distinction that matters is shared versus dedicated. A hosted tool that serves hundreds of businesses through a single connection is a proxy; a tool where each customer authenticates through their own Cloud project is not, even if it uses the same underlying software. Here is how the common categories fall out after the change:
| Access pattern | Example | Status after Aug 31 2026 |
|---|---|---|
| Shared hosted MCP / wrapper | One AI tool serving many advertisers via a single connection | Prohibited |
| Self-hosted, dedicated project | Your own MCP server on your own verified Cloud project | Permitted (carve-out) |
| Google’s official MCP server | Read-only tools released Apr 28 2026 | Permitted, read-only |
| Vendor tool, per-customer Cloud project | Dashboard that authenticates through your project | Permitted |
Google’s own MCP server sets the reference model
The policy is not a retreat from AI access — Google shipped its own path first. On April 28, 2026, Google released an official Google Ads MCP server that exposes the API to AI assistants through two core tools: list_accessible_customers and a GAQL-powered search. Crucially, it is strictly read-only. It can read every metric, budget, and status in your account, but it cannot pause a campaign, change a bid, or create an asset. That design is the reference model for what Google considers acceptable AI access: scoped, read-oriented, and connected through a verified project rather than a shared intermediary.
For B2B SaaS teams that were testing AI copilots on their ad accounts, this reframes the question from “can we use AI here” to “does this tool connect the way Google now requires.” A read-only assistant that surfaces what is happening in the account is exactly the sort of tool the official server enables, and it pairs naturally with the manual judgement we describe in using ChatGPT to manage Google Ads. The line Google is drawing is between reading your account through a verified connection, which is fine, and handing write access to your campaigns to a shared black box, which is not.
Which tools in your stack are exposed
The exposure sits with any integration that reaches your account through a shared vendor connection rather than your own project. The usual suspects in a B2B SaaS marketing stack are third-party reporting dashboards that aggregate many clients, no-code CRM-sync connectors, external bid-management platforms, and the newer crop of AI assistants and MCP tools. None of these are inherently non-compliant — the question is purely how they authenticate. A dashboard that spins up a dedicated Cloud project per customer is fine; the same dashboard routing every client through one wrapper is the pattern being closed.
Your own scripts are largely unaffected because they already run inside your account. The automation we cover in Google Ads scripts for B2B SaaS executes in Google’s environment rather than through an external proxy, and first-party data plumbing like the Data Manager API for audience management connects through your own credentials. The tools to scrutinise are the hosted, multi-tenant ones — the convenience layers where you never had to think about the Cloud project because the vendor handled it. That convenience is precisely what the policy now disallows, and the detail we outline in the Google Ads API v24 lead-gen update is a reminder that API-layer changes move fast enough to warrant a standing review.
The real lesson: treat account access like production
Strip away the API mechanics and this is an access-governance story. Google’s security rationale — unauthorized account access, cross-tenant data leaks, and throttling that spreads across everyone sharing a proxy — is the same threat model any B2B SaaS company applies to its own systems. The account that runs your paid pipeline holds your budgets, conversion data, and customer-list audiences; it deserves the same discipline as production infrastructure. Shared credentials and undocumented data paths are a liability there for the identical reasons they are in your codebase.
Practically, that means keeping an inventory of every tool with API access, knowing which Cloud project each authenticates through, and being able to revoke any one of them without breaking the others — which is exactly what per-integration projects make possible. It also raises the bar on whoever manages the account. A serious operator, internal or external, should be able to name every tool touching your account and its permission level; if nobody can, that opacity is the finding. This is where the tooling question meets the operating-model question we work through in in-house versus agency for B2B SaaS Google Ads, and where a clean access map separates a well-run account from a fragile one.
A short action plan
The work is bounded. First, inventory every integration with Ads API access — dashboards, connectors, external scripts, and any AI or MCP tool — and note how each one connects. Second, flag anything on a shared vendor proxy and raise it with the vendor now, since compliance review is already underway; ask directly whether they authenticate through your own dedicated Cloud project. Third, prefer read-only AI access modelled on Google’s official server for anything that only needs to observe the account, and reserve write access for tools and people you can fully account for.
If you cannot map your own access paths, that is the signal to get an independent read on the account before enforcement forces the issue. A structured Google Ads audit covers tooling and access governance alongside campaign structure and conversion tracking, so you learn not just how the account is performing but exactly who and what can touch it — and the free 10-point audit checklist is a fast way to start that review yourself. Either way, treat this policy change as the prompt to give your ad account the access hygiene you already give production, the same principle behind what a SaaS Google Ads audit is.