Agent Auth: El problema que mata a los agentes en producción

Tu agente necesita obtener datos de Google Drive, publicar un resumen en Slack y crear un ticket en Jira. Solicitud simple. ¿Pero con qué credenciales lo hace? ¿Debería tener permiso para borrar toda tu carpeta de Drive?

Este problema de autorización mata los demos de agentes antes de llegar a producción. No se trata de que los usuarios entren a tu agente (LangGraph Platform se encarga de eso). Se trata de que tu agente acceda a otros servicios en nombre de esos usuarios.

Si estás construyendo agentes reales, ya chocaste contra esta pared. La pregunta no es “Quiénes este agente”. Es: “¿Puede este agente, actuando por este usuario, ejecutar esta acción sobre este recurso?”

Esta complejidad de autorización es exactamente por qué construimos Arcade.dev. Pero primero, entendamos el panorama completo.

Auth de usuario vs. auth de agente: dos problemas distintos

Antes de entrar al auth de agentes, aclaremos los dos retos:

Autenticación de usuarios (gestionada por LangGraph Platform) Aquí los usuarios demuestran quiénes son para acceder a tu agente. LangGraph Platform lo maneja bien.

# LangGraph Platform verifies user identity
@auth.authenticate
async def authenticate(headers: dict) -> Auth.types.MinimalUserDict:
    api_key = headers.get("x-api-key")
    if not is_valid_key(api_key):
        raise Auth.exceptions.HTTPException(status_code=401)

    return {
        "identity": "user-123",        # Who is this user?
        "is_authenticated": True       # Are they allowed in?
    }

Una vez autenticados, los usuarios pueden crear hilos, ejecutar agentes y acceder a recursos del agente. LangGraph Platform administra todo esto y pone la identidad del usuario disponible en tu agente mediante config[“configuration”][“langgraph_auth_user”].

Autorización del agente (gestionada por Arcade) Aquí es donde se complica. Tu usuario autenticado le pide al agente que “resuma las llamadas de ventas de la semana pasada desde Google Drive y las publique en #sales-team en Slack.” Ahora tu agente necesita:

Conectarse a Google Drive (¿con qué credenciales?)
Conectarse a Slack (¿con qué permisos?)
Hacerlo de forma segura (sin acceso a todo)
En nombre del usuario autenticado
Sin crear brechas de seguridad

Eso es el auth de agentes. Es un problema completamente distinto.

Por qué “Identidad No Humana” se queda corto

A los vendors de seguridad les encantan los buzzwords. “Identidad No Humana” (NHI) es el más reciente. La realidad es: los agentes no son identidades, son aplicaciones que actúan en nombre de usuarios.

Tu agente es una aplicación cliente que necesita acceso delegado. Necesita acceder a servicios no como un nuevo tipo especial de identidad, sino como una aplicación que actúa por un usuario específico. Estos patrones existen desde hace casi dos décadas en OAuth.

El reto no es que los agentes sean especiales. Es que la complejidad de autorización explota cuando los agentes acceden a múltiples servicios de forma dinámica.

Recuerda la pregunta real: “¿Puede este agente, actuando por este usuario, ejecutar esta acción sobre este recurso?”

Por qué importa el auth de agentes en la capa de herramientas

Cuando tu agente llama a una herramienta, ahí es donde la seguridad realmente importa. No puedes confiar en el criterio del agente sobre qué debería o no debería poder hacer. La verificación de autorización tiene que ocurrir en el momento de la acción, con contexto sobre:

Qué agente hace la solicitud
En nombre de qué usuario (desde LangGraph Platform)
Qué acción específica intenta ejecutar
Sobre qué recurso exacto
Con qué parámetros

Las reglas para “¿puede este agente enviar este mensaje de Slack?” son distintas de las de “¿puede este agente borrar este archivo de Drive?”. Por eso el auth de agentes está estrechamente ligado a la ejecución de herramientas (donde ocurre la acción).

Los dos enfoques ingenuos (y por qué fallan)

La mayoría de los equipos empieza con uno de estos dos enfoques defectuosos:

Enfoque 1: Cuentas de servicio

“¡Creemos una cuenta de servicio para nuestro agente con sus propios permisos!”

Parece lógico, especialmente para sistemas RAG. Tu agente necesita documentos de la empresa, así que creas una cuenta de servicio con acceso de lectura a la base de conocimiento. Sencillo, ¿no?

Las cuentas de servicio funcionan bien para procesos en background, pero se usan en exceso en el desarrollo de agentes porque los desarrolladores no tenían mejores alternativas.

Las cuentas de servicio crean vulnerabilidades de bypass. Imagina que tu empresa tiene acceso basado en roles a documentos. RR.HH. ve datos de salarios, ingeniería ve docs técnicos, ventas ve datos de clientes. Pero tu agente RAG con su cuenta de servicio puede ver todo lo que le dieron acceso. Así, cualquier usuario puede preguntarle al agente sobre cualquier documento, saltándose por completo los controles de acceso existentes.

Esta es una razón común por la que los agentes con demos increíbles no llegan a producción: los equipos de seguridad (con razón) los frenan cuando detectan el riesgo de bypass.

¿La alternativa? Agentes muy limitados. Si restringes las cuentas de servicio a información pública, tu agente se convierte en documentación glorificada. Puede recitar tu FAQ pero falla cuando alguien pregunta “¿Cuál es el estado de mi pedido?”, una pregunta útil que los usuarios sí les importa.

Enfoque 2: Permisos completos del usuario

“Bueno, ¡usemos las credenciales y permisos del propio usuario!”

En teoría es más seguro: los usuarios solo acceden a lo que ya tienen permiso de ver. Pero en la práctica es increíblemente peligroso.

Vi cómo Cursor intentó borrar mi directorio raíz. Por suerte, no tenía acceso sudo. ¿Pero quieres que tu agente tenga acceso completo a tu correo? ¿A todo tu Drive? ¿A tu base de datos de producción?

Puede que los usuarios tengan permiso para borrar archivos críticos o enviar correos a toda la empresa. Eso no significa que su agente deba heredar esos permisos sin restricciones. Una alucinación o una inyección de prompt bastan para el desastre; los equipos de seguridad llaman a esto el “radio de explosión”.

La solución correcta: autorización justo a tiempo con mínimos privilegios

La solución requiere tres principios clave:

1. Autorización justo a tiempo: No preautorices todo. Cuando el agente necesita acceso a Slack, ese es el momento de gestionar el flujo OAuth. Los usuarios mantienen el control y autorizan solo lo necesario, cuando es necesario.

2. Acceso con mínimos privilegios: Aunque un usuario pueda borrar archivos en Drive, su agente solo debe obtener acceso de lectura a menos que borrar sea explícitamente necesario. Esto reduce el radio de explosión si algo sale mal. Define los alcances mínimos requeridos para cada herramienta.

3. Aplicación contextual: Cada llamada a una herramienta necesita verificaciones de autorización. ¿Puede este agente específico, actuando por este usuario específico, ejecutar esta acción específica? La respuesta cambia según el contexto.

Complejidad en el mundo real

Lo que esto significa en la práctica:

Gestión de tokens: Los tokens OAuth expiran y necesitan renovarse. Cada servicio tiene tiempos de vida distintos. Tu agente puede estar en medio de una conversación cuando un token expira. Tienes que manejar los flujos de renovación sin romper la experiencia del usuario.

Problemas de escala: Necesitas tokens separados para cada combinación de usuario × servicio × agente. El Usuario A usando tu agente de ventas para acceder a Slack necesita un token distinto al del Usuario A usando tu agente de soporte. Escala esto a 100 usuarios, 10 servicios y 5 agentes, y estás gestionando 5,000 relaciones de tokens distintas.

Autorización dinámica de herramientas: No obligues a los usuarios a preautorizar todos los servicios de entrada; abandonarán el flujo después de 2 o 3 pasos de auth. Mejor gestiona OAuth justo a tiempo dentro del loop de tu agente. ¿El usuario pregunta por datos de ventas? Ese es el momento de solicitar acceso a Salesforce.

Granularidad de alcances: Solo Slack tiene decenas de alcances OAuth. ¿Tu agente necesita chat:write o chat:write.public? ¿Qué hay de files:read vs files:write? Si te equivocas, tu agente o no funciona o tiene demasiado poder.

Cómo pueden resolver esto los desarrolladores de LangGraph

Entraste al desarrollo de agentes para construir flujos de trabajo inteligentes, no para gestionar tokens OAuth. El ecosistema de LangChain te da casi todo lo que necesitas: LangGraph para la orquestación de agentes, LangGraph Platform para hospedaje y escalado, LangSmith para observabilidad.

Pero hay un hueco: la capa de autorización de herramientas.

Para llenarlo, tendrías que construir flujos OAuth para cada servicio (cada uno con sus peculiaridades a pesar de que OAuth sea un “estándar”). Gestión de tokens entre usuarios y servicios. Políticas de autorización. Lógica de renovación. Controles de seguridad.

Muchos equipos empiezan por este camino. Meses después, siguen depurando casos extremos de OAuth en lugar de lanzar agentes.

O puedes usar Arcade.

La realidad de la implementación

Para implementar por tu cuenta la autorización justo a tiempo correctamente, necesitarías construir:

Gestión del flujo OAuth (inicio, callbacks, manejo de estado)
Gestión del ciclo de vida de tokens entre combinaciones usuario/agente/servicio
Aplicación de políticas de autorización en la capa de herramientas
Lógica de renovación de tokens que no interrumpa la ejecución del agente
Manejo de errores para tokens expirados o revocados
Registros de auditoría para cumplimiento

Eso son miles de líneas de código de infraestructura compleja antes de siquiera llegar a tu lógica de agente.

Así se ve la misma funcionalidad con Arcade:

# Get the authenticated user from LangGraph Platform
user_id = config["configuration"]["langgraph_auth_user"]["identity"]

# All the complexity above, handled by Arcade
result = arcade_client.tools.execute(
    tool_name="Slack.SendMessage",
    input={
        "channel": "#general",
        "message": "Hello World!"
    },
    user_id=user_id  # Who the agent is acting for
)

Lo que ocurre detrás de escena:

LangGraph Platformya autenticó al usuario
Tu agente envía la solicitud a Arcade
Arcade verifica si tu agente tiene tokens OAuth válidos de Slack para este usuario
Si no, Arcade inicia el flujo OAuth (dentro del loop de tu agente)
Tu agente se autentica en Slack con alcances limitados
Arcade ejecuta la acción con la autorización y el registro adecuados
Arcade gestiona estos tokens para usos futuros

Puedes usar herramientas preconstruidas de nuestra librería o crear las tuyas con nuestro Tool Development Kit. Tú configuras las herramientas. Arcade garantiza el acceso con mínimos privilegios. Tus usuarios mantienen el control. Tu agente sigue funcionando. Tu equipo de seguridad queda tranquilo.

Todo diseñado para funcionar sin fricciones con todo el ecosistema de LangChain.

La conclusión

El auth de agentes trata sobre cómo tu agente accede a otros servicios en nombre de los usuarios. Se relaciona con el auth de usuarios, pero es distinto: el auth de usuarios se enfoca en cómo los usuarios acceden al agente.

Los enfoques ingenuos (cuentas de servicio y credenciales completas del usuario) crean vulnerabilidades de seguridad o brechas de protección. El enfoque correcto usa autenticación de agentes basada en OAuth con acceso justo a tiempo y mínimos privilegios.

Arcade y LangGraph Platform gestionan esta complejidad por los desarrolladores, permitiendo que tus agentes LangGraph accedan de forma segura a servicios internos y externos mientras los usuarios autenticados mantienen el control.

Empieza a construir agentes seguros hoy

Tu siguiente paso: Agrega acceso externo seguro a tu agente LangGraph en menos de 10 minutos.

Parte de tu agente LangGraph existente (con el auth de usuario de LangGraph Platform ya configurado)
Regístrate en Arcade en arcade.dev sin tarjeta de crédito
Sigue nuestra guía de integración con LangGraph para agregar Arcade a tu agente
Agrega tu primera herramienta (recomendamos empezar con Slack o Google Drive)
Prueba el flujo OAuth observa cómo tu agente se autentica correctamente en servicios externos