You requested a Gmail or Drive scope, recorded a clean demo video, and still got a rejection that just says your privacy policy does not comply. Nothing tells you which clause is missing. In practice, this is the single most common place Google OAuth verification stalls — not the scopes themselves, but the gap between what you told Google you do with the data and what your published policy actually says.
What the Limited Use requirement actually is
Google's API Services User Data Policy contains a section of additional requirements that attach to Sensitive and Restricted scopes. The core of it, called Limited Use, says Google user data may only be used to provide or improve features that are prominent in your own application's user interface — and that the rule follows the data, including anything you aggregate, anonymise, or derive from it.
Transfers are allowed in only four narrow situations: to provide or improve those prominent user-facing features with the user's consent, for security purposes such as investigating abuse, to comply with applicable law, and in a merger or asset sale after explicit prior user consent. Everything outside that list is prohibited — selling data to third parties such as ad platforms, data brokers or information resellers, using it to serve advertising of any kind including retargeting and interest-based ads, and using it for credit-worthiness or lending decisions.
Who it applies to
The additional requirements sit with Sensitive and Restricted scopes. Apps using only basic, non-sensitive scopes are not put through the same verification path. Google's own pages are not perfectly consistent on the sensitive-scope point, so the safe assumption is that it applies.
Human review
People may not read the data unless the user gave affirmative agreement for those specific messages or files, or it is necessary for security, or required by law, or the data is aggregated for internal operations. The Workspace version of the policy is stricter and asks for documented consent and anonymisation.
AI and model training
Google's Workspace policy and its verification FAQ state that Google user data may not be used to create, train or improve a model beyond a personalised model serving that specific user, and may not be used for foundational or frontier models. A privacy policy that mentions training AI models on user data gets flagged.
Internal-only apps
Applications used only by users inside the developer's own domain or organisation are treated differently and are not put through the same additional requirements. Getting this classification wrong at the start sends teams down a verification path they never needed.
Why the privacy policy is where reviews die
The reviewer does not take your word for your data practices. They open your published privacy policy in a browser and read it against the scopes you requested and the justification you wrote. A rejection follows whenever those three things disagree. That is the mismatch — and it is entirely independent of whether your scope request was reasonable.
Where the policy lives
It has to be published, listed in the OAuth client configuration, hosted on a domain you own and have verified through Search Console, and reachable publicly without a login. Google also expects the policy link on your homepage to be the identical URL you gave on the consent screen.
How it is formatted
It must be a dedicated page in readable HTML. Embedded PDFs, uploaded documents and iframes cannot be processed by the review team. A privacy policy URL that is the same as the homepage URL is an enumerated rejection finding, as is a policy that is obviously a downloaded template.
What it has to say
It must state what Google user data you access, how you use it, who you share or transfer it to, what protects it, and how long you keep it including how a user requests deletion. Umbrella wording that lumps Google data in with everything else gets read as applying to the sensitive data — usually not in your favour.
The Limited Use disclosure
An affirmative statement that your use of the data complies with the Limited Use requirements must be publicly disclosed. Google's guidance allows it in the privacy policy, an in-product disclosure, or a public FAQ. There is no single mandated sentence, but there is a mandated substance.
Consent, shown not claimed
Where your use case involves transfers or personalised model training, the demonstration video has to show a user actually consenting. Google's Workspace guidance is explicit that a disclosure buried in the privacy policy or terms of service does not count as consent on its own.
Findings Google publishes as reasons a policy fails
- The policy is not on a domain you own and have verified, or the URL does not respond.
- The policy is not clearly associated with the application or brand being reviewed.
- The privacy policy URL is identical to the homepage URL.
- It never states what Google user data is collected, or how it is used.
- It never states who the data is shared with, transferred to, or disclosed to.
- It specifies no protection mechanism for sensitive data, such as encryption or confidentiality procedures.
- It has no retention or deletion disclosure, and no way for a user to request deletion.
- It indicates the data is sold, or used for advertising, data brokerage, credit decisions, building databases, or training AI models.
The homepage fails reviews too
Almost every team focuses on the policy and forgets that the homepage is reviewed against its own checklist. It has to be on a verified domain you own, viewable without logging in, and it has to describe what the application actually does rather than being a bare login screen. Redirects to a different domain, shortened links, a Play Store listing or a social profile standing in for a homepage, and a missing link to the privacy policy are all documented findings.
Where teams get stuck
The pattern is almost always the same. A policy written by a general-purpose generator covers the company's website visitors but never mentions Google user data. Or the policy is accurate but describes a broader business model — analytics, enrichment, model improvement — that quietly contradicts the narrow use case submitted in the review form. Or the app requests a restricted scope that the product does not visibly need, and no amount of policy wording rescues it. Each of these produces the same unhelpful rejection note, so teams resubmit with cosmetic edits and cycle through the queue repeatedly without moving.
Untangling it means reading your scope request, your justification, your demo video and your live policy as one document and finding the sentence where they disagree — then rewriting the policy so it is both accurate to your real business and consistent with what you are asking Google to approve. That reconciliation is the work, and it is what we handle for clients.
For the wider process, how to pass the sensitive and restricted scope review covers the review end to end, brand verification covers the separate app name, logo and homepage check, and Google Workspace API verification covers why the Workspace path adds stricter requirements.
This article is policy-aligned guidance based on Google's published documentation as of 2026. Platform requirements change; no specific outcome or timeline can be guaranteed. We provide review preparation and submission assistance, and are not affiliated with or endorsed by Google.