A programmatic proxy is a third-party hosted interface, secondary application programming interface (API), wrapper service, Model Context Protocol (MCP) server, or similar intermediate layer that replicates, wraps or re-exposes a platform's programmatic advertising capabilities without routing each end user through their own verified, direct connection to that platform. Google Ads gave the term this exact definition in its developer policies in August 2026, making the practice prohibited. The concept exists because automated advertising access has historically been mediated: a single developer's credentials could sit between hundreds of advertisers and a platform's API, and nobody downstream needed to prove who they were to the platform itself.

The pattern is old and platform-agnostic even though Google gave it a name in 2026. Any system exposing campaign management through a programmatic interface faces the same question: does the requester identify itself directly to the platform, or can it hide behind an intermediary's shared credentials? Google's policy answers that for its own ecosystem, but the architecture it targets, shared developer proxies routing requests from many independent businesses through one access point, recurs wherever an advertising API exists.

How a programmatic proxy is built and why it works

The mechanics are simple, which is part of the problem platforms have identified. A developer obtains legitimate access to an advertising API: an API key, an OAuth client, a developer token. Rather than requiring every end user of a tool to independently authenticate with the platform, the developer's application accepts requests from many downstream clients and forwards them upstream using its own single set of credentials. Every forwarded request then looks identical to the platform: the same Google Cloud project and developer token, regardless of which advertiser actually triggered the action.

Google's policy lists the specific patterns it prohibits. A developer cannot embed credentials in middleware that obscures the origin of an automated action, nor operate a shared developer proxy routing requests from multiple independent businesses to bypass the individual access each would otherwise need. It also bars a specific technical shape: a third-party hosted interface, secondary API, wrapper service, MCP server or proxy endpoint that solely replicates, wraps or re-exposes Google Ads capabilities as an intermediate layer.

The word solely matters. Google's policy does not restrict a developer's own automated use of the Google Ads API, nor open-source tools where end users connect the software to Google Ads with their own credentials. It targets the configuration where a third party's infrastructure sits between an advertiser and Google, handling authentication and mutations without Google ever independently verifying who that advertiser is.

Agencies, software vendors and developers offering a full-service or reporting tool used by more than one client sit on the affected side. Enforcement sits with the Google Ads API Compliance team, which can downgrade access, apply non-compliance fees or terminate programmatic access. A Google Cloud project unused for 90 consecutive days can separately have access revoked for inactivity.

Why Google introduced the rule in August 2026

Google published the update through its Ads Developer Blog on Monday, August 31, 2026, in a post titled "Making Google Ads More Secure with Updates to Developer Policies," attributed to Nadine Wang of the Advertising and Measurement APIs Team. The post frames the change as an update to the Google Ads Developer Policies, previously called the Google Ads API Policy, intended to support developers building integrations as artificial intelligence reshapes the advertising industry.

Google states that some integrations have historically relied on programmatic proxies that bypass the verifiable, secure connection it wants between end users and its own systems, and closing the gap is meant to protect partners against fraud and security risk. Two harms are named. Security vulnerabilities come first: unaudited proxies can give unauthorised actors account access and introduce cross-tenant data leaks, since many advertisers' traffic flows through one shared channel. Performance problems come second: high-volume traffic through a single proxy can throttle throughput and cause latency for every user of it, and mitigating a localised denial-of-service attack against one bad actor can require enforcement against everyone sharing that channel.

The timing is not incidental. The same policy names MCP servers, the protocol Anthropic introduced in November 2024 to let large language models discover and invoke external tools, as one intermediate-layer form a programmatic proxy can take. Google released its own official, read-only MCP server for the Google Ads API on October 7, 2025, which PPC Land documented at the time; it exposes three tools and cannot pause a campaign, change a budget or create an asset. Amazon followed with a closed beta of its own MCP server on November 13, 2025, and X later launched one exposing ten write tools among 23 total. Each official server is a direct connection sanctioned by the platform itself; a programmatic proxy is a party other than the platform standing between the advertiser and that connection.

Access levels and disclosure obligations

Google Ads Developer Services access is granted through a Google Cloud project, and the policy separates tools into three categories. A full-service tool must meet Required Minimum Functionality rules covering creation, management and reporting. A reporting-only tool need only meet the reporting subset. An internal-use tool, accessed by nobody outside a single advertiser or agency, is exempt entirely. The proxy prohibition cuts across all three, since the defining feature of a proxy is not what the tool does with data but whether the requester is verifiably the party whose account is affected.

The policy requires agencies and end advertisers to each use their own Cloud Platform account and Ads access, so access ties to an individual entity rather than pooling behind shared credentials. A developer offering programmatic access must separately disclose, prominently, that end users should obtain their own Cloud Platform account, an obligation predating the update that the proxy rule now reinforces with an outright ban where disclosure alone would not fix the architecture. The policy also references security practices drawn from the Model Context Protocol specification, alongside standards such as ISO/IEC 27001 and the OWASP Top 10. A compliant MCP implementation is not banned for being an MCP server; it is banned if it functions as an unaudited intermediary rather than a direct, verifiable channel.

Limitations, disputes and open questions

The August 2026 announcement is a policy statement, not a technical enforcement deadline. Outside commentary published in the following days noted that Google commits to reaching out directly to developers whose integrations need to transition, rather than setting a universal cutoff date, leaving a gap between the rule as published and as enforced against any specific tool.

A second open question is scope. The policy bars proxies that solely replicate, wrap or re-expose Google Ads capabilities, targeting tools whose entire function is intermediation. It is less clear how the rule treats a tool offering substantial original functionality built on a pass-through connection. Google's carve-out for open-source, self-credentialed tools suggests the test is about who authenticates to Google rather than how much value a wrapper adds, but the published text offers no worked examples at that boundary.

A third tension sits with AI agent tooling generally. MCP servers are, by construction, an intermediate layer between a language model and an external system. Google's own server escapes the prohibition only because it is first-party and requires each caller's own developer token rather than pooling third-party credentials. Any third-party MCP server built to simplify Google Ads access for many end users risks the same prohibition, an architectural constraint that barely existed as a policy question twelve months earlier.

Programmatic proxy versus adjacent terms

Invalid proxy traffic, a category the Media Rating Council places within Sophisticated Invalid Traffic, describes an intermediary device used to disguise the origin of non-human ad traffic, for example routing data centre bot traffic through residential-looking proxy IP addresses. That concerns delivery and measurement of ad impressions. A programmatic proxy concerns account access and campaign management, a different layer of the stack, even though both share the word proxy and involve obscuring true origin.

MCP server is a specific implementation of the Model Context Protocol and one of several forms a programmatic proxy can take, but the terms are not synonymous. A first-party, direct-connection MCP server, such as Google's own, requiring each caller's own developer token, is not a programmatic proxy. It becomes one only when it pools multiple independent businesses' access behind shared credentials without the platform's review.

Screen scraping, the subject of Google's separate litigation against firms scraping Google Search results, is a related but distinct prohibited practice under the same broader policy document. Scraping extracts data with no sanctioned API access at all, while a programmatic proxy involves legitimate access improperly shared or resold downstream to parties Google has not verified.

Third-party agency access, an agency managing a client's account through its own credentials with the client's authorisation, is not a programmatic proxy. An agency using its own Cloud project and Ads access, on behalf of a client who granted account-level permission, satisfies the direct-connection requirement. A proxy arises specifically when that verification step is bypassed.

Recent developments

The policy took effect as a governance update on August 31, 2026, with the Compliance team stated to be actively reviewing existing integrations. Google's next step is direct outreach to developers whose tools require changes, alongside an instruction to keep contact email current in the API Center, since compliance communications will come from the google.com domain. The update landed nine days after Google's August 25, 2026 release of Google Ads API Developer Assistant version 4.0.0, bringing Google Ads expertise into AI coding environments including Antigravity and Claude Code, a reminder that Google's push toward AI-assisted development proceeds alongside tighter rules on how integrations may be built. The policy also sits beside a separate pilot opened on August 3, 2026, letting manager account holders allowlist Cloud projects for sensitive API methods such as billing management.

Timeline

  • November 2024: Anthropic publishes the Model Context Protocol as an open standard for connecting large language models to external tools and data
  • July 7, 2025: Google Ads API team discloses it is exploring MCP server integration and requests developer feedback
  • October 7, 2025: Google releases its official, read-only open-source MCP server for the Google Ads API
  • November 13, 2025: Amazon Ads opens a closed beta of its own MCP server
  • April 2026: Meta opens its ads MCP server to external AI agents with write access
  • August 3, 2026: Google opens a pilot allowlisting Google Cloud projects for sensitive Google Ads API methods on manager accounts
  • August 24, 2026: X launches an ads MCP server exposing 23 tools, ten of them capable of writing to live campaigns
  • August 25, 2026: Google releases Google Ads API Developer Assistant version 4.0.0 with Antigravity and Claude Code support
  • August 31, 2026: Google publishes updated Google Ads Developer Policies defining and prohibiting the programmatic proxy

Summary

Who. Google Ads defines and prohibits the programmatic proxy; the rule binds developers, agencies and software vendors that build tools accessing the Google Ads application programming interface or MCP servers on behalf of multiple end advertisers. The Google Ads API Compliance team enforces the policy and reviews existing integrations.

What. A programmatic proxy is a third-party hosted interface, secondary API, wrapper service, MCP server, proxy endpoint or similar intermediate layer that replicates, wraps or re-exposes Google Ads programmatic capabilities without each end user connecting directly and verifiably to Google through their own Google Cloud project and credentials.

When. Google published the defining policy update on August 31, 2026, through its Ads Developer Blog, amending the Google Ads Developer Policies that had previously been known as the Google Ads API Policy.

Where. The policy governs access to Google Ads Developer Services globally, wherever a developer's Google Cloud project connects to the Google Ads application programming interface, and applies regardless of the country in which the developer, agency or end advertiser is based.

Why. Google states the change is meant to close security and performance gaps created by unaudited intermediaries: shared proxies can let unauthorised actors reach an account, can leak one tenant's data into another's traffic, and can turn a single point of failure into a bottleneck or denial-of-service risk for every advertiser routed through it. The rule arrives as MCP servers and other AI-agent access methods make automated, credential-pooling intermediaries easier to build than ever, which is also why the same announcement singles out MCP servers by name as one shape a programmatic proxy can take.