Dar acceso a un agente a Drive, correo electrónico y GitHub crea un problema diferente al de simplemente conectar tres herramientas. La pregunta es: ¿qué acción puede realizar este agente, sobre qué recurso, en nombre de quién, durante cuánto tiempo y bajo qué condiciones?
La respuesta más útil es no eliminar tantos permisos como para que la automatización deje de funcionar. Está creando un límite de autorización en capas. El conector fija el techo máximo; una política de ejecución reduce este límite para cada tarea; las operaciones de mayor impacto pueden requerir aprobación; y todas las decisiones relevantes son auditables.
Esta separación está en línea con la dirección reciente del NIST. En febrero de 2026, el NCCoE publicó un documento conceptual específico sobre la identidad y autorización de la IA y los agentes de software y abordó la identificación, la autorización, la auditoría y el no repudio como cuestiones en sí mismas. El documento es un borrador conceptual, no un estándar final, pero deja claro que dar herramientas a un agente no resuelve, en sí mismo, el límite de confianza.
El informe del NIST de mayo de 2026 sobre las respuestas a la consulta de seguridad de los agentes también registra un amplio acuerdo entre los participantes en que los principios tradicionales de ciberseguridad siguen siendo relevantes, pero deben adaptarse a los sistemas de agentes.
Para comprender la capa anterior de esta discusión, vale la pena conectar este dibujo con lo que estandariza el formato de Agent Plugins. Un formato puede describir o integrar una herramienta; La autorización todavía tiene que responder quién puede utilizarla, para qué y con qué consecuencias.
El privilegio mínimo no se trata solo de elegir un alcance pequeño
Los alcances de OAuth, los permisos de aplicación y los tokens son controles importantes, pero no necesariamente representan la intención completa de una tarea.
Imagine un agente encargado de analizar un ticket recibido por correo electrónico, consultar un documento técnico en Drive y preparar una solución en un repositorio. La tarea no implica automáticamente que deba leer todo el buzón, abrir todos los archivos de la organización, escribir en cualquier repositorio o enviar un mensaje final sin confirmación.
La autorización debe funcionar en al menos dos niveles.
El primero es el techo estructural: qué capacidades puede recibir la integración de Google o GitHub. Aquí es donde entran en juego los alcances de OAuth, los permisos de la aplicación GitHub y la selección del repositorio.
La segunda es la autorización de tarea: dentro de ese límite, qué recursos y acciones se liberan para esta ejecución específica. Es esta capa la que impide que una credencial técnicamente válida se convierta en una autorización sin restricciones para el modelo.
El principio de privilegio mínimo ya aparece en el catálogo de controles del NIST como AC-6. La misma familia de controles también separa el registro de eventos, el contenido del registro y la generación de auditoría en AU-2, AU-3 y AU-12. Esta división es útil para los agentes: otorgar acceso y poder reconstruir posteriormente cómo se utilizó son problemas relacionados pero distintos.
Dibuje el límite de autorización en siete pasos
1. Dale al agente su propia identidad
No trate al agente simplemente como "el usuario que autorizó OAuth". Registre una carga de trabajo o identidad de aplicación que le permita distinguir al humano que delegó la tarea del software que realizó la acción.
Registrar una operación debe permitir responder, por ejemplo: el usuario A solicitó la tarea, el agente B la ejecutó, la política C la autorizó y se utilizó la credencial D.
Esta separación reduce una ambigüedad peligrosa: una llamada realizada “en nombre del usuario” no significa que cualquier cosa permitida al usuario esté automáticamente autorizada al agente.
2. Establezca el techo más bajo posible en el conector
En Google Drive, la documentación recomienda elegir el alcance más limitado posible. Cuando el flujo permite al usuario seleccionar o compartir archivos específicos con la aplicación, drive.file proporciona acceso por archivo en lugar de otorgar acceso general a Drive. Drive y drive.readonly alcanzan todos los archivos compatibles con el nivel de acceso respectivo.
En Gmail, elija la capacidad que necesita. gmail.send es para enviar; gmail.readonly permite la lectura; gmail.compose te permite gestionar borradores y enviar mensajes; y gmail.modify reúne lectura, escritura y envío. El alcance de mail.google.com es aún más amplio e incluye la eliminación permanente.
En GitHub, las aplicaciones GitHub se inician sin permisos explícitos y la documentación en sí recomienda seleccionar solo los permisos mínimos requeridos. Los permisos se pueden separar por capacidades de repositorio, organización, empresa o cuenta.
3. Reducir nuevamente por tarea
Aquí está la capa que a menudo falta.
Incluso si una integración está autorizada para acceder a diez repositorios, es posible que la tarea actual solo necesite uno. Incluso si el agente tiene gmail.readonly, sólo podrá recibir mensajes previamente seleccionados mediante una búsqueda o regla. Incluso con permiso para escribir en Drive, es posible que la ejecución actual solo necesite leer dos documentos.
Una política de tarea se puede describir como un pequeño sobre de autorización que contiene:
- identidad del usuario que delegó;
- identidad del agente;
- herramienta permitida;
- recursos permitidos, como ID de archivos, mensajes o repositorios;
- operaciones permitidas, como leer, crear borrador o abrir un cambio;
- fecha de vencimiento;
- límites de volumen o cantidad;
- condición de aprobación, cuando corresponda;
- identificador de tarea para auditoría.
Este sobre es una recomendación arquitectónica, no un formato requerido por NIST o proveedores. El objetivo es convertir "el agente tiene acceso a Gmail" en algo operativamente verificable, como "esta tarea puede leer estos mensajes durante esta ejecución".
4. No entregue credenciales duraderas al contexto de la plantilla
Los tokens de actualización, las claves privadas y otros secretos de larga duración deben permanecer en una capa de credenciales o en un intermediario, no en el mensaje, en la memoria textual del agente ni en argumentos que pueda reproducir.
La documentación de Google recomienda el almacenamiento seguro de tokens y autorizaciones incrementales, solicitando nuevos alcances cuando la funcionalidad realmente los necesita, en lugar de solicitar todo en la autenticación inicial.
La autorización incremental mejora el consentimiento y evita solicitar capacidades por adelantado, pero no reemplaza el control por tarea. Una vez que exista una autorización más amplia, la aplicación aún debe decidir qué operaciones puede realizar el agente en ese momento.
En GitHub hay un mecanismo útil adicional: se puede emitir un token de instalación de una aplicación GitHub para repositorios específicos y con un subconjunto de los permisos otorgados a la aplicación. Estos tokens de instalación caducan después de una hora.
5. Lectura separada, preparación y efecto externo
No todas las operaciones merecen la misma autonomía.
Leer un documento seleccionado es diferente a cambiar su contenido. Crear un borrador es diferente a enviar un mensaje. Preparar un cambio de código es diferente a enviarlo a una rama protegida o enviarlo a producción.
Una política práctica puede liberar automáticamente operaciones de bajo impacto y aumentar la demanda a medida que el efecto se vuelve más difícil de revertir.
Esto evita dos extremos: un agente con poder permanente para cualquier operación o un agente que pide confirmación humana después de cada lectura y, por tanto, pierde gran parte de su utilidad.
6. Apruebe la acción arriesgada, no toda la conversación
La aprobación humana funciona mejor cuando está vinculada a la llamada concreta que produce el efecto.
Si la política requiere confirmación antes de enviar un correo electrónico externo, el agente puede investigar el contexto y preparar el borrador sin interrupción. La aprobación aparece solo antes de la operación de envío.
El mismo razonamiento se puede aplicar a las eliminaciones, compartir cambios, publicar, fusionar u otras acciones definidas por la organización como sensibles.
Este detalle es especialmente importante en Gmail. El alcance de gmail.compose, por ejemplo, cubre tanto la gestión como el envío de borradores. Por lo tanto, si la política de la organización quiere "permitir borradores, prohibir el envío automático", el alcance por sí solo no representa este límite: la aplicación debe evitar la llamada de envío en su propia capa de autorización.
7. Registre la decisión, no solo el resultado final
Guardar solo la respuesta textual del agente no es suficiente para investigar una acción.
El registro debe permitir reconstruir la ruta de autorización: qué identidad se realizó, qué usuario delegó, qué herramienta se llamó, qué recurso se vio afectado, qué operación se solicitó, qué política se decidió, si se dio la aprobación y cuál fue el resultado.
Los controles de auditoría del NIST distinguen el registro de eventos, el contenido de los registros y la generación de esos registros; El documento conceptual sobre agentes de 2026 también destaca la auditoría entre las cuestiones específicas que deben abordarse para los agentes de software y la IA.
El registro no debe almacenar el secreto utilizado en la llamada. Lo que importa es una referencia segura a la credencial o sesión, suficiente para rastrear el evento sin convertir el sistema de auditoría en otro repositorio de credenciales.
Drive, correo electrónico y GitHub requieren controles diferentes
| Integración | Privilegio menos útil | Donde ayuda el control nativo | Donde una política adicional marca la diferencia |
|---|---|---|---|
| Google Drive | Prefiere archivos específicos cuando el flujo lo permita | drive.file puede limitar el acceso a los archivos utilizados o compartidos con la aplicación | Restringir ID, carpetas, operaciones de escritura, uso compartido y eliminación por tarea |
| Gmail | Elige alcance según lectura, envío o redacción | Existen diferentes ámbitos para enviar, leer, componer, modificar y metadatos | Limita los mensajes que entran en la tarea y bloquea los puntos finales de efectos, como el envío, cuando sea necesario |
| GitHub | Aplicación GitHub con permisos mínimos y solo repositorios requeridos | Las instalaciones y los tokens pueden restringirse mediante repositorio y permisos | Limitar rama, operación, número de cambios, flujo de trabajo y acciones que requieren aprobación |
