Google bans programmatic proxies from the Google Ads API and names MCP servers

Google has banned programmatic proxies from Google Ads API access, and the definition it published names Model Context Protocol (MCP) servers as one of them. The ban sits in the updated Google Ads Developer Policies published on 31 August 2026, and a Google Ads Help page titled "Programmatic proxy: Definition" sets out what the term covers.

What Google's programmatic proxy definition actually covers

Google Ads Help defines the term as "a third-party hosted interface, secondary Application Programming Interface (API), wrapper service, Model Context Protocol (MCP) server, proxy endpoint, or any similar service that solely replicates, wraps, or re-exposes Google Ads programmatic capabilities as an intermediate layer." That wording sits on the Google Ads Help definition page, and two parts of it decide whether a given tool is caught by the rule.

The first is "third-party hosted". A service that somebody else runs, and that you point at your Google Ads account, is inside the scope of the definition. The second is "solely". As written, the definition reaches services whose only function is to replicate, wrap or re-expose capabilities the Google Ads API already offers, as a layer in between.

Naming MCP servers inside that list is the part with no precedent. MCP is the interface standard that AI assistants use to reach external systems, so a rule about wrapper services now speaks directly to the way agents are being wired into ad accounts. This is the first time Google has folded MCP infrastructure explicitly into its programmatic access rules.

Google published the updated Developer Policies on 31 August 2026 and renamed the old API policy

The document carrying the ban is the Google Ads Developer Policies, published on 31 August 2026 as a rename of what was previously called the Google Ads API Policy. Google announced it on the Google Ads Developer Blog under the byline of Nadine Wang of the Advertising and Measurement APIs Team. The trade outlet PPC Land wrote up the policy sections on 5 September 2026.

The rename does more work than it looks like it does. A document called an API policy reads as a set of rules about calling one interface. A document called a developer policy reads as a set of rules about how you are allowed to build, which is the framing a proxy ban needs, because a proxy is an architectural choice rather than a particular API call.

What the policy text forbids

The policy states that 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." Four prohibitions sit in and around that sentence.

• Passing developer access to agencies, advertisers or other third parties so those parties can skip applying for their own Google Ads developer access and their own Google Cloud Platform project.
• Embedding credentials in middleware that obfuscates the origin of an automated action.
• Operating shared developer proxy services.
• Granting end users headless programmatic access to modify accounts "without direct, per-entity Google authentication".

The requirement that follows is stated plainly in the same document: every integration must now connect using its own dedicated Google Cloud project. One Cloud project fronting many separate businesses is the exact architecture the policy is written against.

What per-entity authentication asks of a build

Google's prohibition on headless programmatic access without "direct, per-entity Google authentication" is the clause that changes engineering work rather than paperwork. Reading the text: an automated action that writes to an account has to be traceable to a Google authentication belonging to the entity whose account it touches, not to a service identity that stands in for many entities at once.

That rules out the pattern where a platform holds one credential, users log into the platform with the platform's own login, and the platform then edits whichever Google Ads account the user selected. The account edit in that flow has no Google-side authentication attached to the party who asked for it. Google did not publish a reference implementation for what compliant per-entity authentication looks like, so the phrase is the whole specification for now.

Google left two carve-outs in the same section

The same section of the Google Ads Developer Policies states two exemptions. A developer's own automated use of the API against their own accounts is unaffected. Open-source tools that end users download and connect with their own credentials are also unaffected.

Put next to each other, the carve-outs describe the shape Google wants. The credential and the Cloud project belong to the party whose data is being touched. Local and self-run stays fine. Hosted for other people, on your credential, does not.

Google gave two reasons: cross-tenant leaks and shared throughput

Google stated two grounds for the ban. The first is security vulnerability exposure, including cross-tenant data leaks, which is the failure mode where one customer's data becomes reachable from another customer's session inside a shared layer. The second is operational risk: high-volume traffic routed through one proxy "can throttle throughput, cause latency across all users, and require enforcement across all users of a proxy" during denial of service mitigation.

The second reason is a blast radius argument, and it is worth reading twice if your tooling sits behind somebody else's proxy. Enforcement in that sentence lands on the proxy. Everyone behind the proxy takes it, whether or not they generated the traffic that triggered it.

The Required Minimum Functionality tiers, restated in the same document

The same document restates the Required Minimum Functionality (RMF) tiers that govern what a tool has to be able to do to hold each level of access. These are the three tiers as Google set them out.

The tiers are not new. Restating them beside a proxy ban still has an effect, because "internal use only" is both the tier that is exempt from RMF and the tier a shared proxy quietly stretches once it starts serving parties that are not internal to the developer holding the access.

Who is affected, and who is not

On the text of the policy, the parties with work to do are the ones operating a hosted layer that other businesses authenticate through: vendors whose customers never applied for their own developer access, platforms holding one credential on behalf of many advertisers, and anyone running an MCP server that several separate companies point their assistants at. Agencies that run Google Ads campaigns for a roster of clients through a single shared credential layer are in the same position, whether or not they think of themselves as developers.

The parties with nothing to change are in-house teams using their own developer access and their own Cloud project, developers automating their own accounts, and anyone running open-source tooling locally against credentials they own. Both of those last two are covered by the stated carve-outs rather than by inference.

What to check in your own setup

1. Whether every integration touching your Google Ads account has its own Google Cloud project, or is borrowing a vendor's.
2. Whether the MCP server your AI assistant connects through is hosted for multiple businesses, which the policy prohibits, or run locally with your own credentials, which the carve-out exempts.
3. Whether bid scripts, alerting jobs and dashboards authenticate per entity rather than through one shared service identity.
4. Whether anything in the chain writes to the account without a Google authentication belonging to the account holder.
5. Whether reporting pulls Google Ads data through a wrapper you do not control. If a hosted layer sits between the account and your dashboards, it is part of your analytics and measurement setup as much as your ad tooling, and read-only plumbing is where cross-tenant leakage would surface.

What the source did not say

Google published no enforcement date and no grace period beyond the 31 August 2026 publication itself. There is no statement about how existing non-compliant integrations will be notified, throttled or cut off, and no list of affected vendors. Nobody named in the policy is identified as being out of compliance.

The largest gap is the definition's own hinge. Google did not say where "solely replicates" stops and a genuinely value-adding tool begins. A hosted service that wraps the Google Ads API and adds its own logic, storage, scheduling or interface on top is not obviously covered by a rule aimed at services that do nothing but re-expose the API, and it is not obviously outside it either. Anyone running a wrapper today is reading that word without a test to apply, and the source does not supply one.

What this means for marketers in Thailand

Google named no countries in the policy and published nothing specific to Thailand, so what follows is reasoning about implications rather than reporting. The banned architecture is a familiar cost-saving pattern for small agencies here that manage a long list of client accounts through one shared credential layer, because a single developer token and a single Cloud project is cheaper to set up than one of each per client.

Three questions are worth putting to whoever built your stack. Does the integration hold its own Google Cloud project, or is it riding on a vendor's. Is the MCP server behind your AI assistant hosted for several businesses at once, or running on your machine with your credentials. Do your bid scripts and reporting jobs authenticate per account. None of those needs a developer to answer, and the answers determine whether the 31 August document creates work for you or none at all.

FAQ

Does this ban AI assistants from working with Google Ads?

No. The policy bans hosted third-party layers whose only job is to re-expose Google Ads programmatic capabilities, and it explicitly exempts open-source tools that end users download and connect with their own credentials. An assistant reaching your account through a local tool on your own developer access and your own Cloud project is on the exempt side of the line as Google wrote it.

Is this live in Thailand?

The source did not state any country list. The Google Ads Developer Policies govern developer access rather than a regional product launch, and neither the policy announcement of 31 August 2026 nor the Help page definition carries a geographic scope, so no country-level rollout was described either way.

Do I have to do anything if an agency runs my Google Ads for me?

Ask one question: does every integration touching your account connect through its own dedicated Google Cloud project. If the answer is yes, the policy asks nothing of you. If the answer is that a shared layer sits in front of several advertisers, that is the architecture the 31 August 2026 policy prohibits, and the work belongs to whoever built it.

What happens to integrations that are not compliant?

The source did not say. Google published no enforcement date, no grace period and no notification process beyond the publication of the policy on 31 August 2026, and it did not describe what happens to access that stays non-compliant.

Is a self-hosted MCP server allowed?

An open-source tool that end users download and connect with their own credentials is exempt under the policy's own carve-out. Where a server you host yourself but operate on behalf of several separate businesses lands is not addressed in the text, and Google did not publish a test for it.

The short version of the 31 August policy: the credential, the Cloud project and the account should belong to the same party. Working out which tools in your stack already meet that is a morning of checking, and it is better done before enforcement detail arrives than after. If you would rather walk through a Google Ads setup with someone, we are glad to take a look.