Every AI assistant that reads Google Workspace data inherits the permissions of the person asking, which sounds reassuring and is the opposite. Most Drive estates at small firms carry years of accumulated over-sharing: documents set to anyone with the link, shared drives with too many members, folders inherited from a project that ended in 2023. A person had to know a file existed to find it. An assistant asked to summarise what the company knows about a topic surfaces it in seconds. That change in retrieval is why the sharing audit comes before the tool decision, not after it.
Overview: five things that govern AI in Google Workspace
- Permission inheritance is the security model. An assistant returns what the user could already open, so the risk sits in the sharing state of the estate rather than in the tool.
- OAuth scope is the real install decision. A marketplace add-on requesting read and change access to all files has a very different blast radius from one scoped to the file currently open.
- Admin allowlisting is off by default in practice. Unless someone restricts marketplace installs, users install what they like, and each install is a standing grant against tenant data.
- Native and add-on capability overlap heavily. Most of what small teams want is already in the suite, so the honest question is what the add-on does that Gemini and Smart Fill do not.
- Retention and residency differ by tier. Enterprise agreements carry data handling commitments that consumer and trial tiers do not, and the same brand name appears on both.
This is written for IT leads and operations directors at firms between 25 and 500 people on Google Workspace who have been asked to approve an AI tool somebody already installed. If your estate question is Microsoft against Google rather than which add-on, our platform comparison is the better starting point.
Why an AI rollout exposes Google Workspace sharing debt
A Drive sharing permissions audit is the prerequisite step for any assistant that indexes company content, because retrieval difficulty has been doing security work nobody counted. Files were technically accessible and practically invisible, and an assistant removes the practical half of that protection without changing a single permission.
Link sharing set to the whole domain
Anyone in the organisation with the link is the default many people pick to stop a colleague getting an access request. Over several years that setting accumulates across salary reviews, board packs, client contracts and incident notes, all of which are now retrievable by anybody who asks the right question.
The counter argument is that this was always the access position, and the assistant changed nothing about who is permitted to read what. That is technically correct and practically beside the point. Controls work through a combination of permission and friction, and removing friction from a weak permission model produces a real change in exposure even though no policy changed.
The fix is not to block the assistant. Run a sharing report across Drive, find domain wide links on anything sensitive, and tighten those before the rollout. Our guidance on auditing user access rights applies to Drive as directly as it applies to any other system.
Shared drives with membership nobody reviews
Shared drives grant access at the drive level, so adding somebody to help with one document gives them everything in it, permanently, including material added after they stopped being involved. Membership lists grow and effectively never shrink.
Some teams argue that shared drives are an improvement over the old folder model precisely because access is explicit and visible. That is true, and it is why the fix is cheap here: membership is a list somebody can read in an afternoon. Review the drives holding regulated or commercially sensitive content first, and leave the project ones for later.
Departed employees whose content stayed shared
Offboarding usually covers account suspension and mailbox delegation, and it frequently misses documents that person shared externally before leaving. Those external grants survive the account.
The objection that this is an offboarding problem rather than an AI problem is correct, and the AI rollout is simply what surfaces it. External sharing reports exist in the admin console and almost nobody runs them. Running one before the rollout is a short task that tends to produce a genuinely uncomfortable list, which is the point. Backup and retention interact with the same question, covered in our piece on Google Workspace backup gaps.
The AI capabilities worth evaluating inside Workspace first
Google Workspace AI capability now sits in three layers, and evaluating them in order avoids paying for an add-on that duplicates something already licensed. The layers differ in where data goes and who governs the grant, which matters more than the feature list.
Native assistance already inside the suite
Smart Compose, Smart Fill in Sheets, automated meeting notes and the assistant panels across Docs, Sheets, Slides and Gmail cover the majority of everyday requests. They run inside the tenant under the existing agreement, so there is no new vendor, no new grant and no new data path to review.
Their limitation is that they work within one document or one thread at a time and do not reason across a corpus. Teams wanting cross document synthesis genuinely need something more, and that is the point at which a second layer earns consideration.
Marketplace add-ons and what they ask for
Add-ons install as a sidebar across the suite and typically request scopes at install time. The useful discrimination is between an add-on scoped to the currently open file and one requesting access to all files in Drive, because those are different products from a risk perspective even when the feature looks identical.
The argument for permissive scopes is genuine functionality: cross document work requires cross document access. Accept that where the use case needs it, and pair it with an allowlist so the decision is deliberate rather than a consequence of whoever clicked install. The general approach is the same one behind our AI enhanced security work.
Apps Script for the automation nobody sells
A large share of what teams ask an AI add-on to do is deterministic: move a row when a form is submitted, file an attachment, format a report. Apps Script does that natively, runs under the tenant’s own identity, costs nothing extra, and leaves an auditable trail.
It requires somebody who can write it, which is the honest constraint. For firms with no scripting capability an add-on is the pragmatic choice. For firms with one person who can, a short script often replaces a subscription and a third party grant at the same time.
The risk worth naming is that scripts written by one person and never documented become their own kind of debt. A script running under a departed employee’s account, firing on a trigger nobody remembers configuring, is a small but real operational hazard. Run them under a service account, keep them in a shared project, and write down what each one does.
Data loss prevention rules and Drive labels
Workspace carries classification labels on Drive files and rules that act on content patterns, and both keep working when an assistant is in the picture. A label marking a folder as restricted, paired with a rule blocking external sharing of anything carrying it, is the control that survives whichever tool gets installed next.
The friction cost is labelling itself. Nobody at a fifty person firm is going to classify every document, and a labelling scheme that demands it will be abandoned inside a month. Label the two or three categories that actually carry consequence, usually regulated client data and anything under contract confidentiality, and leave everything else unlabelled on purpose.
Meeting transcription and the consent question
Automated meeting notes and transcripts are the fastest adopted feature in this whole category and the one most likely to create a record nobody intended. A transcript of a performance conversation or a commercial negotiation persists, is searchable, and is discoverable.
The argument for leaving it on everywhere is that shared notes genuinely improve follow through, and they do. The workable position is to keep the capability and set an expectation about announcing recording, plus a retention window short enough that transcripts do not accumulate into an archive nobody reviewed. That is a policy and briefing task rather than a technical one.
Governing the grant after the rollout
Workspace Marketplace add-on review is a recurring control rather than a one time decision, and the grant is what makes it so. An install authorises a third party until somebody revokes it, and nothing expires on its own.
Restricting installs without blocking the work
The admin console can restrict marketplace installs to an allowlist, which changes the default from install first to request first. That single setting does most of the governance work available here.
The cost is a request queue and the friction that comes with it, and teams that turn it on without staffing the queue find users routing around it with personal accounts, which is worse than where they started. Turn it on with a named approver and a short turnaround commitment, or do not turn it on.
Reviewing OAuth grants on a schedule
The admin console lists every third party application holding a grant against tenant data, including ones installed by individuals years ago. A quarterly pass over that list, revoking what nobody recognises, takes under an hour and is the highest yield recurring control in this whole area.
Pair it with user briefing, because most risky grants come from somebody approving a consent screen without reading it. That is a training problem as much as a technical one, which is why security awareness training usually moves the number more than another policy does. Wider workspace governance sits alongside it, as our piece on secure workspace practice covers.
Frequently Asked Questions
Can an AI assistant in Google Workspace see files a user cannot?
No. Assistants operate under the requesting user’s permissions and return only what that person could already open. The practical effect is still an increase in exposure, because content that was accessible but hard to find becomes easy to surface.
What should be checked before installing a Workspace AI add-on?
Read the OAuth scopes it requests, decide whether cross document access is genuinely needed, confirm where the vendor processes and stores extracted content, and check whether your tier’s data handling commitments cover it. Install through an admin allowlist rather than per user.
Is Gemini included in Google Workspace or a separate purchase?
Assistance features are bundled into the business and enterprise tiers, with capability differing by tier and some advanced functions still carried as add-ons. Confirm what your specific subscription includes before buying a third party tool that overlaps it.
Do AI add-ons work if files are stored in shared drives?
They generally do, and shared drives are where the permission question gets sharpest. Membership is granted at the drive level, so an assistant can retrieve anything in a drive the user belongs to, including material added long after they joined.
How often should OAuth grants be reviewed?
Quarterly is workable for most firms at this size and takes under an hour. The list in the admin console shows every third party application holding access, and revoking unrecognised grants is the single highest yield recurring control available here.
Who is behind this guidance
Mindcore has run cloud estates for small and mid sized firms for more than two decades across both major suites, which means we spend a lot of time in sharing reports and OAuth grant lists. The patterns above come from engagements where the request was to evaluate an AI add-on and the work turned out to be a Drive permissions cleanup first, alongside the cloud security and cyber security audit reviews that usually run with it.
Matt Rosenthal, our chief executive, focuses on how firms adopt new capability without quietly accumulating access nobody is tracking. His position on assistants reading company content is that the tool is rarely the exposure, and the sharing state it reveals almost always is.
Run the sharing report before you pick the tool
The sequence here is what keeps a rollout safe and cheap. Run the Drive external and domain wide sharing reports, tighten what they surface, and review shared drive membership on anything regulated. List the OAuth grants already held and revoke what nobody recognises. Turn on marketplace allowlisting with a named approver. Then evaluate what the native features already do before buying an add-on to do the same thing.
If you want somebody to run those reports with you before the tool goes in, book a free strategy call and we will work through the estate together.
