Agentes personales de código abierto ya acceden a redes corporativas; control por identidad

Menos de un año después de que aparecieran los primeros agentes personales de código abierto, el debate se ha desplazado del «si» al «cómo» controlar su presencia dentro de redes corporativas. Hechos confirmados en el terreno: estos agentes —tanto los que corren en la nube del proveedor como los que se ejecutan en el equipo del usuario— ya acceden a sistemas corporativos por los mismos canales que otras aplicaciones: consentimiento OAuth, credenciales guardadas en navegadores, claves API y tokens personales, o acceso directo desde un endpoint con software local. Lo que cambia es la entidad que actúa en nombre del empleado: no es sólo un dispositivo o una app, sino un agente autónomo que puede orquestar acciones amplias usando la identidad del trabajador.

Técnicamente, hay cuatro vectores principales por los que un agente personal puede entrar en un entorno corporativo, y cada uno exige controles distintos. Primero, el flujo OAuth: el agente solicita permisos a Google Workspace, Microsoft 365, Slack u otros, y el usuario concede el acceso con un clic; desde la perspectiva del servicio, parece la misma sesión del empleado. Segundo, la automatización del navegador y los gestores de contraseña integrados permiten a un agente “firmarse” en un servicio como si fuera el humano. Tercero, las integraciones no oficiales pueden operar con API keys o tokens de larga duración que el usuario crea y mantiene; esos credenciales sobreviven incluso si el usuario cambia de rol. Cuarto, los agentes locales instalados en el laptop del empleado o en servidores personales leen archivos, correos y calendarios directamente si se les concede permiso.

Consecuencia directa: un agente personal hereda los permisos del usuario, y a menudo solicita mucho menos acceso del que realmente necesita para funcionar. El riesgo es doble: exposición accidental de datos sensibles y persistencia de accesos tras el fin de la relación laboral. Además, la arquitectura del proveedor puede complicar la tarea: algunos proveedores ejecutan el agente en una VM propia que mantiene tokens y aplica políticas del usuario, no las de la empresa, lo que traslada sesiones y credenciales a infraestructuras ajenas.

¿A quién afecta esto? A toda la cadena: empleados que usan agentes para mejorar productividad (desde desarrolladores hasta personal de ventas), equipos de TI y seguridad que deben proteger identidades y datos, y a menudo a terceros (clientes o proveedores) si la información de la empresa se comparte inadvertidamente. Para las organizaciones reguladas, el riesgo de incumplimiento aumenta cuando las concesiones OAuth o los tokens quedan fuera del control de la empresa.

Qué es seguro dar por confirmado y qué no: está confirmado que los agentes usan los mecanismos habituales de autenticación y que existen ejemplos de agentes integrándose con servicios corporativos. También está constatado que muchos proveedores trabajan en controles para despliegues gestionados. Es una estimación —no una certeza absoluta— que la mayoría de empresas ya tienen agentes personales conectados sin supervisión. Lo incierto es la magnitud exacta del acceso no supervisado en cada organización y cómo evolucionarán las capacidades de atribución y offboarding a corto plazo.

Desde una perspectiva práctica, la identificación de la identidad como plano de control es la estrategia más efectiva. En lugar de intentar bloquear todas las variantes —un juego de Whac-A-Mole que perderá siempre—, conviene asumir que los agentes aparecerán y diseñar controles en el perímetro que de verdad importan: las identidades, los tokens y las sesiones. Esto incluye detección, atribución, limitación de privilegios y procesos de revocación fiables.

Medidas concretas y accionables que un responsable de seguridad debería implementar de inmediato: primero, inventariar los accesos de terceros y las concesiones OAuth en sus tenants (Google y Microsoft ofrecen controles administrativos para listar aplicaciones con acceso a datos; véase la documentación de Google Workspace y la guía de consentimiento de Azure AD). Segundo, forzar que solamente las aplicaciones aprobadas requieran permisos por medio de políticas de consentimiento centralizado o bloqueo de consentimiento de usuario. Tercero, eliminar o rotar los tokens de larga duración y migrar a flujos de autenticación que usen tokens de corta vida y autorización delegada con scopes mínimos. Cuarto, extender las políticas de offboarding para incluir revocación automatizada de concesiones OAuth, cierre de sesiones activas y borrado de claves asociadas al empleado. Quinto, instrumentar detección en endpoints y redes: EDR/SIEM y soluciones CASB o DLP deben alertar sobre patrones típicos de agentes (inicios de sesión desde rangos de IP del proveedor, creación súbita de API keys, uso inusual de cuentas de servicio).

Dos medidas técnicas de alto impacto que exigen poca infraestructura nueva: habilitar el consentimiento administrativo para apps (prohibir que los usuarios otorguen permisos por sí solos) y aplicar políticas de acceso condicionado basadas en riesgo para toda autentificación que implique permisos ampliados. Ambas reducen ataques por abuso de tokens y mitigarán el problema de sesiones que actúan como empleados sin supervisión.

No todo está resuelto hoy: quedan retos abiertos como distinguir con alta certeza si una autenticación proviene del humano o de su agente cuando ambos comparten credenciales, y cómo garantizar que el “conocimiento” que un agente acumula se borre durante el offboarding. También faltan estándares amplios de interoperabilidad para que un administrador pueda ver «este agente pertenece a esta persona» sin romper la privacidad del proveedor ni del usuario. Mientras esas capacidades maduran, la combinación de gobernanza de identidad, detección especializada y procesos operativos robustos es la mejor defensa.

Recursos prácticos y de referencia que conviene leer y aplicar: la guía de control de apps en Google Workspace (https://support.google.com/a/answer/7281227) y la documentación de Microsoft sobre consentimiento y permisos en Azure AD (https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/consent). Para principios técnicos sobre OAuth y mejores prácticas de seguridad, la colección de OWASP es útil como checklist operativo (https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html).

En resumen: bloquear por principio a los agentes personales es una opción políticamente tentadora pero poco práctica. La estrategia más realista y efectiva es tratar al agente como una entidad externa y controlar su alcance a través de la identidad: inventario y atribución, principio de menor privilegio, revocación automática en el offboarding y detección proactiva en tokens y sesiones. Quien implemente estas medidas no eliminará el riesgo por completo, pero sí reducirá de forma apreciable la probabilidad y el impacto de filtraciones y abusos provocados por agentes que actúan con identidades de empleados.