SSO para agentes de AI: autenticación y autorización

Los agentes de AI frecuentemente necesitan acceder a múltiples servicios y fuentes de datos en nombre de los usuarios. Esto genera desafíos únicos de autenticación y autorización que van más allá del single sign-on (SSO) típico para usuarios humanos. A diferencia de una app web estándar, un agente de AI puede operar sin interfaz de usuario e incluso tomar decisiones de forma autónoma. Para mantener estos agentes seguros y efectivos, hay que aplicar buenas prácticas como el acceso de mínimos privilegios y la autenticación justo a tiempo, y entender dónde los flujos de autenticación tradicionales se quedan cortos.

Esta guía explica cómo manejar SSO para agentes de AI de forma segura. Cubrimos por qué debes minimizar los permisos de un agente, cómo gestionar la autorización del usuario solo cuando se necesita, y por qué el modelo de AI no debe participar en procesos de seguridad sensibles. También destacamos las limitaciones de los flujos OAuth/SAML actuales para casos de uso con agentes y explicamos por qué automatizar un navegador para la autenticación no es una solución sólida. Por último, mostramos cómo nuevas soluciones como Arcade.dev) pueden simplificar la autenticación para agentes de AI respetando estos principios de seguridad.

Mínimos privilegios para agentes de AI

Los agentes de AI deben seguir un modelo estricto de mínimos privilegios : solo darles los permisos mínimos necesarios para cada tarea. Darle a un agente acceso amplio “por si acaso” es peligroso. Si el agente malinterpreta instrucciones o se ve comprometido, cualquier privilegio extra puede causar daños graves. No puedes confiar completamente en que una AI siempre tome decisiones seguras, así que hay que limitar lo que puede hacer.

Scopes OAuth del usuario: Cuando un agente se autentica como usuario vía OAuth, solicita solo los scopes que realmente necesita (por ejemplo, acceso de solo lectura si únicamente necesita obtener datos). Los scopes OAuth granulares son ideales para esto, ya que permiten un control preciso sobre lo que el agente puede hacer (AI agent identity: it’s just OAuth). Por ejemplo, un bot que organiza correos podría tener permiso para leer correos, pero no para eliminarlos.
Permisos de cuenta de servicio: Si el agente usa su propia cuenta de servicio o clave de API, dale a esa cuenta permisos bien delimitados. Crea roles dedicados para el agente que restrinjan las acciones al mínimo indispensable (por ejemplo, un agente de limpieza en la nube solo accede a buckets de almacenamiento específicos, no a toda la cuenta).
No determinismo del LLM: Como el modelo de AI subyacente puede comportarse de forma impredecible, es riesgoso darle derechos de administrador amplios. Por ejemplo, un agente de gestión de archivos con acceso irrestricto al sistema de archivos intentó eliminar el directorio raíz completo por error, una acción catastrófica que habría sido imposible si solo tuviera permisos de lectura. Este incidente real ilustra por qué incluso los agentes “inteligentes” deben mantenerse con privilegios muy acotados.

Autenticación justo a tiempo (buena práctica)

Otra buena práctica es usar autenticación justo a tiempo (JIT) para las integraciones de agentes de AI. A diferencia de una app tradicional donde conectas todos los servicios por adelantado, un agente de AI puede solicitar acceso de forma dinámica cuando surgen nuevas necesidades. No debes obligar a los usuarios a pre-autorizar todas las integraciones posibles durante el onboarding. El agente debe pedir autenticación solo cuando el usuario realmente intente usar ese servicio.

Este enfoque bajo demanda mantiene la experiencia de usuario fluida y segura:

Mínima fricción inicial: Los usuarios pueden empezar a usar el agente sin tener que conectar cuentas que quizás nunca utilicen.
Sincronizado con la necesidad real: El agente pide credenciales o consentimiento OAuth exactamente cuando el usuario solicita una acción que lo requiere. Por ejemplo, si el usuario le pide al agente que reserve un vuelo en Delta, el agente le pedirá que entre a su cuenta de Delta. (De forma similar, solo pediría el acceso a Marriott cuando el usuario decida reservar un hotel Marriott.)
Menor exposición de credenciales: Al no almacenar tokens de servicios que no se usan, reduces la superficie de ataque. Si el usuario nunca usa la integración con Hilton, nunca se obtienen ni almacenan credenciales o tokens de Hilton.

En resumen, los agentes de AI deben ampliar su acceso autenticado justo a tiempo según las solicitudes del usuario, en lugar de asumir todo por adelantado. Así los usuarios no cargan con permisos que quizás no necesiten, y las credenciales solo se manejan cuando es necesario.

Los LLMs no pueden procesar flujos de seguridad

Aislar los flujos de autenticación del modelo de AI es fundamental. Los modelos de lenguaje grande (LLMs) nunca deben manejar procesos de login ni estar expuestos a credenciales sin procesar. El “cerebro” de un agente de AI puede ser hábil con el lenguaje, pero no es un actor seguro y puede manejar mal información sensible con facilidad. Los desarrolladores deben diseñar los sistemas para que todo el manejo de credenciales y los pasos de seguridad ocurran fuera del LLM.

Dejar que un LLM gestione la autenticación genera riesgos serios:

Filtración accidental de credenciales: El modelo podría exponer una contraseña o token sin querer en una respuesta o en un log. (Se sabe que los LLMs integrados en aplicaciones han expuesto datos sensibles a través de sus salidas (LLM02:2025 Sensitive Information Disclosure - OWASP Top 10 for LLM & Generative AI Security.).)
Pasos de autenticación mal interpretados: Un LLM podría no seguir de forma confiable un flujo de autenticación de varios pasos. Por ejemplo, podría confundirse con un aviso de autenticación de dos factores o con un paso de redirección web y no completar el login correctamente.
Vulnerabilidad a phishing: La AI no puede realmente entender si una página de login es falsa o maliciosa. Podría entregar credenciales a una página de phishing porque no tiene el criterio que tiene un usuario humano.
Reutilización no autorizada de tokens: Si el modelo de alguna manera obtiene un token de sesión o cookie, podría usarlo de formas no previstas o exponerlo en otro lugar, ya que no sabe inherentemente qué usos son permitidos o seguros.

En la práctica, esto significa que cualquier intercambio OAuth, respuesta SAML, clave de API o contraseña de usuario debe ser manejado por lógica de backend segura o un componente de UI dedicado, no por el LLM. El agente de AI puede ser notificado después de que “la autenticación fue exitosa”, pero el intercambio de seguridad real debe ocurrir de forma controlada y determinista, de una manera que el LLM no pueda alterar ni ver. Esta separación garantiza que inyecciones de prompt o fallas en la AI no comprometan las credenciales ni la integridad del flujo de autenticación.

Los flujos de autenticación no fueron diseñados para agentes de AI

Los protocolos de identidad modernos como OAuth 2.0 y SAML fueron construidos originalmente pensando en apps web y móviles, no en agentes autónomos. Estos flujos asumen que hay un usuario humano presente para hacer clic en un botón de login, otorgar consentimiento y completar solicitudes de múltiples factores. Un agente de AI frecuentemente corre sin interfaz gráfica (headless), como cuando ejecuta Claude Code Routines, o en un entorno de servidor backend, lo que hace que el proceso estándar de OAuth de “redirigir al navegador para login” sea complicado de implementar. Los desarrolladores a menudo luchan por encajar OAuth en el modelo de un sistema de agentes.

Sin embargo, para integrarse con servicios populares no hay forma de evitarlo: servicios como Google (Gmail), Microsoft (Outlook), Slack, Salesforce y otros requieren OAuth o SSO para acceso a la API. El resultado es un desafío clave para los desarrolladores de agentes: cómo iniciar y completar estos flujos de autenticación en un entorno backend o CLI. Los workarounds comunes incluyen usar códigos de dispositivo OAuth (donde el agente proporciona un link o código para que el usuario autorice desde otro dispositivo) o pre-generar tokens para el agente, pero todo esto añade fricción y complejidad.

El problema central es que los flujos de identidad asumen una sesión impulsada por el usuario. Los agentes de AI invierten ese modelo: el “usuario” (el agente) es un programa que actúa en nombre de alguien. Como lo expresó un experto en seguridad, los marcos de identidad actuales nunca fueron diseñados para agentes autónomos, y “las grietas están empezando a notarse.”(Agentic AI and Authentication: Exploring Some Unanswered Questions - Spherical Cow Consulting) Hasta que los estándares evolucionen, los desarrolladores deben cubrir esta brecha con soluciones personalizadas o herramientas que puedan manejar OAuth en nombre de un agente.

Problemas con agentes basados en navegador

Un enfoque ingenuo para la autenticación de agentes es automatizar un navegador web (o un navegador headless) para simular un usuario que entra a su cuenta. Esto puede funcionar en casos simples, pero en general es una estrategia débil y frágil. Los agentes basados en navegador tienen poco control sobre el flujo de autenticación más allá de lo que ve un usuario normal, y se topan con numerosos obstáculos:

Redirecciones y callbacks de OAuth: Un navegador automatizado puede cargar la página de login, pero capturar el token resultante desde una redirección OAuth (la URL de callback) es complicado sin un servidor backend real que lo reciba. No es una solución limpia para obtener tokens.
Medidas de detección de bots: Muchos servicios usan CAPTCHAs, scripts de detección de bots, límites de tasa por IP y otras técnicas para bloquear logins automatizados. Es probable que un agente headless sea detectado o bloqueado por estas defensas.
Poco confiable y difícil de mantener: Las páginas web y los flujos cambian con frecuencia. Un script que navega un formulario de login puede fallar cada vez que la UI o el flujo se actualicen. Depender del scraping de una interfaz web para autenticación es frágil. Además, suele violar los términos de servicio y no es escalable ni seguro para uso en producción.

En resumen, los agentes de AI necesitan integraciones nativas de API, no automatización chapucera de navegadores. Siempre que sea posible, usa APIs oficiales y flujos de autenticación estándar (OAuth, claves de API, etc.) mediante código, en lugar de intentar simular un login web. Es más robusto y evita la carrera armamentista de esquivar medidas anti-bot. El objetivo es que el agente interactúe con los servicios como un cliente legítimo de la API, no como un navegador con scripts.

Conclusión

Construir SSO y autenticación para agentes de AI tiene muchos obstáculos, pero están surgiendo soluciones para manejar esta complejidad. Arcade.dev es una plataforma que enfrenta estos desafíos de frente.

En resumen, Arcade.dev ofrece:

Flujos OAuth y de seguridad gestionados: Arcade maneja todo el intercambio OAuth y otros pasos de autenticación por ti, para que no tengas que escribir código de autenticación personalizado desde cero para cada servicio.
Autenticación justo a tiempo: Permite que los agentes soliciten autorización del usuario solo en el momento en que se necesita, en lugar de requerir que todas las integraciones sean pre-autorizadas por adelantado.
Diseño seguro para LLMs: El modelo de AI nunca ve ni procesa credenciales cuando usa Arcade. Todos los tokens y secretos sensibles se mantienen lejos del LLM, manteniendo los flujos de autenticación seguros.
Soporte para agentes sin navegador: Arcade facilita que un agente de AI backend o headless se autentique ante servicios como Gmail, Slack, Salesforce y otros que esperan OAuth. Cubre la brecha para agentes que no tienen navegador ni frontend tradicional.
Integraciones nativas de API (sin scraping): Usar Arcade significa que no necesitas depender de la frágil automatización de navegadores. El agente se conecta directamente a las APIs del servicio con autenticación correcta, lo que te permite evitar CAPTCHAs y obstáculos anti-bot por completo.

Al incorporar estas prácticas y herramientas, puedes empoderar a tus agentes de AI de forma segura para que actúen en nombre de los usuarios sin comprometer la seguridad ni la experiencia de usuario. Aprende más sobre cómo Arcade ayuda con SSO para agentes de AI o regístrate para obtener una cuenta gratis.