El 3 de agosto Cursor publicó cinco plugins oficiales que conectan los coding agents con Google Workspace. El changelog abre con una frase que conviene leer dos veces: “Cursor can now read, write, and act across your Google Workspace.”
Leer, escribir y actuar. No solo leer. Los cinco plugins — Drive, Gmail, Calendar, Docs y Sheets — se instalan desde el Cursor Marketplace o desde la página Customize, y todo el flujo toma unos cinco clics. En algún punto de esos cinco clics hay un consent screen de Google que decide cuánto de tu vida laboral puede tocar un agente autónomo, y es la única pantalla de la secuencia en la que realmente tienes que detenerte a pensar.
Esta es una guía sobre esa pantalla.
Qué se publicó exactamente
Las capacidades declaradas, plugin por plugin:
- Drive — buscar archivos y carpetas, abrir y descargar contenido, crear y organizar archivos. La ficha del Marketplace agrega un verbo que el changelog omite: share.
- Gmail — buscar y leer correo, redactar y enviar mensajes, aplicar labels, gestionar threads.
- Calendar — leer agendas, crear y actualizar eventos, encontrar espacios libres.
- Docs — abrir y leer documentos, escribir y editar texto, crear documentos nuevos.
- Sheets — leer rangos y buscar valores, actualizar celdas, crear y editar spreadsheets.
Hay un detalle estructural que el changelog deja fuera y que cambia cómo deberías pensar todo esto. Estos plugins no son integraciones construidas por Cursor. Cada ficha del Marketplace dice lo mismo: “Connect Cursor to Gmail via Google’s remote MCP server.” Cursor está empaquetando los remote MCP servers del propio Google detrás de una instalación de un clic. Eso es buena noticia para la confiabilidad — estás hablando con la infraestructura de Google, no con un scraper de terceros — y significa que el modelo de permisos que importa es el consent de OAuth de Google, no algo que Cursor haya inventado.
Por eso este artículo vive en el consent screen.
Anatomía del consent screen de Gmail
Instalas el plugin de Gmail y Google te muestra tres casillas bajo el título “Select what Cursor can access”. Corresponden a scopes estándar de la Gmail API:
| Casilla | Scope | Qué concede |
|---|---|---|
| View your email messages and settings | gmail.readonly |
Solo lectura. Buscar, leer, nada más. |
| Manage drafts and send emails | gmail.compose |
Crear drafts y enviarlos. |
| Read, compose, and send emails from your Gmail account | gmail.modify |
Todo, salvo el borrado permanente que se salta la papelera. |
Hay tres cosas en esta pantalla en las que vale la pena detenerse.
Primero: nada viene marcado por defecto. Arriba hay un “Select all”, y es el camino de menor resistencia. También es el permiso máximo. Puedes instalar este plugin con solo la primera casilla marcada y tener un agente de solo lectura perfectamente útil, que busca threads y trae contexto a tu editor sin capacidad de enviar un solo mensaje. Es la decisión de mayor impacto de toda la instalación, y basta un clic para equivocarla.
Segundo: no existe un camino a las labels sin conceder envío. Mira lo que anuncia el plugin: buscar, leer, redactar, etiquetar, gestionar threads. Etiquetar un mensaje pasa por messages.modify, que vive bajo el scope gmail.modify. Esa es la tercera casilla. Y esa casilla también concede redactar y enviar. Google sí publica un scope más angosto, gmail.labels, pero aquí no se ofrece. Así que si quieres un agente que lea tu inbox y lo ordene — posiblemente lo más aburrido, lo más útil y lo de menor riesgo que un agente podría hacer con tu correo — el consent screen te obliga a concederle envío para conseguirlo. No hay configuración de solo-leer-y-etiquetar. Conviene saberlo antes de dar por sentado que el caso de uso “ordenar el inbox” es el seguro.
Tercero: el permiso tiene fecha de vencimiento, salvo que la desactives tú. Google indica que el acceso expira en una fecha fija (31 de enero de 2027 en el flujo que capturamos) con una revisión cada seis meses, y ofrece una casilla: “I want to allow Cursor ongoing access to the Google Account data I’m sharing today.” Marcarla elimina el vencimiento. Déjala en blanco. Una revisión forzada cada seis meses de lo que un agente autónomo puede hacerle a tu casilla de correo no es fricción, es la función. Si en seis meses la integración sigue justificándose, volver a aprobarla te cuesta treinta segundos.
Ahora mira Drive — y fíjate que está construido al revés
Instalas el plugin de Drive y Google te muestra otra pantalla. Dos casillas:
| Casilla | Scope | Qué concede |
|---|---|---|
| See and download all your Google Drive files | drive.readonly |
Solo lectura, sobre todo tu Drive. Google lo clasifica como restricted scope. |
| See, edit, create, and delete only the specific Google Drive files you use with this app | drive.file |
Lectura y escritura, pero solo sobre los archivos que abres explícitamente con la app o que la app creó. Google lo clasifica como non-sensitive y lo recomienda. |
Lee esa tabla de nuevo, porque la intuición que traes del consent screen de Gmail está a punto de fallarte.
En Gmail, solo lectura era la opción segura y escribir implicaba un permiso sobre toda la casilla. En Drive se invierte: la opción de solo lectura es la amplia y restricted — todos los archivos de tu Drive, incluidos los que olvidaste que estaban ahí — mientras que la de lectura y escritura es la angosta, acotada archivo por archivo. drive.file es un permiso genuinamente bien diseñado: el agente puede crear, editar y borrar, pero solo dentro del conjunto de archivos que le entregaste. No puede salir a buscar.
O sea que la recomendación por defecto para Drive es la segunda casilla sola. No la primera. El instinto de marcar solo lectura “por las dudas” le entrega al agente más datos tuyos, no menos.
Esa asimetría es lo más útil del lanzamiento. Mismo vendor, mismo día, dos plugins envolviendo dos MCP servers de Google — y uno ofrece un scope de escritura angosto mientras el otro no ofrece ninguno. El catálogo de scopes de Google es el que es, y Cursor heredó ambos diseños sin tocarlos. La lección para quien audite estas instalaciones: no generalices de un consent screen al siguiente. Lee cada uno.
Una precisión sobre el verbo share de la ficha del Marketplace. Con drive.file, los cambios de permisos quedan confinados a los archivos que ya están en el scope de la app, así que el escenario de exfiltración por compartir queda acotado a lo que tú entregaste, no a tu Drive completo. Es bastante mejor de lo que parece a primera vista. Aun así conviene ser deliberado con qué abres desde el plugin, porque todo lo que abres se convierte en algo que el agente puede compartir.
Cómo mantener el permiso chico
Minimizar el scope es la primera palanca. Este es el resto de la lista.
Usa una cuenta de Google separada cuando puedas. La contención más fuerte no es un setting de permisos, es un límite de cuenta. Un agente conectado a una cuenta de trabajo que tiene specs, tickets y documentos de proyecto — pero no tu correo personal, no tus comprobantes de pago, no tu flujo de recuperación de contraseñas — pone mucho menos en juego que cualquier combinación de scopes sobre tu identidad principal.
Prefiere drive.file sobre drive.readonly, y marca una sola casilla por pantalla. Ningún consent screen te exige conceder ambas opciones. En Drive, la segunda casilla sola cubre los workflows realistas. En Gmail, decide honestamente si necesitas las labels lo suficiente como para conceder envío — y si no, la primera casilla sola te da un agente de investigación de solo lectura que no puede tocar nada.
Usa los sandbox access controls de Cursor. Desde Cursor 2.5, la ejecución de comandos del agente corre contra restricciones configurables de red y filesystem: un allowlist de dominios definido en sandbox.json, opcionalmente combinado con los defaults de Cursor, más controles sobre qué directorios y archivos locales puede alcanzar el agente. Los admins enterprise pueden empujar allowlists y denylists a nivel de organización desde el admin dashboard. Esto no limita lo que el MCP server puede hacer con tus datos de Google, pero sí limita todo lo que el agente puede hacer con lo que aprende.
Entiende qué acabas de cambiar en tu threat model. Esta parte no tiene nada que ver con casillas. Antes de estos plugins, el input no confiable que llegaba a tu agente era mayormente código que tú elegiste abrir. Ahora es tu inbox. Cada correo que cualquiera pueda mandarte es contenido que tu agente puede leer y, según cómo tengas configurada la autonomía, sobre el que puede actuar. El prompt injection deja de ser una curiosidad de laboratorio en el momento en que un atacante puede poner texto frente a tu agente con solo conocer tu dirección de correo — y puede hacerlo con un permiso que además le deja responder. Los scopes de solo lectura tampoco resuelven esto del todo, porque un agente de Gmail en solo lectura que además tiene acceso de escritura a tu repo sigue siendo un camino desde el correo de un desconocido hasta tu codebase. Mantén un humano en el loop en todo lo que envíe, commitee o comparta.
El cambio de fondo
Lo interesante de este lanzamiento no son los cinco plugins. Es lo que dicen sobre hacia dónde va el contexto de los agentes. Tus specs viven en Docs. Tus tickets viven en un Sheet. La decisión que explica por qué este módulo es raro está en un thread de Gmail de marzo. Nada de eso está en el repo, y hasta ahora nada de eso era alcanzable por el agente que trabaja en el repo.
Cursor acaba de volverlo alcanzable en cinco clics. Gasta uno de esos clics leyendo el consent screen.
Y tú, ¿le darías acceso a tu inbox a un agente que también puede escribir en tu repo, o trazas la línea en solo lectura?