Em 3 de agosto, o Cursor publicou cinco plugins oficiais que conectam agentes de codificação com o Google Workspace. O changelog abre com uma frase que vale a pena ler duas vezes: “O Cursor agora pode ler, escrever e agir em todo o seu Google Workspace.”
Ler, escrever e agir. Não apenas ler. Os cinco plugins — Drive, Gmail, Calendar, Docs e Sheets — são instalados a partir do Cursor Marketplace ou da página Customize, e todo o fluxo leva apenas cinco cliques. Em algum ponto desses cinco cliques há uma tela de consentimento do Google que decide quanto da sua vida profissional um agente autônomo pode acessar, e é a única tela da sequência em que você realmente precisa parar para pensar.
Este é um guia sobre essa tela.
O que foi publicado exatamente
As capacidades declaradas, plugin por plugin:
- Drive — buscar arquivos e pastas, abrir e baixar conteúdo, criar e organizar arquivos. A ficha do Marketplace adiciona um verbo que o changelog omite: compartilhar.
- Gmail — buscar e ler e-mails, redigir e enviar mensagens, aplicar labels, gerenciar threads.
- Calendar — ler agendas, criar e atualizar eventos, encontrar espaços livres.
- Docs — abrir e ler documentos, escrever e editar texto, criar novos documentos.
- Sheets — ler intervalos e buscar valores, atualizar células, criar e editar planilhas.
Há um detalhe estrutural que o changelog deixa de fora e que muda como você deveria pensar tudo isso. Esses plugins não são integrações construídas pelo Cursor. Cada ficha do Marketplace diz a mesma coisa: “Conecte o Cursor ao Gmail através do servidor MCP remoto do Google.” O Cursor está empacotando os servidores MCP remotos do próprio Google atrás de uma instalação de um clique. Isso é uma boa notícia para a confiabilidade — você está falando com a infraestrutura do Google, não com um scraper de terceiros — e significa que o modelo de permissões que importa é o consentimento OAuth do Google, não algo que o Cursor tenha inventado.
Por isso este artigo vive na tela de consentimento.
Anatomia da tela de consentimento do Gmail
Você instala o plugin do Gmail e o Google mostra três caixas sob o título “Selecione o que o Cursor pode acessar”. Elas correspondem aos scopes padrão da API do Gmail:
| Caixa | Scope | O que concede |
|---|---|---|
| Ver suas mensagens de e-mail e configurações | gmail.readonly |
Apenas leitura. Buscar, ler, nada mais. |
| Gerenciar rascunhos e enviar e-mails | gmail.compose |
Criar rascunhos e enviá-los. |
| Ler, redigir e enviar e-mails da sua conta do Gmail | gmail.modify |
Tudo, exceto exclusão permanente que pula a lixeira. |
Há três coisas nessa tela que vale a pena considerar.
Primeiro: nada vem marcado por padrão. No topo há um “Selecionar tudo”, e é o caminho de menor resistência. Também é a permissão máxima. Você pode instalar esse plugin com apenas a primeira caixa marcada e ter um agente somente leitura perfeitamente útil, que busca threads e traz contexto para seu editor sem capacidade de enviar uma única mensagem. É a decisão de maior impacto de toda a instalação, e basta um clique para errá-la.
Segundo: não existe um caminho para labels sem conceder envio. Veja o que o plugin anuncia: buscar, ler, redigir, etiquetar, gerenciar threads. Etiquetar uma mensagem passa por messages.modify, que vive sob o scope gmail.modify. Essa é a terceira caixa. E essa caixa também concede redigir e enviar. O Google sim publica um scope mais estreito, gmail.labels, mas aqui ele não é oferecido. Então, se você quer um agente que leia sua caixa de entrada e a organize — possivelmente o mais entediante, o mais útil e o de menor risco que um agente poderia fazer com seu e-mail — a tela de consentimento o obriga a conceder envio para conseguir isso. Não há configuração apenas-ler-e-etiquetar. Vale a pena saber disso antes de dar por sentado que o caso de uso “organizar a caixa de entrada” é o seguro.
Terceiro: a permissão tem data de vencimento, a menos que você a desative. O Google indica que o acesso expira em uma data fixa (31 de janeiro de 2027 no fluxo que capturamos) com uma revisão a cada seis meses, e oferece uma caixa: “Quero permitir que o Cursor tenha acesso contínuo aos dados da Conta do Google que estou compartilhando hoje.” Marcar essa caixa elimina o vencimento. Deixe-a em branco. Uma revisão forçada a cada seis meses do que um agente autônomo pode fazer para sua caixa de e-mail não é atrito, é a função. Se em seis meses a integração ainda se justificar, aprovar novamente lhe custa trinta segundos.
Agora olhe para o Drive — e note que está construído ao contrário
Você instala o plugin do Drive e o Google mostra outra tela. Duas caixas:
| Caixa | Scope | O que concede |
|---|---|---|
| Ver e baixar todos os seus arquivos do Google Drive | drive.readonly |
Apenas leitura, sobre todo o seu Drive. O Google o classifica como scope restrito. |
| Ver, editar, criar e deletar apenas os arquivos específicos do Google Drive que você usa com este aplicativo | drive.file |
Leitura e escrita, mas apenas nos arquivos que você abre explicitamente com o aplicativo ou que o aplicativo criou. O Google o classifica como não-sensível e o recomenda. |
Leia essa tabela novamente, porque a intuição que você traz da tela de consentimento do Gmail está prestes a falhar.
No Gmail, apenas leitura era a opção segura e escrever implicava uma permissão sobre toda a caixa. No Drive se inverte: a opção de apenas leitura é a ampla e restrita — todos os arquivos do seu Drive, incluindo aqueles que você esqueceu que estavam lá — enquanto a de leitura e escrita é a estreita, delimitada arquivo por arquivo. drive.file é uma permissão genuinamente bem projetada: o agente pode criar, editar e deletar, mas apenas dentro do conjunto de arquivos que você entregou. Ele não pode sair procurando.
Ou seja, a recomendação padrão para Drive é a segunda caixa sozinha. Não a primeira. O instinto de marcar apenas leitura “para ser seguro” entrega ao agente mais dados seus, não menos.
Essa assimetria é o mais útil do lançamento. Mesmo fornecedor, mesmo dia, dois plugins envolvendo dois servidores MCP do Google — e um oferece um scope de escrita estreito enquanto o outro não oferece nenhum. O catálogo de scopes do Google é o que é, e o Cursor herdou ambos os designs sem tocá-los. A lição para quem audite essas instalações: não generalize de uma tela de consentimento para a próxima. Leia cada uma.
Uma observação sobre o verbo compartilhar da ficha do Marketplace. Com drive.file, as mudanças de permissões ficam confinadas aos arquivos que já estão no escopo do aplicativo, então o cenário de exfiltração por compartilhamento fica limitado ao que você entregou, não ao seu Drive completo. É bastante melhor do que parece à primeira vista. Ainda assim, vale a pena ser deliberado sobre o que você abre a partir do plugin, porque tudo o que você abre se torna algo que o agente pode compartilhar.
Como manter a permissão pequena
Minimizar o scope é a primeira alavanca. Este é o resto da lista.
Use uma conta do Google separada quando puder. O confinamento mais forte não é uma configuração de permissões, é um limite de conta. Um agente conectado a uma conta de trabalho que tem specs, tickets e documentos de projeto — mas não seu e-mail pessoal, não seus comprovantes de pagamento, não seu fluxo de recuperação de senhas — coloca muito menos em risco do que qualquer combinação de scopes na sua identidade principal.
Prefira drive.file em vez de drive.readonly, e marque apenas uma caixa por tela. Nenhuma tela de consentimento o obriga a conceder ambas as opções. No Drive, a segunda caixa sozinha cobre os workflows realistas. No Gmail, decida honestamente se você precisa das labels o suficiente para conceder envio — e se não, a primeira caixa sozinha oferece um agente de investigação apenas leitura que não pode tocar nada.Use os controles de acesso sandbox do Cursor. A partir do Cursor 2.5, a execução de comandos do agente roda contra restrições configuráveis de rede e filesystem: uma allowlist de domínios definida em sandbox.json, opcionalmente combinada com os padrões do Cursor, mais controles sobre quais diretórios e arquivos locais o agente pode acessar. Admins enterprise podem enviar allowlists e denylists no nível da organização pelo painel de admin. Isso não limita o que o servidor MCP pode fazer com seus dados do Google, mas limita tudo o que o agente pode fazer com o que aprende.
Entenda o que você acabou de mudar no seu modelo de ameaça. Esta parte não tem nada a ver com caixas de seleção. Antes destes plugins, o input não confiável que chegava ao seu agente era majoritariamente código que você escolheu abrir. Agora é sua caixa de entrada. Cada e-mail que qualquer pessoa possa lhe enviar é conteúdo que seu agente pode ler e, dependendo de como você configurou a autonomia, sobre o qual pode agir. A injeção de prompt deixa de ser uma curiosidade de laboratório no momento em que um atacante pode colocar texto na frente do seu agente apenas conhecendo seu endereço de e-mail — e pode fazer isso com uma permissão que ainda lhe permite responder. Os escopos de apenas leitura também não resolvem isso completamente, porque um agente do Gmail somente leitura que também tem acesso de escrita ao seu repo continua sendo um caminho do e-mail de um desconhecido até seu codebase. Mantenha um humano no loop em tudo o que enviar, fazer commit ou compartilhar.
A mudança fundamental
O interessante sobre este lançamento não são os cinco plugins. É o que eles dizem sobre para onde vai o contexto dos agentes. Suas specs vivem no Docs. Seus tickets vivem em uma Sheet. A decisão que explica por que este módulo é estranho está em uma thread do Gmail de março. Nada disso está no repo, e até agora nada disso era alcançável pelo agente que trabalha no repo.
O Cursor acabou de tornalo alcançável em cinco cliques. Gaste um desses cliques lendo a tela de consentimento.
E você, daria acesso à sua caixa de entrada a um agente que também pode escrever no seu repo, ou traça a linha apenas em leitura?