Google bans programmatic proxies from Ads API access

Google has formally barred developers from using shared intermediary services to connect to Google Ads, tightening access rules for software vendors, agencies, and AI-related tools that manage or report on ad accounts.

The updated Google Ads Developer Policies were published on August 31, 2026. The change requires each integration to connect directly to Google Ads services through its own dedicated Google Cloud project and prohibits what Google now calls programmatic proxies.

In a post on the Google Ads Developer Blog, published under the byline of Nadine Wang of the Advertising and Measurement APIs Team, Google said the renamed policy framework is meant "to support developers in building robust, high-quality integrations as new AI capabilities continue to shape the advertising industry."

Broader policy scope

Google said the former Google Ads API Policy has been renamed the Google Ads Developer Policies. The updated scope explicitly covers the Google Ads API, Google Ads scripts, and Model Context Protocol servers.

The source article said this is the first time Google has explicitly included Model Context Protocol infrastructure in its programmatic access rules. That matters because the policy definition reaches beyond traditional API wrappers to newer AI connection layers.

Google's Help Center defines the restricted category this way: "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.

sbb-itb-6b5f97f

What developers can no longer do

Under a section titled Programmatic use, the policy says 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."

It also bars developers from using hidden or shared credentials. The policy says 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."

Google also set a specific authentication boundary for account changes. "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.

The policy includes two carve-outs. According to the source article, it "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."

Google's stated reasons

Google framed the move as part of a broader policy review. "As technology evolves, we periodically review our policies to make sure they reflect the current landscape", the post states.

The company said the issue is tied to a type of architecture it no longer wants developers using. "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 cited both security and operational concerns. "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.

The company also warned of technical and enforcement problems when many clients share one proxy. "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.

Minimum feature requirements still apply

The updated policy also restates Required Minimum Functionality, or RMF, which the source article said governs baseline features for some classes of tools. According to the policy, RMF "refers to the features and other functionality that certain tool developers must offer when using Google Ads Developer Services", and is organized into "Creation Functionality, Management Functionality, and Reporting Functionality."

The policy divides developers into three categories: Full-Service tool, Reporting only, and Internal use only. The source article said RMF applies across all three functionality categories for Full-Service tools, applies only to reporting for Reporting only tools, and does not apply to Internal use only tools.

Google also says access levels matter. "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.

For violations, Google warns: "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 and security rules

The refreshed policy also lays out disclosure duties for developers and agencies handling client accounts and data.

"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."

The policy also says agencies "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."

For cross-platform imports and exports, Google says developers must "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 data protection, developers must use "an industry accepted encryption standard to encrypt user data" in several situations described in the policy, including when data is stored on portable media, kept outside Google or developer systems, transferred across external networks, or stored at rest. The policy also 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 some applications, Google says developers must follow "the Cloud Application Security Assessment (CASA)" and notes it "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.

If a security issue occurs, 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."

A review path remains open

Google did not completely eliminate intermediary models. The updated policy introduces a process called Developer Secondary Interface Review, under 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."

The source article said the review centers on three criteria.

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)." The policy adds that those logs and reports "must be made available to Google Ads Compliance upon request to verify platform stability, rate-limit adherence, and data isolation."

Google says that "any developer may request review of a proposed use."

Existing integrations are already under review

The policy change is not limited to new developers. According to the announcement, "the Ads API Compliance team is actively reviewing existing integrations."

Google told developers to "check if your application requires updates by reviewing the policy", and said it "will also reach out directly to developers who will need to transition with detailed guidance, technical resources and additional details."

The company also asked 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 said "these communications will come from the google.com domain."

The policy separately warns: "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."

Google says enforcement may begin with notice. "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. It also warns 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."

The source article said additional consequences can include access downgrades, quota limits, or termination of Google Ads programmatic access. It also said Google retains audit powers. "Google may monitor and audit any Google Ads Developer Services activity to ensure compliance with the Terms and Conditions and these policies", and "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 treated as a violation.

Part of a wider tightening trend

The source article places the proxy ban in a broader pattern of Google Ads API restrictions and changes across 2025 and 2026, including new rules around Customer Match uploads, offline conversion imports, reporting data retention, session tracking, authentication, and developer token review.

It also said the explicit naming of Model Context Protocol servers comes as AI agent tools built on that protocol spread across advertising platforms. Under the new policy, the source article said a third-party MCP server that wraps Google Ads capabilities for multiple independent businesses falls within the banned category, while an MCP server built only for a single agency's own internal use appears to fall under the internal-use exception preserved elsewhere in the policy.

For developers already using direct connections, separate Google Cloud projects, and direct Google authentication, the source article said the August 31 changes mostly formalize existing practice. But for hosted multi-tenant tools that use a vendor-controlled credential on behalf of many clients, the article said the policy names that architecture as prohibited.

The result is a new compliance test for software connected to Google Ads: whether each client connects through its own approved setup, or through a shared layer Google now says cannot remain in the middle.

Read the source