Is a CASA security assessment required for an Apps Script add-on that uses restricted Gmail scopes but no script.external_request?

[bong mk]

Hi all,

I'm building an Apps Script project that uses restricted Gmail scopes and calls
Gemini. It runs entirely inside the user's own Google account and sends nothing
to my own servers.

From an earlier thread in this group, I understand that the script.external_request
scope is what triggers the CASA security assessment, and that projects without it
may be treated as "local clients":
https://groups.google.com/g/google-apps-script-community/c/LODyY26RhnA

So I removed every UrlFetchApp call and switched to the Vertex AI advanced
service for Gemini. A test project now requests these scopes:

  https://www.googleapis.com/auth/script.scriptapp
  https://mail.google.com/
  https://www.googleapis.com/auth/spreadsheets
  https://www.googleapis.com/auth/cloud-platform
  https://www.googleapis.com/auth/cloud-platform.read-only
  https://www.googleapis.com/auth/userinfo.email

script.external_request is gone, but cloud-platform has appeared because of
the Vertex AI advanced service.

My questions:

1. Without script.external_request, is a CASA assessment still required for
   restricted Gmail scopes? Has anyone gone through verification recently with
   a setup like this?

2. Does cloud-platform count as a scope that can transmit user data outside the
   user's account? In other words, would it bring back the CASA requirement?

3. Does it matter whose Google Cloud project the Vertex AI calls are billed to?
   I'd prefer each user to run Gemini in their own project, so their data stays
   under their own agreement with Google rather than mine.

I'm also planning to narrow https://mail.google.com/ by switching from GmailApp
to the Gmail advanced service with explicit scopes (gmail.modify / gmail.compose).
If anyone knows whether that makes a difference to the review, I'd appreciate it.

Thanks in advance.

[Ryan Vaz]

Hi,

Thanks for the detailed explanation. I have been looking into a very similar architecture, and I think there are a few important distinctions worth making.

My understanding is that removing script.external_request does not, by itself, remove the CASA requirement if the application continues to request restricted Gmail scopes. The CASA requirement is tied primarily to the restricted OAuth scopes and how restricted data is handled, rather than specifically to the use of UrlFetchApp.

The move from UrlFetchApp to the Vertex AI advanced service does, however, materially change the architecture. In that case the script is calling Google's Vertex AI API directly rather than making an arbitrary external HTTP request. I would therefore distinguish between the absence of script.external_request and the separate question of whether Gmail data is being transmitted to Vertex AI.

Regarding cloud-platform, I would also be cautious about treating it as simply a replacement for script.external_request. It is a broad Google Cloud OAuth scope, so it is worth minimizing permissions and understanding exactly what the Vertex AI advanced service requires. However, I don't believe that the mere presence of cloud-platform means that CASA automatically applies in the same way as it would because of script.external_request.

The question of which Google Cloud project is used is also important. If each user can use their own Google Cloud project and billing account for Vertex AI, the data-flow and contractual arrangement are considerably cleaner from a privacy perspective than having all users' Gemini requests go through a Cloud project controlled and billed by the application developer. That said, I would not assume that this arrangement by itself creates an exemption from Google's OAuth verification or CASA requirements.

I also agree with your plan to replace mail.google.com with the narrowest Gmail scope actually required. For example, gmail.send is substantially different from gmail.modify or gmail.compose from Google's scope-classification perspective. If the application only needs to generate and send email, it may be possible to use gmail.send, which is classified as sensitive rather than restricted. On the other hand, gmail.modify, gmail.compose, and the full mail.google.com scope remain restricted.

One thing I would also check is whether you actually need both:

cloud-platform

and

cloud-platform.read-only

If the Vertex AI service works with the broader scope, requesting both would not provide additional security and could make the permission set look broader than necessary.

For a published application, I would therefore aim for the smallest possible scope set and explicitly declare those scopes in the Apps Script manifest.

The most useful test would probably be to create three small proof-of-concept projects:

1. gmail.send + Vertex AI

2. gmail.compose + Vertex AI

3. gmail.modify + Vertex AI

with no UrlFetchApp at all, and then see how Google's current OAuth verification process treats each configuration.

In particular, the first case could be interesting if your application's functionality can be designed so that it does not need to read or modify existing Gmail content.

Overall, I think your move away from UrlFetchApp is sensible, but I would separate three questions when discussing this with Google:

• whether script.external_request is present;

• which Gmail scopes are requested and whether they are restricted; and

• where Gmail data is actually sent when Gemini is invoked.

Those three issues appear to be related but are not interchangeable.

Best regards,
Ryan

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-apps-script-community/63d3a7c5-93a4-4f8c-a1c0-ecddf63c47b8n%40googlegroups.com.

[bong mk]

Thanks, Ryan. Very helpful, especially separating the three questions.

One thing I'm trying to reconcile: older threads here (2019) report passing verification without the assessment just by removing script.external_request:
https://groups.google.com/g/google-apps-script-community/c/iE0wi64rSe0

And Google's docs tie the assessment to apps that can access data "from or through a third-party server":
https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification

Has this changed under CASA? Has anyone gone through verification recently with restricted Gmail scopes but no script.external_request?

Best regards,
Bong

2026年10月3日土曜日 10:54:20 UTC+9 Ryan Vaz:

[Ryan Vaz]

Hi Bong,

I think your distinction is important. The 2019 Google Apps Script Community thread does document a case where removing script.external_request reportedly resulted in approval without a security assessment, even though the app retained the https://mail.google.com/ scope.

However, I would be cautious about assuming that this outcome still applies under the current CASA framework.

Google's current documentation ties the security assessment requirement to apps that access restricted user data from or through a third-party server. That suggests the key question is the app's architecture and actual data flows, rather than simply whether a particular OAuth scope is present.

Removing script.external_request may support the argument that the application operates entirely on the client side, but it does not, by itself, establish that Google will accept the exemption.

I haven't been able to confirm a recent case involving restricted Gmail scopes, no script.external_request, and successful verification without a CASA assessment.

The safest approach would be to document the architecture and data flows clearly, then ask Google's OAuth verification team to confirm in writing whether the proposed implementation qualifies for an exemption before investing in the assessment process.

It would be particularly useful to hear from anyone who has completed this process recently.

Best regards

To view this discussion visit https://groups.google.com/d/msgid/google-apps-script-community/ed86f119-0f3a-4f53-b8eb-7f6f7e83688cn%40googlegroups.com.

[bong mk]

Thanks, Ryan. That matches my reading. I'll document the architecture and
data flows and ask the verification team to confirm before going further.
If anyone has gone through this recently, I'd still love to hear about it.

Best regards

2026年10月4日日曜日 15:55:27 UTC+9 Ryan Vaz: