Google sorts every OAuth scope into three levels, and the level decides your whole timeline. Non-sensitive scopes need basic verification. Sensitive scopes add a review Google's own table puts at ten business days. Restricted scopes, which include reading a Gmail inbox, add a third-party security assessment that you pay for, wait six weeks for, and repeat every year. If the app runs inside one Google Workspace organisation and the user type is set to Internal, Google says restricted scopes do not require further review at all.
Two decisions made in the first ten minutes set your whole timeline: which scope string you request, and whose Google Cloud organisation the project lives in.
Three tiers, and only one of them has a price
Google publishes the table, on the Workspace guide for configuring the consent screen, last updated 3 September 2026. Three columns: basic app verification, additional app verification, security assessment. Non-sensitive scopes tick the first. Sensitive scopes tick two. Restricted scopes tick all three.
The first two columns are cheap work: a homepage on a domain you own, a privacy policy on it, ownership proved in Search Console, a demo video. The third has an invoice attached. An outside lab carries it out, not Google, and it comes back every twelve months. I have built five hundred projects across thirty countries, and nobody reads that third column until the build is done and the client is asking when it goes live.
The scope string is the whole decision
Here is the part worth writing on a wall. On Google's Gmail scopes page, updated 10 September 2026, the scope that sends mail on the user's behalf sits under Sensitive scopes. The scope that manages drafts and sends mail sits under Restricted scopes. One needs an annual security assessment, the other does not, and the whole difference is whether your automation may leave a draft in the mailbox.
It gets sharper. The metadata scope reads headers and labels and, by Google's own description, cannot read the body. It is still restricted, so you do not escape the top tier by reading less. Drive is the same: Google steers you to the per-file scope because it is non-sensitive. And if you send over SMTP with the full mail scope, Google's FAQ is blunt, that violates the minimum scope policy, migrate to the sensitive send scope. At volume that is a cold email infrastructure decision as much as an OAuth one.
Grab the scope that obviously works, wire it up, ship it, deal with the consent screen later.
The draft-and-send scope is restricted. You have just added a six week review and a yearly outside audit to the project.
Open the scope table first. Pick the narrowest string that does the job, then design around it.
The send-only scope is sensitive. Same outcome for the client, no security assessment, and nothing to renew next year.
Internal apps skip verification, in Google's own words
From that same Workspace guide: for apps used only internally by your Google Workspace organisation, scopes are not listed on the consent screen and use of restricted or sensitive scopes does not require further review by Google. Read that with a project plan in your hand. No verification queue, no six week wait, no security assessment, no annual re-test, no hundred user cap.
The catch is structural. The Cloud project has to live inside that organisation, and Google's FAQ is plain: if you do not see the Internal option, your project might not be part of an organisation. So the client must be on Google Workspace or Cloud Identity, and only people inside it can authorise the app, which means one app cannot serve twelve clients this way.
It also means the client owns the project. That is a real trade, and in my experience the right one, because the alternative is you holding restricted access to a dozen companies' mailboxes in one project of your own. One caveat: Google notes high-risk Gmail and Drive scopes might still need configuration by the organisation's administrators. That is an email to an admin, not a six week review.
Google still points you at a free assessment that was retired
This is the part I did not expect to find. Google's OAuth App Verification FAQ still asks what to do if you are in scope for Tier 2 but do not want to scan your own application, and answers by referring to being in scope for the free tier 2 assessment. It uses Tier 2 and Tier 3 throughout.
The App Defense Alliance actually runs the programme, and its own Scan Your App page opens with a warning that the CASA self scanning process is deprecated. You may still use it to check readiness for the lab verified scan, and nothing more. That page's last updated stamp is November 2024, so this is not a change from last week. The vocabulary moved too: the Alliance and its authorized labs now price the work as AL1 and AL2, both lab verified, while Google's FAQ still speaks in tiers. So a developer budgeting from Google's own help page is planning around a free route that is no longer the route, using names their assessor will not recognise, and the assumption it plants is that this step might cost nothing.
What it costs when you cannot avoid it
Google does not charge you, and says so: it charges the developer no fees for the security assessment, and the cost is agreed between the developer and the assessor. So Google publishes no number at all. You cannot budget a mandatory step from the documentation of the company that made it mandatory.
Most authorized labs route you to a scoping form. One, TAC Security, publishes list prices on its own site: 675 dollars for a one time AL1 assessment, 855 for AL1 with unlimited revalidation, and 5,400 for AL2. That is one lab's published figure, not a market rate, and Google itself tells developers to approach several assessors.
Then it comes round again, in full. Google's wording leaves no room: the annual reassessment must be a complete test of your application whether you have made any changes or not. And if you plan to ship unverified while you wait, know the ceiling. Google says the user cap applies over the lifetime of the project and cannot be reset. One hundred new users, ever.
Four moves before you write any code
Ask one question on the scoping call
Is the client on Google Workspace? If yes, build in their organisation and set the user type to Internal. That single answer moves the delivery date more than anything else you will discuss that hour.
Write the scope list before the architecture
Open Google’s Gmail and Drive scope pages and check which heading your string sits under. Choosing the send-only scope over the draft-and-send one can take the security assessment off the project entirely.
Decide where the data lands
Google’s rule is that storing restricted scope data on servers, or transmitting it, triggers the assessment. Read, act, keep nothing is a different build from sync the mailbox into our warehouse, and a real automation should settle that on day one.
If you must verify, start on day one
Six weeks is Google’s own estimate and it says the estimate is not guaranteed. Starting it at handover is how a finished build sits dark for a month. This is the part an AI automation programme should schedule first, not last.
The bottom line
None of this is difficult. It is just decided much earlier than people expect. By the time you have a prototype reading a client's inbox, both expensive decisions have already been made quietly, by whoever created the Cloud project and whoever copied a scope string out of a tutorial. Ask the Workspace question in the first call, and read the scope table before you design the data flow. Skip both and you will be explaining to a client why an automation that already works cannot go live until October.