The Google Ads Developer Policies tighten: shared proxies banned, a dedicated Cloud project required
Per the Google Ads Developer Blog announcement dated August 31, 2026, integrations must now connect directly to Google Ads services through their own dedicated Google Cloud project. Operating shared developer proxy services and embedding credentials in middleware are prohibited.
The policy changed its name and its scope
On August 31, 2026 the Google Ads Developer Blog published a post announcing updates to the developer policies.
The policy was renamed from the Google Ads API Policy to the Google Ads Developer Policies. Google describes the purpose of the update as supporting developers in building robust, high quality integrations as new AI capabilities continue to shape the advertising industry.
The proxy rule carries its own separate rationale: helping protect advertising partners against fraud and security risks. Google says programmatic proxies bypass the verifiable and secure interface between end users and Google.
The announcement gives no general effective date or compliance deadline. It states that the compliance team is already reviewing existing integrations.
What the rule says and which structures are prohibited
Under the new rule, integrations need to connect directly to Google Ads services using their own dedicated Google Cloud project.
The policy explicitly prohibits two things: embedding credentials in middleware that obfuscates the origin of the automated action, and operating shared developer proxy services.
The shared proxy prohibition is written conditionally. It targets shared developer proxy services that route the automated requests of multiple independent businesses in order to circumvent individual access requirements.
When listing prohibited structures the policy also names third party hosted interfaces, secondary APIs, wrapper services and MCP servers alongside proxy endpoints.
The risks Google lists fall into three groups. Using unaudited proxies can give unauthorized actors access to your account.
The second is the risk of cross tenant data leaks, exposing data more broadly than intended.
The third is performance bottlenecks. High volume traffic routed through a single proxy can throttle throughput, cause latency across all users, and require enforcement across all users of that proxy when mitigating a localized denial of service attack.
The policy further requires agencies and end advertiser clients to use their own Google Cloud Platform account and their own Google Ads access.
The cost of non compliance is defined: the policy text refers to non compliance fees and to access being downgraded.
Google's compliance team will reach out directly to developers who need to transition. Developers are asked to keep their contact email up to date in the API Center, and communications will come from the google.com domain.
The invisible link: who connects to your account?
The assessment in this section is ours. The security of an ad account is usually thought of as a password and two step verification. The real attack surface is the entire software chain connecting to that account.
A shared proxy architecture is exactly the invisible link in that chain. If the data of dozens of separate businesses passes through the same technical gate in a reporting panel, the owner of that gate is the weakest point between you and your ad account.
Google's performance rationale is notable for that reason. Enforcement for a problem on one proxy potentially applying to all users of that proxy means you can be affected by your neighbor's mistake.
It is also a signal that MCP servers appear by name among the prohibited structures. The layer where AI agents will connect to ad accounts is being brought under rules before it becomes widespread.
All of this points one way: thin out the intermediary layer and tie every access to a project with a known identity. That also clarifies the address of responsibility.
One caution is due: the announcement carries no scheduled deadline. This is not a transition with a date to wait for, it is a review process already under way.
What it means for businesses in Türkiye
The assessment below does not appear in the source, it is our reading. The text contains no Türkiye specific information.
A significant share of businesses in Türkiye follow Google Ads not directly but through an agency panel or a local reporting and automation tool. The architecture of those tools is rarely explained to the client.
So the question to ask is commercial rather than technical: which tool connects to my ad account, and through which Google Cloud project.
The second question follows: does the panel I use rely on my own Google Ads access, or on a structure shared by everyone. Because the policy requires agencies and advertisers to use their own access, this is no longer a preference.
For a business parting ways with its agency the conclusion is clear. If account access is tied to your own Google account, handover is simple; if it is tied to a shared intermediary, the data and the history stay there.
A practical step: ask your current tool and your agency whether they know about this change and how they will adapt their architecture. How clear the answer is also tells you something about the maturity of the party you work with.
The UNALSOFT take
On the advertising management side we require from the start that access on every account we work on is tied to the client's own Google account. The reason is not this policy but a simple principle: the client's data and account stay with the client, and the agency is only an authorized user. When the working relationship ends, the only thing to do is revoke the permission, not migrate data. This Google update makes the same principle mandatory at platform level. For businesses the real gain is transparency before security: the moment you can ask who connects to your account and with which project, you start seeing the technical chain behind your ad budget.
Who connects to your ad account?
Let us review your account access and the connection architecture of the tools you use.