What Permissions Does an AI Tool Need for Google Ads? OAuth, Roles and Revocation Explained

an AI tool does not receive blanket Google Ads authority just because you connect it. Effective access is the intersection of the OAuth grant, the connected Google identity’s Google Ads role, the manager-account path used to reach the advertiser, the accounts you choose to make available, and the actions exposed by the connector.

For reporting, Read-only access is usually enough. To create or change campaigns, the connected identity normally needs Standard or Admin access. Admin is not automatically required for campaign work – and granting it adds user-management permissions that most AI workflows do not need.

OAuth is the door. Your Google Ads role decides which rooms the identity can enter. The connector’s tool catalog decides which jobs the assistant can perform once inside.

A permission question such as “Can ChatGPT edit this campaign?” cannot be answered from the consent screen alone. Check all five layers.

Google Ads uses the Google Ads API OAuth scope to authorize an application. Google does not provide separate Google Ads OAuth scopes for read-only and read-write work. The same scope can support either; the connected user’s Google Ads role is what limits effective access.

This is why a consent screen can look broad even when the signed-in user has Read-only access. A valid OAuth token cannot promote that user to Standard or Admin.

The AI tool acts through the Google identity you authorize. If that identity cannot open an advertiser account in Google Ads, OAuth does not manufacture access. If the identity is Read-only, API calls inherit that restriction.

A user can receive access directly on an advertiser account or indirectly through a Manager account (MCC). Google resolves the effective role through the selected manager path. The same person can therefore have different effective access to the same advertiser through different manager hierarchies.

A connector may let you save only selected accounts after OAuth. That is an operational boundary: it controls which discovered accounts the connector will work with. It does not change the underlying Google Ads role or replace account-level access management.

OAuth and Standard access do not mean the assistant can perform every Google Ads action. The MCP server must expose the relevant report or mutation, and Google Ads must permit that operation for the resource, campaign type, policy state, and field.

Use the least-privileged role that completes the job. The practical choice is usually Read-only for analysis or Standard for supervised campaign work.

Billing and Email-only access are specialized roles, not useful substitutes for campaign reporting or management. Billing users focus on payment information. Email-only users receive notifications but cannot inspect and operate campaigns like a Read-only user.

Choose Read-only when the workflow only needs to inspect account structure, pull reports, research performance, review change history, or produce recommendations. A read-only identity cannot be turned into a write-capable operator by the prompt or the AI client.

Standard is normally the sensible choice when the workflow needs to create or update supported campaigns, ads, keywords, budgets, bidding settings, negatives, assets, conversions, or other account resources. It supports campaign work without granting user-administration control.

Admin access is appropriate when the human user must manage other users, security settings, or product links. Do not grant Admin merely because an AI tool needs to edit campaigns; Standard is normally sufficient for campaign changes.

Manager access is inherited down the hierarchy. If an agency user has Standard access on an MCC, that role can apply to linked advertiser accounts beneath it. If the same user has Read-only access through another manager path, the login customer selected for the API request helps Google resolve the effective role.

For practitioners, the useful questions are:

In HireOtto, one connected Google login includes directly accessible accounts and one level of child accounts beneath each visible MCC. A nested manager hierarchy may require another Google login with direct access to the inner MCC. Multiple connected Google logins are an Agency-plan feature.

During HireOtto’s Google Ads authorization flow, you select and save the accounts you want available. If OAuth completes but you do not save any accounts, the connector has no advertiser accounts to work with.

Account selection helps reduce accidental account mix-ups and keeps the working set relevant. It does not downgrade a Standard Google Ads role to Read-only, and it is not a substitute for removing a user from an advertiser or MCC.

After a client grants access to a new account, refresh the available-account list before assuming the account is missing or the token is broken.

“Disconnect” can mean three different things. Choose the control that matches the outcome you want.

Use your Google Account’s linked-apps page to find the application, review its access, and select Remove access. This revokes the app’s ability to use the Google Account grant. HireOtto will need a new authorization before Google Ads workflows can run through that connection again.

An Admin can remove the connected user from the advertiser or manager account, or change the role from Standard to Read-only. This is the right control when you want to preserve the app connection for other accounts but stop or reduce access to a particular Google Ads hierarchy.

Removing an MCP connector from ChatGPT, Claude, or another client stops that client from calling the connector. Do not treat it as equivalent to revoking the underlying Google OAuth grant. For the strongest cutoff, remove the app’s access in the Google Account and review the user’s Google Ads access separately.

Revocation stops future access through the removed permission. It does not automatically reverse campaign edits already applied, erase Google Ads change history, or delete data the application was legitimately allowed to process before access was removed. Review the provider’s data policy when that distinction matters.

A useful verification prompt:

HireOtto is a hosted MCP server that connects an AI client to Google Ads through OAuth. Google handles sign-in and consent; HireOtto does not receive your Google password. After authorization, you select and save the advertiser accounts the connector may route to.

Within those accounts, HireOtto can support reporting, account inspection, keyword research, audits, and documented user-directed changes. The connected Google Ads role remains authoritative: Read-only access is generally suitable for reporting, while supported writes normally need Standard or Admin. Google can still reject an operation because of account access, resource state, policy, or an unsupported field.

HireOtto does not make campaign changes on its own. For material writes, keep a human review gate: name the customer and entity IDs, inspect current and proposed values, approve the bounded action, then read the live setting back. Formal daily, weekly, and account-health audits are read-only.

For setup and access details, read Google Ads authentication and manager-account access, check the Google Ads MCP tools reference, and use the quickstart to connect HireOtto.

No. OAuth authorizes the connection, but Google Ads roles and manager hierarchy determine effective access. The connector can only use the actions it exposes, and Google Ads can reject unsupported or unauthorized operations.

Yes. Authorize a Google identity that has Read-only access in Google Ads. The OAuth scope is the same, but API calls inherit the user’s read-only role.

Usually not. Standard access normally supports campaign edits. Admin is primarily needed for user access, security, and certain account-level administrative tasks.

Yes, when the authorized Google identity has access through that manager hierarchy. Effective permissions are inherited, and the manager login context matters. Connector-specific discovery depth may still limit which nested accounts appear.

Remove the application from your Google Account’s linked-app access, then review or remove the connected user’s Google Ads access if that identity should no longer reach the advertiser or MCC. Removing only the connector from an AI client is not the same as revoking Google authorization.