Google Bans Programmatic Proxies in 2026: What It Means for Your Agency's Tools

What Changed in the Google Ads Developer Policies in 2026?

On 31 August 2026 Google announced updates to what it now calls the Google Ads Developer Policies, formerly the "Google Ads API Policy". The core change is that integrations "now need to connect directly to Google Ads services using their own dedicated Google Cloud project", and that programmatic proxies, which Google says "bypass the verifiable and secure interface between end-users and Google", are prohibited. Google also says its Ads API Compliance team is "actively reviewing existing integrations" and will contact developers who need to transition.

Nothing stops working on a single date here, which is exactly why this change is easy to miss. It is a policy that is already published and being enforced through reviews, not a version that switches off. If your agency uses a tool that touches Google Ads accounts on your behalf, or plans to connect Google Ads to an AI agent, this is the policy that decides whether that tool is allowed to exist in its current form. It sits alongside the hard deadline covered in our Google Ads API v22 sunset guide.

What Exactly Is a Programmatic Proxy in 2026?

Google defines it precisely, and the definition is broader than most people expect. In its help article, 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."

Two words in that sentence do most of the work. "Hosted" means the service runs on someone else's infrastructure rather than yours. "Solely" means its purpose is to pass Google Ads capabilities through, rather than being a tool with its own functionality that happens to use the API. A full reporting or management product with its own interface is a tool. A service whose job is to hand you or your AI agent a second API in front of Google Ads is the thing being prohibited.

The policy text repeats the definition in its Programmatic use section and states the consequence: "Any use of Google Ads by agencies or end-advertiser clients requires them to use their own Google Cloud Platform account and Google Ads access in order to ensure Google Ads API access is associated with the individual end-advertiser or agency."

Why Is Google Doing This in 2026?

Google gives two reasons in its 31 August announcement, both framed as protecting advertisers rather than restricting developers. Its stated context is that "new AI capabilities continue to shape the advertising industry", which is a fair reading of why a rule about intermediate layers arrives now: AI agents are the new and fast-growing reason people want a second API in front of Google Ads.

• Security: "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."
• Performance: "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)."

The second reason is the one with commercial teeth. If many advertisers share one proxy and one of them triggers enforcement, Google's own description is that enforcement can land on every user of that proxy. Your client's account access can depend on the behaviour of strangers sharing the same intermediary.

What Does the Policy Prohibit, Word for Word, in 2026?

The Programmatic use section is short and specific. These are the practices it names, quoted from the Google Ads Developer Policies page.

• Allowing 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 RMF."
• Embedding "credentials in middleware that obfuscate the origin of the automated action".
• Operating "shared developer proxy services that route automated requests from multiple independent businesses to bypass individual access".
• "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".

The policy also states that "end users of your tool will need to manually sign in to make changes to their accounts". For anyone designing an AI workflow that edits campaigns, that sentence is the constraint to design around: account changes need a human sign-in and per-entity authentication, not a shared credential the agent reuses.

What Is Still Allowed Under the 2026 Policy?

More than the headlines suggest. Google writes that the policy "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." The prohibition is on enabling other parties through your access, not on automation itself.

That last row matters for tool vendors. Google describes a review path for secondary programmatic interfaces with stated standards: full RMF adherence, "unbiased cross-channel measurement frameworks", and auditing that includes "immutable transaction logs that map every automated programmatic action directly to a verified end-advertiser account" and "industry-standard third-party security assessments (e.g., SOC 2 Type II)". A vendor that says its proxy is compliant should be able to tell you whether it has been through that review.

How Does This Affect Agencies Using AI Agents in 2026?

Directly, because the policy names MCP servers. The Model Context Protocol is how most AI agents in 2026 connect to external systems, and the fastest way to give an agent Google Ads access has been a hosted MCP connector. If that connector is operated by a third party and works by re-exposing Google Ads through its own access, it now matches Google's definition of a programmatic proxy.

The compliant pattern is the one the carve-out describes: run the connector yourself, on your own Google Cloud project, with your own developer access, and with each advertiser authenticating as themselves. That is more setup than pasting an API key into a hosted service, and it is the setup Google now requires. Our Google Ads account audit guide is a good place to fold an integrations review into routine account hygiene.

What Other Obligations in the Policy Do Agencies Miss in 2026?

The proxy rule is the news, but the same policy page carries obligations that apply to agencies every day, and several are easy to breach without realising.

• Delayed data disclosure: "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."
• Client data consent: 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."
• Unused access: "Google may revoke your access if it's not used consecutively for 90 days."
• Demo on request: "Upon request from Google, you must provide a demo account to your tool within 7 days of the request."
• Contact details: "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."

What Happens If an Integration Breaches the Policy in 2026?

Google describes a graduated process, which is why the contact email matters more than it sounds. Notices go "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." Google "may send you a warning before charging non-compliance fees in accordance with the rates detailed on the Google Ads API rate sheet." Further consequences can include "downgrading your access, imposing other quota limits on your Google Ads usage, or termination of your Google Ads programmatic access."

The 31 August announcement adds that compliance communications "will come from the google.com domain". If the contact on your Google Cloud project is a former employee's mailbox, the correction period can run out without anyone reading the notice.

What Should an Agency Do This Week in 2026?

1. List every system that touches Google Ads. Scripts, connectors, BI pipelines, bid tools, reporting dashboards, AI agents and MCP connectors.
2. For each, answer one question: whose Google Cloud project and whose developer access does it use? Yours, the vendor's, or a shared intermediary's?
3. Flag hosted MCP connectors and API wrappers that run on a vendor's access. Those are the closest match to Google's definition.
4. Ask vendors directly whether they have been through Google's Developer Secondary Interface Review, and get the answer in writing.
5. Update the contact email in API Center and on your Google Cloud project to a monitored alias, as Google recommends.
6. Check the 24-hour disclosure and client consent rules against how you currently report and share client data.
7. If unsure whether a tool qualifies, Google says to contact the Google Ads API Compliance team rather than guess.

What Are the Common Mistakes in 2026?

• Waiting for a deadline. There is no single switch-off date. Enforcement happens through reviews, starting now.
• Assuming "it is a popular tool" means "it is compliant". Popularity is not the test. Whose access it uses is.
• Treating all automation as banned. Your own programmatic use and self-run open-source tools are explicitly allowed.
• Plugging client accounts into a hosted MCP connector for an AI agent without checking how it authenticates.
• Letting an AI agent make account changes on a shared credential. The policy requires manual sign-in and per-entity authentication for changes.
• Leaving a stale contact email on the Google Cloud project. That is where the correction-period notice goes.
• Overlooking the 24-hour delayed-data disclosure in client dashboards that refresh daily.

Key Takeaways for 2026

• Google updated the Google Ads Developer Policies on 31 August 2026. Integrations must connect directly using their own dedicated Google Cloud project.
• Programmatic proxies are prohibited, and Google's definition explicitly includes hosted MCP servers that solely re-expose Google Ads capabilities.
• Your own automation and open-source tools run on your own credentials remain allowed.
• Account changes require manual sign-in and per-entity authentication, which shapes how AI agents can be connected.
• Enforcement is graduated: notice to your Google Cloud contact email, a possible correction window, then fees, downgrades or termination.
• The same policy requires disclosing reporting delays over 24 hours and written client consent before sharing account data.

Distk audits the integrations behind Google Ads accounts for agencies and in-house teams in India and internationally: which tools touch the account, whose access they use, and whether an AI agent setup meets the policy before Google's compliance team asks. If you are connecting Google Ads to AI tooling in 2026, that review is where we start.

Sources

• Google Ads Developer Blog, "Making Google Ads More Secure with Updates to Developer Policies", Nadine Wang, 31 August 2026 (read via the blog's official feed).
• Google Ads Developer Policies, Advertising Policies Help.
• Google Ads Help, definition of a programmatic proxy.