Google Ads MCP Server Security: Designing Safe Read and Write Access for AI Agents

1. Define the security boundaries before connecting an agent

The Google Ads Model Context Protocol describes a way for an AI application to discover and invoke tools exposed by an MCP server. It does not grant access to a Google Ads account by itself. A Google Ads MCP server is an application that translates permitted tool requests into Google Ads API calls, then returns selected results to the agent. The MCP protocol, the server implementation, Google OAuth, Google Ads user permissions, and the agent’s own instructions are separate control surfaces. Security depends on all of them agreeing about what the agent may do.

Do not treat a prompt such as “never change budgets” as an authorization control. Models can misinterpret instructions, tool descriptions can be ambiguous, and account data can contain misleading text. Enforce permissions in the server and Google Ads account, regardless of what the model is asked to do. The MCP server should reject an unauthorized operation before it reaches the Google Ads API, and the Google Ads identity should lack permissions the application does not need.

Separate the layers of access

• Agent policy: Defines the task and the intended behavior, but should not be the only safeguard.
• MCP tool surface: Determines which operations the agent can discover and request, and which parameters it may supply.
• Server authorization: Checks the authenticated user, account scope, role, policy limits, and approval status on every request.
• Google Ads authorization: Determines which customer accounts and actions the OAuth user can access through the Google Ads API.
• Operational controls: Capture audit records, review unusual activity, limit exposure, and provide a tested way to disable access.

2. Design Google Ads identity and credential handling

Secure Google Ads API access starts with the identity behind each request. The Google Ads API uses OAuth 2.0 authorization and a developer token associated with the API application. OAuth identifies the user and the scope of the authorization; Google Ads account permissions determine what that user can do in the accounts they can reach. A developer token is not a substitute for user authorization, and an OAuth token is not a policy engine for individual MCP tools.

Prefer distinct identities for read and write workloads

For a read-only monitoring agent, authorize a dedicated Google Ads user with read-only access to only the required accounts or manager-account branch. For a workflow that can mutate settings, use a separate, explicitly managed identity with the minimum role needed for the approved operations. Google Ads API OAuth scopes are broad; do not expect the OAuth scope alone to restrict an agent to reporting or to a particular campaign. Account roles and the MCP server’s own policy checks must provide that separation.

A manager account can provide convenient access to many child accounts, but that convenience enlarges the blast radius. Avoid granting an agent access to an entire manager hierarchy if it only operates on one customer. At the server layer, maintain an explicit customer-account allowlist and verify the requested customer against the authenticated user’s approved scope on every call. Never trust an account ID supplied only by the model.

Protect OAuth material as production secrets

• Store client secrets and refresh tokens in a managed secret store with encryption, access logging, and narrowly scoped service permissions. Do not place them in system prompts, tool responses, source control, browser storage, or ordinary application logs.
• Use TLS for network transport. For remote MCP deployments, authenticate the connecting user and validate authorization on each session and operation; do not rely on a shared bearer token distributed to every agent.
• Restrict local process and filesystem access for a stdio-based server. For a remote HTTP-based server, secure the endpoint, validate allowed origins as appropriate to the transport, and protect session and token handling.
• Rotate credentials after staff changes, suspected exposure, or a security incident. Define who can reauthorize the application and how fast account access can be revoked.
• Do not assume a service account can replace a Google Ads user identity. Confirm the current Google Ads API authentication model and account requirements before choosing an unattended credential pattern.

3. Make the read plane useful without overexposing data

Start with read-only tools and give the agent the smallest useful set of account facts. A monitoring workflow commonly needs cost, impressions, clicks, conversions, conversion value, campaign and ad group status, budgets, bidding strategy, search impression share, and change history. It may also need conversion action settings and asset status to diagnose performance. It usually does not need unrestricted access to every customer, billing detail, user list, or historical record.

Return normalized summaries rather than dumping large, unfiltered datasets into model context. Limit date ranges, paginate safely, apply account and campaign filters server-side, and label currency, time zone, conversion basis, and reporting window. Keep a record of the query intent, customer, date range, fields returned, and data freshness outside the model transcript. If a model needs a narrow answer, retrieve that answer through a narrow tool instead of offering a general-purpose data-export tool.

Account for conversion lag and measurement quality

An agent that sees yesterday’s cost and only a fraction of yesterday’s conversions may incorrectly diagnose a CPA spike. Set reporting windows based on the account’s observed conversion delay: for example, use the period in which roughly 95% of conversions are typically reported, then compare that mature period with an equivalent prior period. The exact lag differs by conversion action, attribution settings, and business. Mark recent periods as provisional, and do not let provisional CPA or ROAS trigger a write without a specific human review.

Use explicit decision thresholds. For example, a team could require at least 30 mature conversions in the evaluation period before accepting a CPA-based scaling recommendation, and require a statistically meaningful comparison window before making a large budget change. That is a starting policy, not a universal Google Ads rule. If volume is lower, return a lower-confidence diagnosis and ask for review rather than converting noisy data into an automatic action.

For budget-constrained campaigns, interpret lost impression share due to budget separately from lost share due to rank. Compare the value of incremental conversions with the target CPA or target ROAS, and check whether the campaign has enough conversion volume to support a change. The Lost IS Calculator can help teams quantify impression-share opportunity, while the Google Ads Waste Calculator can help frame a waste review before proposing changes.

4. Restrict write access to narrow, testable operations

A write-capable MCP server should expose business actions, not a general-purpose command surface. Prefer a tool such as “propose a campaign budget adjustment” with a fixed set of validated fields over a tool that accepts arbitrary resource changes. The server should resolve the target resource from authorized account data, validate its current state, reject unknown fields, and prevent the model from changing account scope, URLs, conversion settings, or campaign status through an unintended parameter.

Classify every operation by impact. Reading a report is low impact. Changing a label or pausing a low-spend item can still affect delivery. Editing a campaign budget, bidding strategy, conversion action, location target, final URL, or Performance Max asset group can materially change cost, lead quality, or eligibility. Begin with recommendations only. Then allow a narrowly defined set of low-risk writes, and keep high-impact actions behind explicit approval.

Use performance and spend guardrails as policy, not suggestions

Guardrails should be calculated and enforced by the server. A useful pacing reference is expected month-to-date spend equals the approved monthly budget multiplied by elapsed calendar days and divided by the days in that month. Compare actual cost with expected spend, then account for weekday patterns, seasonality, campaign start dates, and Google Ads billing behavior. This equation is a monitoring baseline, not permission to change budgets automatically.

The following matrix illustrates starting controls for three account sizes. The spend figures are approximate daily equivalents using a 30.4-day month. The example change ceilings are internal policy choices, not Google Ads limits; set them to match cash-flow tolerance, account structure, and business risk. Require human approval for every budget increase during the initial rollout, even when it falls below the stated ceiling.

Tie proposed changes to the account’s actual target CPA or ROAS, not a generic “performance improved” statement. For a target-CPA campaign, define a mature performance window and specify how far above or below target a campaign must be before the agent may recommend a change. For target ROAS, evaluate conversion value on a consistent attribution basis and set a minimum data volume. Add a hard ceiling for total daily budget across all campaigns so an agent cannot make many individually compliant increases that exceed the account’s aggregate limit.

5. Put human approval between proposal and execution

The safest initial workflow is read, diagnose, propose, review, execute, and verify. The agent should state the evidence it used, identify the affected customer and resources, show the current and proposed values, explain expected impact, state uncertainty, and list the guardrails checked. A reviewer should be able to reject, edit, or approve the exact mutation—not approve a vague plan that could change between review and execution.

Make approval specific, time-bound, and auditable

• Bind approval to the exact customer, resource IDs, fields, old values, proposed values, and operation set.
• Expire an approval after a short policy-defined period or if the resource changes before execution. Re-read the resource immediately before applying the mutation.
• Require a named reviewer with the appropriate role. Separate the person who proposes a high-impact change from the person who approves it when staffing allows.
• Record who requested, reviewed, approved, and executed the action, along with the evidence snapshot, timestamp, API response, and final observed state.
• After execution, verify the resource in Google Ads and compare the result with the approved diff. If the result differs, stop additional writes and escalate.

For Performance Max, apply extra review to asset group edits, audience signals, listing groups, URL expansion, and final URL changes. Check destination quality, policy eligibility, asset coverage, and campaign-level overlap before changing configuration. A recommendation based only on campaign-level ROAS may miss product or query-level cannibalization; use the PMax Cannibalization Checker as one diagnostic input, then have an operator validate the account evidence.

A managed optimization workflow is an alternative to operating your own MCP server. PPC Tuner combines Gemini 3.8 Flash with human-in-the-loop mutate staging: proposed operations are staged for review and approval inside PPC Tuner’s secure web application workspace. This describes a managed workflow, not a native Google Ads MCP connection. Teams building their own Google Ads MCP server remain responsible for their own OAuth, authorization, audit, and deployment controls.

6. Threat-model the server and plan for failure

A secure Google Ads MCP server must account for more than stolen credentials. Threats include a compromised agent host, an exposed HTTP endpoint, a malicious or misconfigured MCP tool, prompt injection in retrieved content, cross-account data leakage, excessive tool permissions, and an operator approving an inaccurate recommendation. Treat descriptions and returned data as untrusted input. Campaign names, URLs, search terms, ad copy, and landing-page content can contain text that attempts to influence an agent. The model must not be able to reinterpret that content as authorization.

Operational controls to implement before production

• Use a tool allowlist and server-side schema validation. Reject unexpected parameters, unsupported resource types, out-of-scope customer IDs, and values outside approved ranges.
• Apply rate limits, request-size limits, pagination limits, and timeouts. Set concurrency caps so a loop or repeated agent call cannot create a large burst of API traffic or proposals.
• Separate application logs from model context. Redact credentials and unnecessary personal data; retain enough information to reconstruct the request and the decision without storing secrets.
• Monitor unusual access patterns, including new customer IDs, unexpected write attempts, repeated authorization failures, high mutation volume, and activity outside the expected operating window.
• Keep a change snapshot or equivalent recovery record for high-impact configuration. Define who can pause the MCP server, revoke OAuth access, disable write tools, and contact the account owner.
• Test failure handling for expired tokens, API errors, partial failures, stale data, approval expiration, and a resource changing between review and execution.

Maintain a kill switch that disables mutations without taking down read-only reporting. If a token is suspected to be exposed, revoke or rotate it, disable write-capable identities, inspect Google Ads change history and server audit logs, and confirm whether any approved operation was executed. Reauthorization should be deliberate and documented. A fast, tested revocation path is more valuable than an elaborate permission policy no one can operate during an incident.

7. Roll out access in stages and measure control effectiveness

A safe rollout progresses from visibility to recommendations to controlled execution. In the first phase, provide read-only access to one low-risk customer and compare agent summaries with established Google Ads reports. In the second phase, allow the agent to create proposals but not execute them; review false positives, missed context, and data freshness. In the third phase, enable a narrow set of approved mutations for a limited group of operators, with an approval gate and strict limits. Expand account coverage only after evidence shows that controls work under normal and failure conditions.

Review Google Ads AI agent permissions at least quarterly and whenever an operator, account structure, OAuth application, or MCP tool changes. Remove accounts that no longer need access, retire unused tools, and reassess whether write access is still justified. Track operational indicators such as the share of proposals approved, rejection reasons, stale-data blocks, authorization denials, change reversals, and differences between approved and observed state. A high approval rate is not proof of safety if reviewers are approving without examining evidence; pair it with sampled audits and outcome checks.

For scale, calculate the maximum financial exposure if every permitted action reaches its cap during a short interval. A $200,000 monthly account with many campaigns can exceed its risk limit even when each individual adjustment appears small. Enforce limits at campaign, customer, and portfolio levels, and consider a daily aggregate mutation budget. For a smaller $5,000 account, a single $50 change may represent a meaningful fraction of daily spend; use absolute caps as well as percentages.