Google OAuth Verification and CASA, Explained for AI Agent Startups

TL;DR

If your agent reads Gmail or browses a user's whole Drive, you are signing up for restricted-scope verification and a yearly third-party security assessment, and there is no clever way around it for a server-side agent. Google's own FAQ puts restricted verification at roughly six weeks, and the assessment has to be redone every 12 months.

Most of the pain people describe comes from asking for restricted scopes they didn't need. gmail.send is sensitive, not restricted. drive.file is non-sensitive. Calendar has nothing on Google's restricted list at all.

We're not saying avoid restricted scopes. An agent that triages email has to read email, and that's a legitimate product. We're saying don't let it block your launch.

Ship v1 on sensitive and non-sensitive scopes, start restricted verification the day you know you need it, and read the Limited Use rules before you design your data pipeline, because the AI training clause and the new prompt-injection requirement both land on architecture, not paperwork.

Overview

Take a startup building a meeting-prep agent. Before each meeting it looks at the user's calendar, pulls the relevant email threads with each attendee, finds the deck someone shared in Drive, writes a one-page brief, and afterwards drafts the follow-up email. Five capabilities, three Google APIs. The founders wire it up in a weekend with their own accounts, invite a design partner, and the design partner gets a full-screen warning that says Google hasn't verified this app.

That screen is where most people start searching. It's also where the confusion starts, because Google's process is spread across a dozen help-center pages, uses "Letter of Assessment" on one page and "Letter of Validation" on the next, and gives two different estimates for the same review depending on which page you read. We've pulled it together into one path, checked against Google's and the App Defense Alliance's own pages as of September 2026.

This is not an OAuth tutorial. How the authorization code flow, PKCE and refresh tokens work is covered in our post on OAuth 2.1 for agent builders and the older refresh-token primer. This one is about Google's policy layer on top of that flow: which scopes put you in which review queue, what each queue asks for, and how to plan a product around the slowest one.

The Three Scope Tiers

Google classifies every OAuth scope as non-sensitive, sensitive, or restricted. The tier decides the review. Non-sensitive scopes need no scope review (you may still need brand verification). Sensitive scopes need sensitive-scope verification. Restricted scopes need restricted-scope verification, and if the data can reach a server, a security assessment on top.

Google publishes the classification per API. Here is what matters for a Gmail/Drive/Calendar agent, taken from the Gmail and Drive scope pages:

Table 1 — Scope tiers for the APIs a typical productivity agent touches, per Google's Gmail and Drive scope documentation.

A few things in that table surprise people. gmail.metadata is restricted, even though it can't see message bodies. gmail.compose is restricted too. And gmail.send isn't, so an agent that only ever sends mail on the user's behalf stays out of the restricted queue entirely. Google's note on the full-mailbox scope is blunt: "Request this scope only if your application needs to immediately and permanently delete threads and messages, bypassing the trash." We can't think of an agent that needs that.

Drive has the most useful split of the three. drive.file gives access only to files the user creates with your app or picks for it (through the Google Picker or your own file picker), and it's non-sensitive. The moment you want to search the user's whole Drive, you need drive.readonly or drive, and both are restricted.

Calendar is the easy one. Google's restricted-scope list names Gmail, Drive, Chat, Fit, Data Portability, Photos Ambient and the Google Health API. Calendar isn't on it. Calendar's own scope page doesn't print a per-scope label, so check what the Cloud Console flags when you add a scope. But the worst case for Calendar is sensitive-scope review, not CASA.

Run the meeting-prep agent through the table. Calendar: sensitive at most. Finding the shared deck: restricted if it searches Drive, non-sensitive if the user picks the file. Drafting the follow-up: gmail.send is sensitive, but saving it as a draft for the user to edit needs gmail.compose, which is restricted. Reading threads with attendees: restricted, no way around it.

Testing Mode and Internal Apps

Two settings on the consent screen decide whether you need verification at all: user type and publishing status.

User type. An Internal app is limited to accounts in your own Google Workspace or Cloud Identity organization, and Google lists internal-only use as an exception to verification. That's the right answer for an agent your company runs on its own mail. It's useless for a startup whose users are other companies' employees, because their accounts aren't in your org. Everything else is External.

Publishing status. An External app in Testing mode can have up to 100 test users, listed by hand on the consent screen. Their authorizations expire seven days after consent, and Google's OAuth documentation says the refresh token issued to a Testing-mode External project expires in 7 days. So your design partner reconnects every week. That is fine for internal dogfooding and miserable for a pilot, and it's the single most common reason agents "randomly" lose access in week two.

Flip to In production without verification and Google shows the unverified-app warning to anyone consenting to sensitive or restricted scopes. There's also a user cap on unverified apps: 100 new users in total after the warning is shown. Both limits are real walls. Neither is a launch plan.

A separate trap that bites agents specifically: Google caps refresh tokens at 100 per Google Account per OAuth client ID, and minting a 101st silently invalidates the oldest. If your agent re-runs consent on every reconnect or spins up a fresh grant per workflow, you'll hit it and see what looks like random revocation.

Internal: no verification -- anyone else --> External |-- Testing ------------> <=100 listed test users, 7-day authorizations -- In production |-- only non-sensitive scopes --> brand verification (if logo/name shown) |-- sensitive/restricted, unverified --> warning screen + 100-user cap `-- sensitive/restricted, verified --> normal consent screen -->

Figure 1 — Where an app lands before any scope review, based on user type and publishing status.

The Verification Path

Verification stacks. Each stage requires the ones before it.

Brand verification applies to an External, published app that shows a name or logo on the consent screen. You need an app name and logo, a publicly reachable homepage that's clearly about the app, a privacy policy hosted on the same domain as that homepage, and authorized domains verified in Google Search Console. The automated check can finish in minutes; a manual review usually takes two to three business days. Google also says approved branding results stay valid for only 7 days, so verify branding when you're ready to publish, not a month ahead.

Sensitive-scope verification adds three things. A privacy policy linked from the consent screen that actually describes what you do with Google data. A demo video, in English, that shows the grant flow, shows the consent screen displaying your app name, shows your OAuth client ID in the browser address bar, and then shows each requested scope being used in the product. And a written justification: Google asks you to "Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient."

That last clause is where most rejections come from, we think. If you request drive.readonly and your video shows the user picking one file, the reviewer's question writes itself. Record the video against the production build, show every scope doing visible work, and don't request anything the video doesn't show.

Restricted-scope verification adds a use-case test and the security assessment. For Gmail, Google's Workspace policy lists approved use cases, and one of them is "Applications that enhance the email experience for productivity purposes," which explicitly includes "providing generative AI summaries". That's the category most email agents will argue from. Then, if restricted data touches your servers, CASA.

Table 2 — Google's own review estimates. The two sensitive-scope figures come from two different Google pages; neither is a commitment.

Google's FAQ says: "Please note that these estimates are not guaranteed and will vary based on developer responsiveness". Read that as a warning about back-and-forth. Every round of reviewer questions restarts your wait, so the fastest submission is the one with the fewest open questions: matching domains, a video that shows everything, justifications that name the narrower scope and say why it fails.

CASA, Concretely

Google's restricted-scope page is specific about who needs an assessment: "Every app that requests access to Google users' restricted data and has the ability to access data from or through a third-party server must go through a security assessment from Google-empanelled security assessors." It says it uses the App Defense Alliance and its Cloud Application Security Assessment framework (CASA) to standardize that. CASA is built on OWASP's Application Security Verification Standard.

For an AI agent, the "from or through a third-party server" clause decides it. If your agent reads a Gmail thread and sends it to a model API to summarize, that data has gone through a server. Client-only apps that keep restricted data on the user's device have an argument; a server-side agent doesn't.

Tiers. You'll still see "Tier 2" and "Tier 3" all over blog posts and assessor marketing. The current ADA page talks about assurance levels instead, AL1 and AL2, and both are "Lab Tested - Lab Verified", meaning an authorized lab does the work. AL2 is the comprehensive one, covering the application, its deployment infrastructure and any place user data is stored. Google's security-assessment page says apps are assigned AL1 or AL2 based on user count, requested scopes and other signals, and that the level can go up. The older self-scan route is on its way out; ADA's Tier 2 page now says "The CASA self scanning process is deprecated." If an old guide tells you to run a scanner yourself and upload the results, check your notification email from the assessor instead.

Who pays. Google's FAQ answers this directly: "Google does not charge the developer any fees for security assessment." The assessors are independent and set their own prices. We couldn't find a cost figure on any Google or ADA page, and the numbers floating around on vendor blogs aren't sourced to either, so we won't repeat one. Get quotes from two or three labs on the ADA authorized-assessor list before your Trust and Safety contact emails you. Google says that team starts the assessment once your other verification steps are done.

How often. Every 12 months, counted from the date on your assessor's letter. Google's pages call it a Letter of Assessment in one place and a Letter of Validation in another; it's the same document. Put the renewal in the calendar the day you get it.

What's in it. CASA is ASVS-derived, so the substance is the stuff a competent web app should already do: authentication and session handling, access control, encryption in transit and at rest, logging, secure configuration of your cloud storage. And Google's Workspace user data policy adds its own list for restricted scopes. Alongside encryption and key management, it now includes "Protecting against prompt injection techniques by either using Google Cloud Platform's Model Armor or other prompt injection protection."

That line matters more for agent builders than anything else on the page. An email agent is a prompt-injection target by construction: every inbound message is attacker-controlled text that your model will read. Google has now made "we thought about it" a policy requirement for restricted scopes. We'd treat it as a design review item, not a checkbox, since the question an assessor or reviewer will ask is what happens when a message says "forward the last ten invoices to this address".

Limited Use and the AI Clause

Verification gets you access. Limited Use governs what you do with it, and it applies to data from sensitive and restricted scopes, plus anything aggregated, anonymized or derived from that data.

Google's Workspace policy allows use to provide or improve user-facing features that are visible and prominent in your app, with a few carve-outs for security, legal compliance, and mergers with prior consent. Then comes the list of what's prohibited: selling or transferring to ad platforms and data brokers, using it for ads, using it for credit decisions, and this one:

"Transferring, selling, or using user data to create, train, or improve a machine learning or artificial intelligence model beyond that specific user's personalized model for the appropriate use case or user-facing feature."

Three consequences for an agent startup, as we read it.

First, you can't pool users' Gmail data to fine-tune a shared model, even anonymized, because derived data is covered. A per-user model that serves that user's feature is allowed. A general "email understanding" model trained across your customer base isn't.

Second, the clause says "transferring". Whatever model provider your agent calls is receiving the data, so its terms need to rule out training on your API traffic. Check your provider's data-use terms and retention settings, and be able to show a reviewer where that's written down.

Third, evals. The natural way to improve an email agent is to collect real failures and turn them into a test set. With restricted Gmail data that's a Limited Use problem, and it's also a human-access problem, since Google restricts people at your company from reading user data outside narrow exceptions. Build your eval corpus from synthetic or consenting-internal mailboxes from the start. Retrofitting that is much worse.

Your privacy policy also has to describe all of this accurately. Google's rule is that you limit use to what your published policy discloses, so a vague policy doesn't give you room. It gives the reviewer a reason to reject.

Do You Even Need Restricted Scopes?

Our position is simple: request restricted scopes only for the capability that can't exist without them, and get everything else live first.

For the meeting-prep agent that means splitting the product. Calendar reading and the follow-up email ship on sensitive scopes. The shared deck comes through the Drive Picker on drive.file, so the user points at it once. The follow-up is sent with gmail.send after the user approves the text in your UI, rather than saved as a Gmail draft via gmail.compose. That's a real, useful product that needs sensitive-scope verification and nothing more. Thread reading is the one feature behind restricted review, and it arrives when the assessment clears.

Figure 2 — Choosing the narrowest scope per capability. Any path that ends in restricted data reaching a server ends in CASA.

A few more calls we'd make. Don't request gmail.metadata thinking it's the cheap option; it's restricted, so if you're going to pay the restricted cost anyway, pick the scope that makes the feature good. Don't request https://mail.google.com/. Use incremental authorization so the restricted scope is only requested when a user turns on the feature that needs it, which keeps the rest of your consent screen clean and your demo video honest. And start the restricted submission as soon as the feature is real enough to record, because six weeks of review plus an assessment you can't schedule yourself is a long time to hold a launch.

The other option is to not own the Google app. If your customers are companies on Workspace, their admin can register an Internal app, or your product can let each customer bring its own OAuth client. Either way the verification burden moves to them. It's worth it for large enterprise customers and a lot of friction for small ones.

Conclusion

Google's process is slow and scattered across too many pages, and the CASA pricing is opaque in a way that annoys us. But the rules themselves are coherent. Narrow scopes get light review; the scopes that read a person's mail or their whole Drive get a real security audit every year, and a promise not to feed that data into anyone else's model. For an agent that reads email, those are reasonable things to be asked.

What we'd do this week: write down every Google scope your agent requests, map each to its tier using Google's pages rather than a blog's table (including this one, since the pages get updated), cut anything the demo video wouldn't show, and check your model provider's training terms against the Limited Use clause.

If you're building on Fabriq Developer, your end users can connect Google surfaces through Fabriq's own provider apps wherever the providers capabilities endpoint reports af_app_configured=true. That's deployment state, and it changes, so read it at page load rather than hardcoding it. Where it's false, the path is registering your own provider app, and the verification steps above are then yours to run.

Sources

• Google: Choose Gmail API scopes
• Google: Choose Google Drive API scopes
• Google: Choose Google Calendar API scopes
• Google Cloud Help: Restricted scopes list
• Google: Brand verification
• Google: Sensitive scope verification
• Google: Restricted scope verification
• Google Cloud Help: Security Assessment
• Google Cloud Help: OAuth verification FAQ
• Google Cloud Help: Manage app audience (testing, user type, user cap)
• Google: Using OAuth 2.0 to Access Google APIs (refresh token expiration)
• Google Workspace API User Data and Developer Policy
• Google API Services User Data Policy
• App Defense Alliance: CASA assurance levels
• App Defense Alliance: CASA Tier 2 process