On August 3rd, Cursor published five official plugins that connect coding agents with Google Workspace. The changelog opens with a phrase worth reading twice: “Cursor can now read, write, and act across your Google Workspace.”
Read, write, and act. Not just read. The five plugins — Drive, Gmail, Calendar, Docs, and Sheets — are installed from the Cursor Marketplace or from the Customize page, and the entire flow takes about five clicks. At some point in those five clicks there’s a Google consent screen that decides how much of your work life an autonomous agent can touch, and it’s the only screen in the sequence where you actually have to stop and think.
This is a guide about that screen.
What exactly was released
The declared capabilities, plugin by plugin:
- Drive — search files and folders, open and download content, create and organize files. The Marketplace listing adds a verb that the changelog omits: share.
- Gmail — search and read email, draft and send messages, apply labels, manage threads.
- Calendar — read calendars, create and update events, find free slots.
- Docs — open and read documents, write and edit text, create new documents.
- Sheets — read ranges and search values, update cells, create and edit spreadsheets.
There’s a structural detail that the changelog leaves out and that changes how you should think about all this. These plugins aren’t integrations built by Cursor. Each Marketplace listing says the same thing: “Connect Cursor to Gmail via Google’s remote MCP server.” Cursor is packaging Google’s own remote MCP servers behind a one-click installation. That’s good news for reliability — you’re talking to Google’s infrastructure, not a third-party scraper — and it means the permissions model that matters is Google’s OAuth consent, not something Cursor invented.
That’s why this article lives in the consent screen.
Anatomy of the Gmail consent screen
You install the Gmail plugin and Google shows you three checkboxes under the heading “Select what Cursor can access”. They correspond to standard scopes of the Gmail API:
| Checkbox | Scope | What it grants |
|---|---|---|
| View your email messages and settings | gmail.readonly |
Read-only. Search, read, nothing else. |
| Manage drafts and send emails | gmail.compose |
Create drafts and send them. |
| Read, compose, and send emails from your Gmail account | gmail.modify |
Everything, except permanent deletion which skips the trash. |
There are three things on this screen worth pausing over.
First: nothing is checked by default. At the top there’s a “Select all”, and it’s the path of least resistance. It’s also maximum permissions. You can install this plugin with only the first checkbox checked and have a perfectly useful read-only agent that searches threads and brings context to your editor without the ability to send a single message. It’s the highest-impact decision of the entire installation, and it takes just one click to get it wrong.
Second: there is no path to labels without granting send. Look at what the plugin advertises: search, read, draft, label, manage threads. Labeling a message goes through messages.modify, which lives under the gmail.modify scope. That’s the third checkbox. And that checkbox also grants drafting and sending. Google does publish a narrower scope, gmail.labels, but it’s not offered here. So if you want an agent that reads your inbox and organizes it — possibly the most tedious, most useful, and lowest-risk thing an agent could do with your email — the consent screen forces you to grant it send access to get it. There’s no read-and-label-only configuration. It’s worth knowing before you assume that the “organize the inbox” use case is the safe one.
Third: the permission has an expiration date, unless you disable it. Google indicates that access expires on a fixed date (January 31, 2027 in the flow we captured) with a review every six months, and offers a checkbox: “I want to allow Cursor ongoing access to the Google Account data I’m sharing today.” Checking it removes the expiration. Leave it unchecked. A forced review every six months of what an autonomous agent can do to your mailbox isn’t friction, it’s the feature. If in six months the integration still justifies itself, re-approving it costs you thirty seconds.
Now look at Drive — and notice it’s built backwards
You install the Drive plugin and Google shows you another screen. Two checkboxes:
| Checkbox | Scope | What it grants |
|---|---|---|
| See and download all your Google Drive files | drive.readonly |
Read-only, over everything in your Drive. Google classifies it as a restricted scope. |
| See, edit, create, and delete only the specific Google Drive files you use with this app | drive.file |
Read and write, but only over files you explicitly open with the app or that the app created. Google classifies it as non-sensitive and recommends it. |
Read that table again, because the intuition you’re bringing from the Gmail consent screen is about to fail you.
In Gmail, read-only was the safe option and writing implied permission over the whole mailbox. In Drive it’s inverted: the read-only option is the broad and restricted one — all the files in your Drive, including the ones you forgot were there — while the read and write one is the narrow, file-by-file one. drive.file is a genuinely well-designed permission: the agent can create, edit, and delete, but only within the set of files you handed it. It can’t go searching.
So the default recommendation for Drive is the second checkbox alone. Not the first. The instinct to check read-only “just to be safe” gives the agent more of your data, not less.
That asymmetry is the most useful thing about the launch. Same vendor, same day, two plugins wrapping two Google MCP servers — and one offers a narrow write scope while the other doesn’t offer one at all. Google’s scope catalog is what it is, and Cursor inherited both designs without touching them. The lesson for anyone auditing these installations: don’t generalize from one consent screen to the next. Read each one.
A clarification about the share verb from the Marketplace listing. With drive.file, permission changes stay confined to files already in the app’s scope, so the exfiltration-by-sharing scenario is bounded by what you handed over, not your entire Drive. It’s much better than it looks at first glance. Still, it’s worth being deliberate about what you open from the plugin, because everything you open becomes something the agent can share.
How to keep permissions small
Minimizing scope is the first lever. Here’s the rest of the list.
Use a separate Google account when you can. The strongest containment isn’t a permissions setting, it’s an account boundary. An agent connected to a work account that has specs, tickets, and project documents — but not your personal email, not your payment receipts, not your password recovery flow — puts much less at stake than any combination of scopes over your primary identity.
Prefer drive.file over drive.readonly, and check only one box per screen. No consent screen requires you to grant both options. On Drive, the second checkbox alone covers realistic workflows. On Gmail, honestly decide if you need the labels badly enough to grant send — and if not, the first checkbox alone gives you a read-only research agent that can’t touch anything.
Use Cursor’s sandbox access controls. Since Cursor 2.5, agent command execution runs against configurable network and filesystem restrictions: an allowlist of domains defined in sandbox.json, optionally combined with Cursor’s defaults, plus controls over which local directories and files the agent can reach. Enterprise admins can push allowlists and denylists at the organization level from the admin dashboard. This doesn’t limit what the MCP server can do with your Google data, but it does limit everything the agent can do with what it learns.
Understand what you just changed in your threat model. This part has nothing to do with checkboxes. Before these plugins, untrusted input reaching your agent was mostly code that you chose to open. Now it’s your inbox. Every email anyone can send you is content your agent can read and, depending on how you configure autonomy, can act on. Prompt injection stops being a lab curiosity the moment an attacker can put text in front of your agent by just knowing your email address — and can do it with a permission that also lets them reply. Read-only scopes don’t fully solve this either, because a Gmail agent in read-only that also has write access to your repo is still a path from a stranger’s email to your codebase. Keep a human in the loop on everything it sends, commits, or shares.
The Big Picture
What’s interesting about this release isn’t the five plugins. It’s what they say about where agent context is headed. Your specs live in Docs. Your tickets live in a Sheet. The decision explaining why this module is weird is in a Gmail thread from March. None of that is in the repo, and until now none of that was reachable by the agent working in the repo.
Cursor just made it reachable in five clicks. Spend one of those clicks reading the consent screen.
Would you give an agent access to your inbox if it can also write to your repo, or do you draw the line at read-only?