Para que una automatización tenga solo el acceso que necesita, asígnale una identidad propia, limita esa identidad a los datos y operaciones indispensables y separa la lectura de cualquier permiso para modificar. Los permisos OAuth no son una casilla técnica que se marca una vez: definen qué puede tocar el sistema y cuánto daño podría causar un error o una credencial expuesta.
Una identidad por automatización, no una cuenta compartida
Una identidad de servicio es la credencial que permite a un proceso actuar ante una aplicación. No debería ser la cuenta personal del dueño ni una credencial compartida por varios flujos. Si tres automatizaciones usan el mismo usuario con acceso amplio, será más difícil saber cuál hizo un cambio, retirar solo el acceso de una tarea o evitar que una falle y afecte a las demás.
Hecho: Google recomienda crear cuentas de servicio de propósito único. Explica que compartir una identidad entre aplicaciones mezcla sus ciclos de vida, puede hacer crecer los accesos concedidos y dificulta atribuir actividad en los registros. Google Cloud, “Best practices for using service accounts securely”, actualización 30 de septiembre de 2026, https://docs.cloud.google.com/iam/docs/best-practices-service-accounts.
Recomendación práctica: registra cada identidad con el nombre del flujo, su propósito y una persona responsable de revisarla. Separa además pruebas y producción; una automatización en pruebas no necesita por defecto los datos reales ni las facultades del proceso activo. Si el flujo deja de usarse, desactiva su credencial y confirma que no interrumpa otra tarea antes de eliminarla.
OAuth: pide el alcance mínimo y comprueba lo concedido
OAuth permite autorizar a una aplicación para acceder a un servicio. El “ámbito” o scope, cuando el proveedor lo implementa, expresa categorías de acceso, como consultar información o modificarla, pero los nombres y la granularidad cambian según cada proveedor. No asumas que “conectar la cuenta” equivale a un permiso pequeño: algunos ámbitos agrupan muchas facultades.
Hecho: la guía oficial de GitHub dice que los scopes limitan el acceso de los tokens OAuth y no amplían los permisos que ya tiene la persona. También muestra un contraste práctico: el scope “repo” incluye lectura y escritura en repositorios públicos y privados, mientras “repo:status” limita el acceso a estados de commits sin dar acceso al código. GitHub Docs, “Scopes for OAuth apps”, sin fecha; consultada 2026-10-03, https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps.
Interpretación: pedir un scope amplio por comodidad puede exponer más de lo que requiere una tarea. Antes de autorizar, compara la descripción exacta del proveedor con las acciones del flujo. Luego comprueba qué permisos fueron concedidos realmente; no diseñes el proceso suponiendo que el usuario aceptó todos los scopes solicitados. Si el proveedor no ofrece una opción de solo lectura adecuada, limita el recurso en la aplicación o reconsidera la conexión.
La norma de buenas prácticas de OAuth recomienda que los privilegios de los tokens se restrinjan al mínimo necesario y que, cuando sea posible, se limite también el servidor de recursos al que sirven. IETF, RFC 9700, “Best Current Practice for OAuth 2.0 Security”, enero de 2025, https://www.rfc-editor.org/rfc/rfc9700.html. Esa restricción reduce el alcance potencial de una credencial filtrada; no convierte un token en inocuo ni sustituye el control de acceso del servicio.
Diseña lectura y escritura como capacidades distintas
Empieza describiendo qué debe hacer el proceso, no qué permisos ofrece el conector. Por ejemplo hipotético: una pyme de servicios quiere que una automatización lea solicitudes de mantenimiento y prepare una nota para el encargado. Para reunir contexto, quizá necesite leer solo los tickets de una sede; no necesita borrar solicitudes, administrar usuarios ni cambiar la configuración de toda la cuenta.
Recomendación práctica: divide el trabajo en dos identidades si existe una acción de escritura. La primera puede consultar los campos indispensables. La segunda, más restringida, solo crea una nota o borrador en el destino definido. Si la tarea únicamente analiza información, no concedas escritura “por si acaso”. Si necesita guardar un resultado, evita que pueda alterar o eliminar el registro original.
Esto no significa que cada empresa tenga que crear dos cuentas en todos los productos. Algunas plataformas ofrecen roles, ámbitos separados o límites por recurso; otras agrupan funciones. El diseño debe ajustarse a lo que el proveedor realmente permite. Si no se puede aislar una acción de riesgo, documenta esa limitación y reduce los datos, recursos o procesos conectados en vez de presentar el acceso amplio como mínimo.
Prueba el límite, registra y revisa
Una configuración mínima se comprueba intentando hacer lo que el proceso no debería poder hacer. Con la identidad de lectura, intenta modificar un dato de prueba y confirma que el servicio lo rechaza. Con la identidad de escritura, prueba un recurso fuera del ámbito permitido. Revisa también qué aparece en el registro de actividad y si la acción se atribuye a la automatización correcta.
Google recomienda identidades de servicio dedicadas y advierte que, si varias aplicaciones comparten una, los registros pueden no revelar cuál aplicación la utilizó. Para ciertas arquitecturas, también describe el uso de credenciales de corta duración y tokens con alcance reducido. Google Cloud, “Best practices for using service accounts securely”, actualización 30 de septiembre de 2026, https://docs.cloud.google.com/iam/docs/best-practices-service-accounts. En una pyme, la recomendación práctica es revisar permisos cuando cambia el flujo, el proveedor o la persona responsable, y retirar los que ya no hagan falta.
El primer paso concreto es elegir una automatización y anotar, en una sola hoja, su identidad, los datos que consulta, cada cambio que puede realizar, el scope solicitado y quién revisa la credencial. Después elimina cualquier permiso que no puedas justificar con una acción específica y prueba que lectura y escritura respeten sus límites. Para una explicación introductoria sobre agentes, Jarvis ya publicó: https://www.jarvisrd.com.do/blog/que-es-un-agente-de-ia.