On June 24, 2026, Google shipped v24.2 of the Google Ads API, and one day later published a dedicated post on its headline feature: multi-party approvals in the Google Ads API. For teams that let software — increasingly, AI agents — make changes to ad accounts, this is the most consequential governance change the API has seen in a while. It formalizes a second-person-approves gate at the account-access layer, and it signals the direction every automated ad workflow is heading.

This post covers one thing: what multi-party approval (MPA) actually governs, the exact API surface it exposes, and how the two-party pattern maps onto agentic automation. For the complete overview, see Google Ads API Access & Brand Verification. For why approval gates matter specifically for an agent's write actions, see AI Ad Automation on the Google Ads API.

What multi-party approval actually gates

MPA is a response to a real problem: a wave of account-hijacking where an attacker who gains access quietly adds themselves (or removes the real owner) as a user. Google's fix is to require a second administrator to sign off before sensitive user-management actions take effect. Per the official MPA documentation, the API supports exactly three gated actions:

Inviting a new user to an account
Changing the access level of an existing user
Removing an existing user from the account

When one admin initiates any of these, a request fans out to all eligible administrators in the account hierarchy, who get an in-product notification to review it. A different admin — not the original requester — must approve or reject. If nobody acts within 20 days, the request expires and the change is discarded (Search Engine Land).

Two exemptions matter enormously for automation, and most coverage buries them: read-only roles and API users are exempt from the approval process (MPA docs). MPA is a control over who holds access to the account — not over what an authorized caller changes inside it. That distinction is the whole story for AI ad teams, and we'll come back to it.

The exact API surface

MPA isn't just a UI feature; v24.2 exposes it programmatically, so tools and agents can participate in the review flow instead of being locked out of it.

Resolve a request: call MultiPartyAuthReviewService.ResolveMultiPartyAuthReview with a ResolveMultiPartyAuthReviewOperation, setting status to APPROVED, REJECTED, or REVOKED. Approval must use the credentials of a user other than the original requester; revocation uses the original requester's credentials (MPA docs).
Find pending requests: query the multi_party_auth_review resource via GoogleAdsService.Search / SearchStream, filtering on WHERE multi_party_auth_review.review_status = 'PENDING'.
Availability: the feature is in beta and, notably, was backported to v23.3, v22.2, and v21.2 alongside v24.2 — so you don't have to be on the newest version to adopt it (ppc.land).

That's a small, clean surface. But read it in context: Google is standardizing the vocabulary of proposed change → pending review → second party resolves as a first-class API concept. That vocabulary is exactly what an agentic ad stack needs.

v24.2 in one screen: the governance-relevant parts

MPA is the security headline, but v24.2 pairs it with a second governance-flavored change that AI ad teams should not skip: AI-content transparency. The release adds SyntheticContentInfo and SyntheticContentAttestation fields to assets and ads, letting developers label AI-generated creative programmatically (Search Engine Land). Two of those fields — synthetic_content_info.advertiser_attestation.status and .source — are read-only in v24.2 and become fully mutable in v25. The timing is not an accident: it lines up with EU AI Act obligations landing in August 2026.

The rest of v24.2 — ad_network_type segmentation on performance_max_placement_view, YouTube brand-channel linking, a LANDING_PAGE_TEXT_GENERATION asset-automation type, and the new COMPARE_CAMPAIGNS experiment (ppc.land) — is real but off-thesis here. The two governance signals are clear: access changes now need a second party, and AI-generated creative now needs a machine-readable attestation. Both push accountability into the API itself.

How the two-party gate maps onto AI agents

Here's the part no one on the current SERP connects. If your agent authenticates as an API user, MPA does not gate the campaign, budget, bid, or creative changes it makes — API users are exempt, and the three gated actions are all user-management, not campaign management. So MPA does not, today, put a human in front of an agent's ad-account writes.

That's precisely why the pattern matters more than the feature. Google has ratified the two-party gate as the right control for high-consequence, hard-to-reverse actions. An agent mutating a live account — pausing a campaign, shifting budget, rewriting an ad — is exactly that kind of action. The responsible move is to wrap the same shape around agent writes yourself: agent proposes → human-in-the-loop reviews the diff → the change applies (or is rejected before it ever reaches the account).

Diagram showing Google's Multi-Party Approval flow — sensitive action, pending review, second admin resolves — mapped onto an agent write flow where an agent proposes a change, a human reviews the diff, and only then is the change applied and logged

The top lane is Google's MPA at the access layer. The bottom lane is the control you build at the change layer, borrowing MPA's structure: a proposed mutation sits in a reviewable pending state, a second party (here, a human operator) resolves it, and only an approved write lands — every decision logged. It's the same governance primitive, moved from "who can touch the account" to "what the automation is about to do."

An operating checklist for AI ad teams

Turn on MPA for user management now. It's the cheapest defense against the hijacking pattern it was built for, and it's exempt for your API automation, so it won't break your agents (MPA docs).
Keep agents on API-user credentials and reserve human-admin logins for actual people. This keeps the access surface auditable and lets MPA do its job without blocking automated reads/writes.
Don't rely on MPA to police agent behavior. It governs access, not account changes. Put your own approval gate in front of agent mutations.
Plan for AI-content attestation. With SyntheticContentInfo mutable in v25, any agent that generates creative will soon need to declare it. Wire attestation into the generation step, not as a cleanup pass.

How Soku fits

This gate is core to how Soku operates on ad accounts. Soku reasons over Google Ads and Meta data, proposes concrete changes, and surfaces the diff for approval before it writes anything back — the exact bottom-lane pattern above. MPA hardens who can reach the account; Soku's review loop hardens what gets changed once they're in. In a year where Google is baking two-party approval and AI-content attestation directly into the API, an ad stack whose automation already runs behind an approval gate isn't just safer — it's aligned with where the platform is going.

The takeaway: v24.2's multi-party approval is a small API surface with a large signal. Adopt MPA for access, understand that it does not cover your agents, and build the same second-party gate around every change your automation proposes.