Verify client identity before an AI assistant reads or changes an account

An AI assistant can produce a polished report for the wrong account if the task begins with an ambiguous client name. For an agency managing several businesses, similarity in names and shared manager access make this a practical operational risk. Read access deserves identity verification as well as account changes.

Start by binding the requested business to the actual provider account and permitted task. The useful result is a small evidence record that another operator can inspect. A familiar display name alone is insufficient evidence that the assistant has selected the intended account.

Ask for the business and task clearly

Record the business, provider, account and period requested. If the user asks to review one campaign, preserve that scope instead of expanding to every account available through a manager connection.

Use the organization's approved account map. It should connect the business identity with provider IDs and relevant assets. Do not create a mapping by copying an identifier from whichever browser tab happens to be open.

If the map is missing or uncertain, resolve the identity before collecting a broad report. An incomplete map is a concrete operational issue, not a reason to guess.

Distinguish accessible accounts from intended accounts

Google's List Accessible Accounts explains that the direct-access list is based on OAuth credentials and does not necessarily include every account in a hierarchy. Discovery needs that context.

Access means a credential can reach an account under the provider's model. It does not mean the account is the one the owner requested. A manager may legitimately access several clients, each needing separate task scope.

Use provider identifiers and the approved business mapping together. Record the discovery result and the selected account without exposing credentials or unnecessary client information.

Use a hypothetical mismatch example

Imagine an agency has two accounts with similar names: a local repair shop and a regional repair brand. In this fictional example, the approved mapping assigns different provider IDs to each.

The user requests the local shop's last thirty days of search terms. The assistant discovers both accounts but selects the regional brand based on its shorter display name. An identity check catches the mismatch before the report is produced.

The correct response is to resolve the account mapping, not to continue because the request is read-only. Reading the wrong account can disclose unrelated business information and produce recommendations the owner did not request.

The example contains no real client identifiers or results. Its purpose is to show why identity and authorization are separate questions.

Verify relevant linked assets independently

An advertising customer ID does not automatically identify the correct analytics property, tag container or website. Each service has its own identifiers and access rules.

When the task requires several providers, use approved evidence linking each asset to the business. A domain, configured stream or authorized account relationship can help, but the verification method should be appropriate to the asset.

Do not claim that every connection exists merely because one provider is connected. Missing or unverified assets should remain visible in the report.

Our Google Ads Naming Conventions That Actually Hold Up can reduce ambiguity, but naming consistency complements IDs rather than replacing them.

Treat OAuth as one authorization layer

Google's Use OAuth 2.0 to access Google Ads API explains API authorization. Application permissions, product access and the scope of the user's task still need their own checks.

Do not ask ChatGPT or Claude connector users to generate dashboard-minted client credentials as a generic connection fix. Follow the verified connection instructions for the client and the actual failing step.

Keep secrets out of reports and approval records. The operator needs evidence of the account and allowed action, not the token used to access it.

Make a change proposal bind to the same identity

A recommendation should identify the account and object it concerns. A later write proposal should preserve that identity and show the exact intended change.

If the selected account changes between analysis and execution, the old approval should not silently apply. Recheck the mapping and scope. Similar campaign names across clients are particularly poor identifiers for a mutation.

Our Approval Gates for AI PPC Agents explains the broader control pattern. Actual product enforcement must be verified for the deployed tool rather than assumed from a general recommendation.

Record a compact verification receipt

Use a mobile-readable checklist: requested business, provider, account ID, task, evidence checked, unresolved assets and operator. Store private account evidence in the approved work system.

For an account change, add the old and proposed values, authorization, provider outcome and read-back. The PPC Change Receipts: Prove What Automation Published describes that distinction.

A successful API response alone does not establish that the right account was used or that the intended state is now stored. Verification needs both identity and result.

Decide what to do when evidence is incomplete

Explain the missing mapping or connection precisely. Provide the actual resolving support route and reference code for a customer-facing failure. For AdvisorPPC, that route is /support and [email protected].

Begin with a bounded read-only task where the account identity is verified. The free AdvisorPPC lane is intended for Google Ads reads; other providers and writes require the appropriate paid product. Current access behavior should be confirmed before making a product-specific promise.

Explore current AdvisorPPC plans and bring the mapping checklist to your review. The useful starting point is confidence about whose account the work concerns and what the assistant is permitted to do.