Extensiones IA con acceso a Gmail: qué debe revisar tu empresa

Antes de aprobar una extensión de IA en el navegador con acceso a Gmail y Calendar, tu empresa debe revisar dos capas de permisos distintas: los permisos de la extensión de Chrome (qué puede leer o modificar en la página que estás viendo) y los scopes OAuth concedidos a la API de Google (qué puede hacer directamente con tus datos vía backend). Auditar solo una de las dos capas deja la otra sin control, y es exactamente ahí donde se cuela el riesgo real.

Cuando una extensión de IA como Claude for Chrome se instala, el usuario pasa por dos pantallas de consentimiento distintas que casi nadie separa mentalmente. La primera es el permiso de Chrome Web Store: la extensión pide poder leer y cambiar todos los datos en todos los sitios web que visitas, porque necesita ver el contenido de la pestaña activa para poder actuar sobre ella. La segunda, si la extensión se conecta a Gmail o Calendar vía API en lugar de solo leer el DOM, es una pantalla OAuth de Google donde se listan los scopes concretos: gmail.readonly, gmail.modify, calendar.events, etc. Son dos sistemas de permisos completamente independientes, gestionados por equipos distintos dentro de Google, y un departamento de IT que solo revisa el panel de apps de terceros de Workspace está viendo la mitad del riesgo. La otra mitad, qué puede hacer la extensión directamente sobre lo que el usuario ve en pantalla sin pasar por ninguna API, no aparece en ese panel.

Por qué esto importa más en Gmail y Calendar que en cualquier otra app

Gmail y Calendar concentran el tipo de dato que más vale en una intrusión silenciosa: correspondencia con clientes, contraseñas reenviadas por correo, invitaciones de reuniones con enlaces internos, contratos adjuntos. Una extensión con acceso amplio no necesita robar nada en el sentido clásico; le basta con poder leer lo que ya está abierto en la pestaña o con tener un scope de lectura que se ejecuta en segundo plano cada vez que el usuario abre el correo. Google clasifica gmail.modify y los scopes de Calendar como sensibles o restringidos precisamente porque el daño potencial de un mal uso, intencionado o por una brecha en el proveedor, es alto. El problema no es que un proveedor grande vaya a usar mal esos datos; el problema es que la superficie de exposición crece con cada extensión aprobada, y la mayoría de empresas no llevan un inventario vivo de cuántas tienen ese nivel de acceso activo en este momento.

Google no deja que cualquier aplicación pida acceso a scopes restringidos de Gmail o Calendar sin pasar antes por un proceso de verificación. Para los scopes más sensibles, el desarrollador debe superar una evaluación de seguridad de terceros conocida como CASA (Cloud Application Security Assessment), un proceso anual y de pago que revisa cómo se almacenan, cifran y usan los datos obtenidos, documentado públicamente por Google en su centro para desarrolladores de OAuth. Si una extensión pide esos scopes y no ha pasado esa verificación, Chrome y Google muestran una pantalla de advertencia explícita antes de conceder el permiso, pero esa pantalla es fácil de saltarse con un par de clics y en la práctica casi ningún empleado se detiene a leerla. Que una extensión esté verificada no es garantía de que su uso sea adecuado para tu empresa, pero que no lo esté es una señal de alarma que debería bloquear la aprobación automáticamente.

• gmail.readonly: lectura de correos y metadatos, sin poder enviar ni borrar — el nivel mínimo razonable para un asistente de IA
• gmail.modify: lectura, envío, archivado y etiquetado — necesario si la IA gestiona correo en tu nombre, pero mucho más peligroso si la sesión se compromete
• gmail.send o compose: puede enviar correos como si fueras tú, el vector perfecto para fraude del CEO automatizado si el proveedor sufre una brecha
• calendar.events: lectura y escritura de eventos, incluyendo invitados y ubicaciones, expone patrones de reuniones con clientes y socios
• acceso de extensión 'en todos los sitios': permite leer el contenido renderizado de cualquier pestaña abierta, independiente de cualquier scope OAuth concedido

• Comprobar en Google Workspace Admin > Seguridad > Control de acceso a API qué apps de terceros están ya autorizadas y con qué scopes exactos
• Separar la revisión en dos partes: permisos de extensión de Chrome (host permissions) y scopes OAuth de la API, no dar por válida una sin la otra
• Verificar si el proveedor ha pasado la verificación OAuth de Google para scopes restringidos, visible en la pantalla de consentimiento
• Marcar la app como de confianza o bloquearla explícitamente a nivel de organización en el admin console, en lugar de dejar la decisión a cada usuario
• Leer la política de retención y uso de datos del proveedor: si los correos o eventos se usan para entrenar modelos y durante cuánto tiempo se conservan
• Activar y revisar el Investigation Tool de Workspace tras la aprobación para detectar patrones de acceso anómalos en los primeros días
• Fijar una fecha de revisión periódica de permisos concedidos, porque las actualizaciones de la extensión pueden ampliar el alcance sin que nadie vuelva a aprobarlo explícitamente

El error más común: confundir el clic de un empleado con gobernanza corporativa

En la mayoría de empresas que auditamos, la aprobación real de este tipo de extensiones ocurre en el momento en que un empleado pulsa permitir en su propio navegador, sin que IT lo sepa hasta semanas después, si es que llega a saberlo. Eso no es gobernanza, es shadow IT con forma de asistente de productividad. El admin console de Google Workspace permite restringir qué aplicaciones de terceros pueden solicitar acceso OAuth a los datos corporativos, pero esa función solo protege si está configurada de forma restrictiva por defecto, algo que muchas pymes nunca activan porque exige fricción adicional para herramientas legítimas. La consecuencia práctica es que el inventario real de quién tiene acceso a qué vive en la cabeza de cada empleado, no en ningún panel de control. Cualquier auditoría de seguridad que empiece por el catálogo oficial de aplicaciones aprobadas, en lugar de por los logs reales de autorizaciones concedidas, se queda corta desde el primer minuto.

Aquí viene la parte incómoda: no todas las extensiones de IA con acceso a Gmail son un riesgo desproporcionado, y bloquear todo el catálogo por defecto suele empeorar el problema en lugar de resolverlo. Cuando IT prohíbe sin criterio, el empleado que necesita el asistente para su trabajo diario no deja de usarlo, simplemente lo instala desde su cuenta personal, con su Gmail personal, sincronizado en el mismo navegador que usa para el correo corporativo. Eso multiplica el riesgo en vez de eliminarlo, porque ahora el dato sale de un canal que ni siquiera aparece en el admin console de la empresa. Nuestra recomendación en Blurtek no siempre es contratar una auditoría completa o un servicio de monitorización continuo: en buena parte de los casos que revisamos, el problema se resuelve con veinte minutos de configuración en el panel de apps de terceros de Workspace y una política clara de qué scopes están permitidos por defecto. Gobernar con criterio, no prohibir por reflejo, es lo que de verdad reduce la superficie de ataque sin generar más shadow IT del que ya existía.

Si ya tienes extensiones IA instaladas sin control, qué hacer ahora

El primer paso no es desinstalar nada de golpe, porque eso puede romper flujos de trabajo activos y generar resistencia que empuja al usuario de vuelta al shadow IT. Empieza por sacar el listado real de apps de terceros con scopes de Gmail y Calendar desde el admin console de Workspace, y cruzarlo con lo que IT cree que tiene aprobado: la diferencia entre ambas listas es tu mapa de riesgo real. A partir de ahí, prioriza por scope: cualquier cosa con gmail.send, gmail.modify o acceso de escritura a Calendar sin verificación OAuth pasa a revisión inmediata; el resto de solo lectura puede esperar a la siguiente ventana de mantenimiento. Documenta la decisión sobre cada extensión, aunque sea aprobada sin cambios, porque ese registro es lo que te permite responder en minutos la próxima vez que aparezca una extensión nueva con el mismo patrón de permisos.