Blog / Small Business Automation
'Google Hasn't Verified This App' on Your Own Script: What It Means and What to Do
By Keyona Meeks, Founder, ReRev Labs · Oct 31, 2026 · 9 min read
The short answer: The warning means Google has not reviewed the script's access request. Google's documentation says users outside your domain see an unverified app screen, and verification removes it. For a script you wrote and can read, continuing is usually reasonable, but only after you check what it asks to access. For a script you did not write or cannot read, stop. This post is based on Google's documentation as my tool returned it on October 31, 2026. I ran no script and I do not give the labels on the warning screen, because the documentation did not state them.
By the end of this post, you'll be able to:
- Say what the warning means, using Google's own words.
- Decide whether to continue or stop.
- Check what a script asks to access before you approve it.
- Know what changes when other people use your script.
We sell AI operations work, so weigh this post with that in mind. I am not a security professional. For scripts that touch business data, ask your IT administrator or a security professional.
What does "Google hasn't verified this app" mean?
I read two Google pages. Google's authorization page, as my tool returned it, says: "Users attempting to authorize such apps may see a warning screen saying the app is unverified by Google." It ties this to scripts that use sensitive or restricted scopes that Google has not verified. A scope is a kind of access, such as reading your spreadsheets.
Google's OAuth client verification page does not use the exact phrase "Google hasn't verified this app." It says "unverified app screen" and captions a figure "The unverified app warning screen." It says that if you do not verify, "users outside your domain see an unverified app screen when they try to authorize your script." It says verification "removes the unverified app screen and the user cap, building user confidence." My tool returned the verification page as a full article and the authorization page in parts, so check the quotes on the pages.
Why do you see the warning on your own script?
Because the script asks for access that Google treats as sensitive. The authorization page says: "Authorization scopes are determined automatically by scanning the script code." It adds: "Code that is commented out can still generate an authorization request." So a line you disabled can still add a request.
The verification page says: "Google OAuth clients that request certain sensitive OAuth scopes are subject to verification by Google." I could not confirm from either page whether the script owner always sees the screen for their own script. The verification page does not say.
When is it fine to continue?
These points are my judgment from general practice, not Google's advice:
- You wrote the script, or someone you trust wrote it and you can read it.
- You know what each line of access is for. A script that reads one sheet does not need your whole Drive.
- You are signed in to the account you meant to use.
- The access matches what the script does.
Google's page says verification is not required in one case: "Verification isn't required for Google Apps Script projects whose owner and users belong to the same Google Workspace domain or customer." It also says apps published within one Workspace organization "don't result in the unverified app authorization flow for accounts in that domain."
When should you stop?
Stop when any of these is true:
- You did not write the script and cannot read it.
- It arrived in a message you did not expect.
- It asks for far more than it needs. For example, access to all your email for a script that fills in a spreadsheet.
- You cannot say who owns it.
If you stop, close the screen and do not approve. Ask the sender how it works. For business data, ask your IT administrator.
How do you see what a script asks for?
Google's authorization page says: "If a script needs authorization, an authorization dialog appears when it is run." On screens that support it, the user sees "a granular consent screen where they can selectively grant or deny specific scopes." Read each line on that screen before you approve.
I could not confirm the labels of the buttons on the warning screen from Google's documentation, so I give none. Read each screen as it appears.
The page also says you can "explicitly set the scopes in the project manifest (appsscript.json)." It recommends this for published scripts "to ensure that you're using the minimum required permissions." It gives no editing steps in what I saw, and I could not confirm where the manifest file sits in the editor. Use Google's own help for that.
What changes when other people use your script?
The verification page says "users outside your domain see an unverified app screen." It also says "The total number of unverified app users is also capped," to limit possible abuse. It points to a separate page for the cap. I did not read that page, so I give no number.
If everyone who uses the script is in your own Google Workspace domain, the page says verification is not required. If your users are outside it, plan for the warning screen, and tell them before they see it. I did not read the steps for verification itself.
How do you check a script before you approve it?
- Read the script top to bottom. Note every service it calls.
- Read the access list on the consent screen.
- Match the two. Every access should have a reason in the code.
- Look for lines that send data out, for example to a web address you do not know.
- Approve only when you can explain each access.
- Write down who approved it and when.
Where does an LLM fit in this?
An LLM can help with the messy input. For example, it can read a script and list the services it seems to call, or explain a consent screen in plain words. A person checks the list against the code and the screen, because an LLM can miss a call and sound sure. Do not paste a script that holds passwords or keys into an LLM tool. The approval is a person's decision, and the access list is a plain fact from Google. My stance: AI writes the code, plain automation runs it, and an LLM shows up only where the input is messy and a person checks the result. For background, see what Google Apps Script is.
Where this has limits
- I am not a security professional. For business data, ask your IT administrator or a security professional.
- I ran no script and saw no warning screen. This post comes from Google's documentation.
- My tool returned the authorization page in parts. Check the quotes on the pages.
- I do not give the labels on the warning screen. The documentation did not state them.
- I could not confirm whether the owner always sees the screen for their own script, or where the manifest sits in the editor.
- I did not read the cap number or the verification steps.
- Google can change these pages. The date above is when I read them.
- No ReRev prices and no promises about results.
If you want help reviewing the scripts your team uses, see our AI operations service or tell us what the script does. Do not send passwords, keys or login details.
Frequently asked questions
Is it safe to continue past the unverified app warning?
It depends on the script. Continue only if you wrote it or can read it, and the access it asks for matches what it does. Otherwise stop.
Why does Google show this on my own script?
The script asks for access that Google treats as sensitive and has not reviewed. Scopes come from scanning the code, even commented-out code.
Do users in my own company see the warning?
Google's page says verification is not required when the owner and users belong to the same Google Workspace domain or customer.
Can I remove the warning?
Google's page says verification removes the unverified app screen and the user cap. I did not read the verification steps.
Is there a limit on users?
The page says the total number of unverified app users is capped. I did not read the number.
Does this post use an LLM?
An LLM can help read a script, and a person checks the result.
Read next: Apps Script limits every builder should know covers the other walls a personal script runs into.