Google published updated Google Ads Developer Policies on August 31, 2026, formally prohibiting programmatic proxies and requiring every integration to connect to Google Ads services through its own dedicated Google Cloud project.

In short

Google changed the rules for software that connects to Google Ads on August 31, 2026, banning shared middleman services, called programmatic proxies, that stand between advertisers and Google's systems. The change affects developers who build reporting dashboards, bid management tools, and increasingly, AI assistants that read or manage Google Ads accounts on behalf of clients. Any tool built this way must now register its own Google Cloud project and connect directly, or it risks losing access under the policy Google's compliance team is actively enforcing.

The policy update, announced in a post on the Google Ads Developer Blog under the byline of Nadine Wang of the Advertising and Measurement APIs Team, renames what was formerly called the Google Ads API Policy to the Google Ads Developer Policies. According to Google, the change is intended "to support developers in building robust, high-quality integrations as new AI capabilities continue to shape the advertising industry." The rebranding is not cosmetic. It reflects an expanded scope that now explicitly covers Model Context Protocol servers, the connective layer through which large language models query external tools, alongside the traditional Google Ads API and Google Ads scripts.

What counts as a programmatic proxy

Google's updated Help Center defines the newly restricted category in unusually broad terms. "A programmatic proxy is 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," the definition page states.

That single sentence captures a wide range of existing architectural patterns. Any developer who built a middle-tier service, whether to simplify authentication for end clients, centralize billing, or expose a stripped-down set of Google Ads functions through a custom API, now falls within the definition Google intends to enforce. The inclusion of Model Context Protocol servers by name marks the first time Google has folded MCP infrastructure explicitly into its programmatic access rules, tying the newest integration pattern in advertising technology to the oldest one: the plain HTTP wrapper.

The Google Ads Developer Policies document goes further than the definition page, spelling out the prohibited practice under a section titled Programmatic use. According to the policy text, 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, or avoid circumventing Google's Required Minimum Functionality." The document names concrete examples of what this rules out. Developers may not "embed credentials in middleware that obfuscate the origin of the automated action, or operate shared developer proxy services that route automated requests from multiple independent businesses to bypass individual access."

The policy also draws a hard line on end-user authentication. "Granting end-users headless programmatic access to make account modifications to Google Ads accounts without Google review of the developer's proposed use case, or without direct, per-entity Google authentication is prohibited," the text states, meaning end users of a compliant tool will need to manually sign in to make account changes rather than have a script authenticate on their behalf.

Google does carve out two exceptions in the same section. The restriction "doesn't restrict your own use of the Google Ads API in a programmatic or automated way, nor does it restrict open-source tools where the end-users download the software and connect it to Google Ads using their own access credentials." A developer automating their own agency's accounts through the API remains unaffected. So does an open-source script that a user runs locally, authenticating with credentials the user controls directly, rather than routing traffic through a hosted service the developer operates on the user's behalf.

The stated security rationale

The developer blog post frames the change as a periodic housekeeping exercise rather than a reaction to a single incident. "As technology evolves, we periodically review our policies to make sure they reflect the current landscape," the post states, before pointing to programmatic proxies as the specific pattern under scrutiny. "Historically, some integrations have relied on programmatic proxies, which bypass the verifiable and secure interface between end-users and Google," according to the announcement. "To help protect advertising partners against fraud and security risks, integrations now need to connect directly to Google Ads services using their own dedicated Google Cloud project."

Google's post lists two categories of risk the change is meant to address. The first is security vulnerability exposure. "Using unaudited proxies can provide unauthorized actors access to your account. They also introduce the risk of cross-tenant data leaks, which could expose your data more broadly than intended," the blog states. A cross-tenant leak, in this context, describes a scenario where a single shared proxy serving many independent advertisers or agencies has a flaw, or is compromised, that lets one customer's traffic or credentials become visible to, or confused with, another customer's data, since all of them are routed through the same intermediary rather than authenticating with Google directly.

The second risk category is operational rather than adversarial. "High-volume traffic routed through a single proxy can throttle throughput, cause latency across all users, and require enforcement across all users of a proxy when mitigating localized Denial of Service (DoS)," Google wrote. The practical implication is that a shared proxy concentrates risk: if Google's systems need to rate-limit or block traffic from that proxy because one client behind it is generating abusive or excessive requests, every other client sharing that same proxy connection suffers the consequences, even if their own usage was compliant.

Required Minimum Functionality and the developer categories it applies to

The updated Google Ads Developer Policies document restates and clarifies the Required Minimum Functionality framework, commonly abbreviated RMF, which governs what baseline features certain categories of tools must offer. According to the policy, RMF "refers to the features and other functionality that certain tool developers must offer when using Google Ads Developer Services," organized into three groupings: "Creation Functionality, Management Functionality, and Reporting Functionality."

Whether RMF applies to a given integration depends on how the tool is used. The policy separates developers into three categories. A "Full-Service tool" is one where "Advertisers, agencies, and other third parties use your tool to fully manage their Google Ads accounts," and RMF applies across all three functionality categories for that type. A "Reporting only" tool, where "Agencies or end-advertisers may only access a reporting dashboard using your tool," is subject to RMF solely for reporting functionality. An "Internal use only" tool, defined as one that "is only used by individual advertisers or agencies and isn't accessed by third-parties," is exempt from RMF entirely.

The policy also addresses developer access levels tied to this framework. "Each developer project with Google Ads access enabled is assigned an access level that determines whether you can affect production accounts and the number of operations and requests that you can execute daily. RMF applies only to projects with Standard Access," the document states. Non-compliance is not without consequence: "If you violate this policy, you may be subject to non-compliance fees and your access may be downgraded as described in the API rate sheet."

Disclosure, security, and third-party responsibilities

Beyond the proxy prohibition, the refreshed policy document sets out a lengthy list of disclosure obligations for agencies and software vendors that manage Google Ads accounts on behalf of end-advertisers. Developers whose reporting is delayed must tell clients: "If your reporting of Google Ads performance data is delayed to end-advertisers or other clients by more than 24 hours, you must prominently disclose this delay to your clients." Agencies must also secure permission before sharing account data: they "must obtain written consent from your clients before selling, redistributing, sub-licensing, or otherwise disclosing or transferring data specific to their Google Ads accounts including keywords, bids, campaign settings, or performance data."

Cross-platform tools face their own disclosure duties. If a tool imports or exports Google Ads data to another advertising platform and the platforms handle a data field differently, for example, "Google Ads allows targeting at the ZIP code level but the other ad platform only allows targeting at the city level," the policy requires the developer to "disclose this inconsistency before the data import is completed and offer your client the ability to cancel the import or modify the campaign data before proceeding."

On security specifically, the policy sets out required technical measures rather than mere recommendations. Developers must use "an industry accepted encryption standard to encrypt user data" whenever that data is "stored on portable devices or portable electronic media," "maintained outside of Google's or your systems," "transferred across any external network not solely managed by you," or "at rest on your systems." The policy further requires "transmitting data using secure modern protocols (for example, over HTTPS)" and "keeping user data and credentials, specifically tokens such as OAuth access and refresh tokens, encrypted at rest."

For applications touching what Google classifies as Sensitive and Restricted Scopes, the bar rises further. The policy requires "following the Cloud Application Security Assessment (CASA)" and notes Google "may also require that your application or service undergo a periodic security assessment and obtain a Letter of Assessment from a Google-designated third party," depending on the scope and number of user grants involved.

A separate section addresses what happens when things go wrong. Developers must "promptly notify Google at security@google.com of any known or suspected unauthorized access to the systems, networks, accounts, or other locations where Google Data is stored" and must "notify Google at security@google.com before you make any public statements regarding any known or suspected Security Incident."

Developer Secondary Interface Review: a path for legitimate wrappers

The policy does not close the door entirely on services that sit between an end user and Google Ads. It introduces a formal review process, described as "Developer Secondary Interface Review," through which Google "may review developer requests to provide secondary programmatic interfaces to assess whether a proposed use case operates in a safe manner and maintains continuous compliance with various technical and security standards."

Three criteria anchor that review. RMF Adherence requires that "the tool must maintain full compliance with Google Ads RMF guidelines, ensuring complete transparency, reporting integrity, and feature parity for the end-advertiser." Measurement Transparency requires that "the integration must employ unbiased cross-channel measurement frameworks to promote fair valuation and prevent anti-competitive self-preferencing." Auditing requires that "the platform must maintain immutable transaction logs that map every automated programmatic action directly to a verified end-advertiser account, and submit to industry-standard third-party security assessments (e.g., SOC 2 Type II)." Those logs and reports, the policy adds, "must be made available to Google Ads Compliance upon request to verify platform stability, rate-limit adherence, and data isolation." Google states that "any developer may request review of a proposed use," leaving a formal, auditable route open for businesses whose model genuinely requires an intermediary layer, provided they submit to the heightened scrutiny that comes with it.

Enforcement mechanics and timeline for existing developers

Google is not treating this as a rule that takes effect only for new applicants. According to the announcement, "the Ads API Compliance team is actively reviewing existing integrations." Google instructed developers to "check if your application requires updates by reviewing the policy," adding that the company "will also reach out directly to developers who will need to transition with detailed guidance, technical resources and additional details."

That outreach depends on developers keeping accurate contact records. The blog post asks developers to "ensure your contact email is up to date in the API Center so our Ads API Compliance team can easily share helpful communication or direct assistance from our compliance team as we do reviews," and specifies that "these communications will come from the google.com domain," a detail that gives developers a way to distinguish legitimate compliance outreach from phishing attempts impersonating Google. The updated policy document separately warns that failure to maintain accurate contact information carries its own consequences: "Failure to respond to requests or notices from the API team will constitute a violation of these policies and may result in downgrading your status or termination of your API access."

The broader enforcement document describes a graduated response to violations generally, not specific to the proxy ban alone. "If you violate these policies, Google will send a notice to the email address on file with your Google Cloud project, and you might have a period of time to correct these violations with no penalty," the policy states, while warning that "Google may send you a warning before charging non-compliance fees in accordance with the rates detailed on the Google Ads API rate sheet." Consequences beyond fees can include "downgrading your access, imposing other quota limits on your Google Ads usage, or termination of your Google Ads programmatic access."

Google also retains an audit mechanism independent of the proxy issue: "Google may monitor and audit any Google Ads Developer Services activity to ensure compliance with the Terms and Conditions and these policies," and separately, "Upon request from Google, you must provide a demo account to your tool within 7 days of the request," with a false or non-functional demo constituting its own violation.

Context: a year of tightening Google Ads API access

The proxy ban does not arrive in isolation. It extends a pattern PPC Land has tracked across the Google Ads API through 2025 and 2026, in which Google has repeatedly narrowed how third-party software connects to its advertising infrastructure while simultaneously expanding the API's reporting depth. Google forces Customer Match uploads to Data Manager API by April 1 documented an earlier instance of the same underlying logic: consolidating a data pathway onto infrastructure that enforces consent and provenance checks the older, more permissive route did not. Google blocks new offline conversion imports via Ads API from June 15 extended that consolidation to offline conversion data, cutting off new implementations of the older import path for any developer token that could not demonstrate active use in the preceding months.

Google's handling of data retention followed a comparable arc. Google Ads cuts granular data access to 37 months starting June 2026 reported that granular reporting data would fall out of reach after 37 months, a sharp contraction from the 11-year retention window Google had set less than 18 months earlier. Google shuts down session tracking for new advertisers in Ads API covered a related restriction on session attribute and IP address data within conversion imports, again pushing developers toward the newer Data Manager API rather than the original Ads API pathway.

The security and authentication dimension has its own recent history. Google's Data Manager API wants to kill your three-pipeline headache described how the Data Manager API enforces a single schema and consent framework across Google Ads, Google Marketing Platform, and Google Analytics, replacing three separate integration pathways that had each evolved their own field names and requirements. That article also noted the Data Manager API's rate limits, capped at 100,000 requests per day and 300 requests per minute per Cloud project, an architecture built around the same principle now written into the proxy ban: one Cloud project per integration, with usage tied to a verifiable identity rather than shared infrastructure.

Authentication requirements tightened again this year outside the API itself. Explaining passkey detailed Google's August 5, 2026 requirement that a passkey, rather than a password or SMS code, be used to generate new OAuth 2.0 refresh tokens for Google Ads API user authentication workflows, a change that PPC Land noted affects downstream products including Google Ads Editor, Ads scripts, and the BigQuery Data Transfer Service.

The Model Context Protocol thread runs in parallel. Google explores MCP server for Ads API integration reported on Google's early move to survey developer interest in an MCP-based connection method for the Ads API, a step PPC Land characterized at the time as a natural evolution of the API's existing programmatic capabilities. That exploration became a shipped product: Google Ads API assistant v4.0 forces existing users to reinstall traced the timeline from Google's open-source Model Context Protocol server, released October 7, 2025 with read-only access, through the Developer Assistant tool that Google itself later credited, alongside a new Explorer Access tier, as one of three causes behind a developer token application backlog serious enough that Google acknowledged it on February 6, 2026, an episode covered in Google faces developer token application backlog as new API tier debuts. Google later moved to clear that backlog with a brand verification pilot cutting review times to hours, reported in Google cuts Ads API review time to hours with brand check.

The pace of API releases has itself accelerated across the same window. Google moved the Google Ads API to a monthly release cadence starting in January 2026, up from three major releases per year previously, a shift documented across a run of version-specific PPC Land articles including Google Ads API v24: cart data sales view, lead gen conversions, retail filters, Google Ads API v24.1 adds mobile segments, passkeys, and new experiment types, Google Ads API v24.2: AI transparency and PMax segmentation finally arrive, and Google Ads API v25 kills two lifecycle goal resources, forcing code rewrites. That cadence means the developer population subject to the new proxy ban has also been absorbing a steady stream of unrelated breaking changes throughout the same period, compounding the migration burden facing any team maintaining a production integration.

Why the timing intersects with agentic AI adoption in advertising

The explicit inclusion of Model Context Protocol servers in the proxy definition lands at a moment when agentic AI tools built on that exact protocol are proliferating across the advertising sector. PPC Land's Explaining agentic AI coverage has tracked how MCP, introduced by Anthropic in November 2024, became the connective layer of choice for advertising platforms building natural-language interfaces to campaign data, with Amazon Ads, Meta, and Microsoft Advertising all shipping their own MCP servers over the past year. Meta opens ads MCP to any app, cutting integration code to zeroillustrates one platform's approach to the same underlying question Google is now answering differently: how much intermediary infrastructure sits between an AI agent and a live advertising account.

Google's answer, as written into the August 31 policy, is that an MCP server built by a third party to wrap Google Ads capabilities and serve multiple independent businesses through shared infrastructure falls squarely inside the banned category, regardless of how the tool markets itself. An MCP server that a single agency builds purely for its own internal account management, with no external businesses connecting through it, appears to sit outside the restriction under the internal-use exception the policy separately preserves. The distinction is not about the protocol itself; Google's own MCP server for the Ads API, released as open source in October 2025, remains Google's direct offering. The restriction targets third-party services that interpose themselves between end users and that direct connection.

This context matters for a wider security conversation already underway around MCP infrastructure generally. MCP forces ad tech to rebuild agent servers as sessions disappear reported on protocol-level changes affecting how ad tech companies build and secure their own agent servers, while Cloudflare Gateway blocks MCP calls that bypass approved portals documented enterprise security tooling built specifically to detect and control unauthorized MCP traffic inside corporate networks, a governance problem PPC Land has also traced through survey data in Augmentt: 47% of MSPs faced AI or Copilot data exposure. Google's move to name MCP servers explicitly inside an advertising-specific policy suggests the company sees the same governance gap other infrastructure providers have identified: a fast-growing, easy-to-build class of software sitting between users and sensitive account data, often without the verification or logging that direct platform access would require.

What the policy means for compliant developers and their clients

For an agency or software vendor whose Google Ads integration already connects each client through its own Google Cloud project and its own developer token, with end users authenticating directly to Google rather than through a shared credential the vendor controls, the August 31 policy update largely codifies existing best practice rather than forcing structural change. The RMF categories, the disclosure requirements, and the security measures spelled out in the refreshed document mirror obligations that have applied, in substance, across earlier versions of what was called the Google Ads API Policy.

The developers most exposed by the change are those who built a hosted, multi-tenant service, whether an API wrapper, a reporting dashboard, or an MCP server, that authenticates to Google Ads using the developer's own credentials on behalf of many separate end clients, rather than requiring each client to hold their own Google Cloud project and developer token. That architecture, common among smaller software vendors seeking to lower the setup burden for clients, is the exact pattern Google's policy text names as prohibited: a shared developer proxy service routing automated requests from multiple independent businesses to bypass individual access requirements.

Advertisers and agencies working with third-party Google Ads tools have a concrete question to raise with their vendors following this update: does the tool require the advertiser's own Google Cloud project and developer token, with the advertiser or agency staff signing in directly to authorize account changes, or does it operate through a credential the vendor controls on the advertiser's behalf. The policy's answer determines whether that vendor's access is likely to survive the compliance reviews Google says are already underway.

Timeline

Summary

Who: Google, through Nadine Wang of the Advertising and Measurement APIs Team, published the policy update on the Google Ads Developer Blog. It affects third-party software developers, agencies, and any vendor operating a hosted tool, including Model Context Protocol servers, that connects to Google Ads on behalf of multiple clients.

What: Google renamed its Google Ads API Policy to the Google Ads Developer Policies and formally banned programmatic proxies, defined as third-party hosted interfaces, secondary APIs, wrapper services, MCP servers, or similar intermediary layers that replicate or re-expose Google Ads programmatic capabilities. Integrations must now connect directly to Google Ads services using their own dedicated Google Cloud project.

When: Google published the policy update on Monday, August 31, 2026. The Ads API Compliance team is already reviewing existing integrations for compliance, according to the announcement.

Where: The change applies to the Google Ads API, Google Ads scripts, and any Model Context Protocol server or similar tool connecting to Google Ads Developer Services, regardless of where the developer or the end-advertiser is located.

Why: Google cites two risk categories driving the change: security vulnerabilities from unaudited proxies, including cross-tenant data leaks, and performance bottlenecks where high-volume traffic through a shared proxy can throttle throughput and force enforcement actions affecting every client behind that proxy, even compliant ones.