Publish today · reviewed 1 September 2026
Google says it is updating its Google Ads Developer Policies, formerly called the Google Ads API Policy, to support more secure and higher-quality integrations as AI changes how advertising software is built. The 31 August 2026 announcement is a governance update, not a new bidding feature or an enforcement deadline.
The immediate job for an advertiser, agency or integration owner is to inspect how software connects to Google Ads. Google’s direction is clear: integrations should connect directly to Google Ads services using their own dedicated Google Cloud project. The announcement also explains why Google is concerned about unaudited programmatic proxies.
What Google is changing
Google says it is updating the developer policies and reviewing existing integrations for compliance. It says developers should review the updated policy, keep the contact email in Google Ads API Center current and use Google Ads Developer Support when they need help. Google says it will contact developers whose integrations need a transition.
That wording matters. It asks teams to review their architecture; it does not state a universal cut-off date in the announcement. Do not turn “transition” into a deadline that Google has not published.
Why programmatic proxies are a concern
Google describes a programmatic proxy as an intermediary that sends API requests for other integrations rather than each integration connecting through its own verifiable interface. The company lists two risks:
- Security: an unaudited proxy may create unauthorised account access or cross-tenant data exposure.
- Performance: high-volume traffic through one proxy can create throughput and latency bottlenecks; broad enforcement during a denial-of-service event can affect every user of the proxy.
This is a system-design explanation, not a claim that every intermediary is malicious. The safe question is whether your team can identify the project, identity, data path, permissions and audit trail for every request. DMT’s agent-harness guide applies the same principle to AI tools: the action boundary must be visible.
What “connect directly” means operationally
For an integration owner, direct connection should mean that the application’s requests can be tied to the organisation’s own Google Cloud project and approved Google Ads API credentials. Start with an inventory:
- List every application, agency tool, connector and internal script that reads or changes Google Ads data.
- Record the Google Cloud project, developer token, OAuth client, service account or user flow associated with each path.
- Mark which components are yours and which are vendor-managed.
- Document the scopes, customer accounts, data fields and mutation permissions each component receives.
- Identify any proxy, middleware or shared endpoint that handles requests for multiple tenants.
Do not assume that “we use a reputable platform” answers these questions. Ask the vendor how your account is isolated, which project owns the request, what logging exists and what happens when the vendor’s endpoint is unavailable.
A security review for agencies and martech teams
Use Google’s announcement as a trigger for a focused review, not a reason to rebuild every integration immediately.
| Review area | Question | Evidence to retain |
|---|---|---|
| Identity | Can each request be tied to an approved project and user/application? | Project ID, OAuth flow and owner |
| Permissions | Does the tool have only the accounts and actions it needs? | Scope and account-access record |
| Tenant separation | Could one customer’s data be returned to another? | Isolation design and test result |
| Traffic | Where are retries, rate limits and failure handling enforced? | Request logs and runbook |
| Contact | Can Google reach the responsible developer? | Current API Center contact |
Pair the review with DMT’s Google Ads AI guide when an AI layer reads campaign data. AI does not remove the need to identify the underlying API path. For API-version work, keep this governance review separate from DMT’s v25.1 migration guide; the announcement is about policy and security, not a new API version.
What the announcement does not say
- It does not provide a universal enforcement date.
- It does not say that every proxy is already prohibited.
- It does not certify any vendor’s current compliance.
- It does not replace the published policy or developer support.
- It does not authorise an agency to access an account without the customer’s approval.
For the exact rules, read Google’s Google Ads API/programmatic-proxy policy reference. If the architecture is unclear, contact Google Ads Developer Support and keep the response with your integration record.
A low-risk transition plan
First, freeze the inventory rather than changing production credentials during a campaign. Second, test a direct path in a non-production or tightly scoped account. Third, compare response identity, data isolation, error handling and audit logs. Fourth, plan a vendor transition only when the ownership and support path are clear. Fifth, re-check the policy after Google provides any additional transition detail.
The DMT technical review pattern is useful here: inspect, document, change one boundary at a time and verify the result. A policy review should create evidence that a human can understand, not just a checkbox.
Keep this governance work separate from feature migration decisions such as Google AI Max planning and testing; a campaign feature choice does not, by itself, establish that an API integration meets developer-policy requirements.
Bottom line
Google’s 31 August update makes integration ownership and auditability more important. A dedicated Google Cloud project, a direct connection, least-privilege access and a current contact path are sensible controls for any Google Ads API integration. Treat the announcement as a prompt to review your architecture, while keeping the exact enforcement timing and any account-specific transition guidance tied to Google’s future communications.
Source credit: This article is based on Google Ads Developer Blog’s 31 August 2026 policy update and the linked Google Ads programmatic-proxy guidance. No compliance determination is made for any specific integration.
