TL;DR: autenticación y autorización de agentes de AI multiusuario en 2026
Llevar agentes de AI de demos de escritorio para un solo usuario a producción empresarial implica resolver un problema de ingeniería brutal: autorización delegada con múltiples usuarios y múltiples sistemas.
Los arquitectos de seguridad e ingenieros líderes de AI ya trabajan con agentes que ejecutan flujos de trabajo complejos sobre infraestructura crítica en nombre de miles de usuarios concurrentes.
El principio de diseño central no es negociable: trata cada acción del agente como acceso delegado del usuario, nunca como acceso propio del agente. Toda la pila de autorización se deriva de esa distinción. Nueve capacidades, dos identidades, una regla de intersección estricta.
Esta guía explica cómo combinar OpenID Connect, OAuth 2.1 y un runtime de MCP como Arcade.dev para evitar el mal uso de herramientas, fugas de datos y agencia excesiva. Está pensada para líderes de gestión de identidad y acceso, arquitectos de seguridad e ingenieros líderes de AI que necesitan los requisitos exactos de infraestructura para desplegar agentes multiusuario en producción de forma segura.
Modelo de amenazas para agentes de AI multiusuario: inyección de prompts, mal uso de herramientas y confused deputy
No puedes diseñar autorización segura sin definir primero el modelo de amenazas. En los modelos de lenguaje, el vector de ataque más peligroso va de la inyección de prompts directo al mal uso de herramientas.
Si un agente empresarial hereda acceso de administrador total a un sistema backend, un solo documento RAG envenenado o un prompt malicioso puede convertir ese agente en un arma. Un atacante le indica al modelo que escanee una bandeja de entrada, resuma datos financieros sensibles y exfiltre el resultado mediante una llamada a herramienta externa. Toda la cadena de exfiltración se completa sin ningún humano en el ciclo.
El Open Web Application Security Project destaca estas vulnerabilidades en sus directrices actualizadas, citando inyección de prompts y agencia excesiva como riesgos primarios que llevan directamente al problema del confused deputy.
En un ataque de confused deputy, una aplicación es engañada para que abuse de la autoridad que heredó.
Hay una segunda clase de ataque que apunta al flujo de autorización en sí. Un atacante que intercepta o adivina el identificador de una autorización OAuth pendiente puede redirigir el paso de consentimiento a su propio navegador, capturando el permiso del usuario o inyectando en el agente credenciales que no debería tener. Tratar cada primera autorización de herramienta como un paso que debe estar ligado criptográficamente a un usuario verificado de la app es la única defensa duradera.
El modelo de dos identidades para la autorización de agentes
Los equipos de ingeniería suelen cometer uno de dos errores al diseñar la autorización de agentes. Si le das al agente su propia identidad, un empleado sin privilegios puede saltarse sus permisos a través del agente. Si heredas el acceso completo del usuario, una sola inyección de prompt se propaga por todos los sistemas conectados.
La respuesta correcta es la intersección: lo que este agente tiene permitido hacer Y lo que este usuario tiene permitido hacer, evaluado por acción, en tiempo de ejecución.
La autorización efectiva en sistemas agénticos requiere que cada solicitud lleve dos capas de identidad:
- La clave a nivel de proyecto (la aplicación del agente): La identidad de carga de trabajo que realiza la llamada. Registrada como cliente OAuth y limitada a la aplicación que ejecuta la lógica del agente.
- La identidad a nivel de usuario (en nombre de quién se ejecuta la acción): La persona real que solicita la acción, autenticada mediante un protocolo como OpenID Connect y representada en la solicitud como sujeto delegado.
El runtime evalúa estas dos identidades contra un contexto de ejecución delegada: un enlace acotado y de corta duración que vincula a un usuario específico con un agente específico para una tarea específica. El contexto no es una tercera identidad, sino la tupla de claims (usuario, agente, scopes, audiencia, tenant, ID de tarea, expiración) que el runtime evalúa en cada llamada a herramienta.
Este modelo aplica la regla de intersección de identidades, que es la base de la seguridad moderna de agentes.
La autoridad efectiva de un agente siempre debe calcularse como la intersección estricta de sus permisos base y los permisos del usuario humano que hace la solicitud. Nunca la unión.
Si un usuario no puede eliminar un registro de base de datos, el agente que actúa en su nombre debe fallar al intentar esa misma acción. No importa cuáles sean las capacidades teóricas máximas del agente.
Implementar esta intersección exige separar estrictamente los protocolos. OpenID Connect autentica al usuario humano para establecer quién interactúa con el sistema. OAuth 2.1 autoriza las llamadas específicas que el agente puede hacer en su nombre.
Mezclar estos dos protocolos genera tokens con permisos excesivos que se reutilizan en sistemas para los que nunca fueron definidos, dándole a un agente comprometido acceso duradero mucho más allá de lo que el usuario autorizó.
Nueve capacidades para auth de agentes de AI multiusuario en producción
La especificación de autorización del Model Context Protocol, desarrollada en colaboración con Anthropic, Arcade.dev, Microsoft, Okta/Auth0 y otros, define recursos protegidos estilo OAuth y descubrimiento de servidores de autorización, con vinculación de audiencia mediante Resource Indicators (RFC 8707) y delegación mediante Token Exchange (RFC 8693). MCP define el handshake de auth; la capa de runtime superior aún debe gestionar el almacenamiento de tokens, el consentimiento just-in-time, la verificación de usuarios, el RBAC y la auditoría. Las nueve capacidades a continuación cierran esa brecha.
Construir infraestructura de agentes multiusuario robusta implica evaluar tus sistemas contra esta lista de capacidades 2026. Unificarlas previene accesos no autorizados y garantiza una ejecución confiable de herramientas.
Capacidad 1: Modelar usuario, agente y contexto delegado
Cada decisión de autorización en tu runtime debe evaluar simultáneamente la tupla usuario, agente y contexto.
Si tu capa de herramientas backend solo verifica la API key del agente, no estás modelando al usuario humano.
El modelado delegado real garantiza que el servidor de recursos upstream sepa exactamente qué humano originó la solicitud, qué workload la orquestó y el contexto preciso bajo el cual se otorgó la delegación.
En la práctica, esto significa que el user_id fluye desde la sesión autenticada de tu app hacia cada llamada del runtime. Un patrón típico: tu IdP (Stytch, Auth0, Okta o similar) autentica al usuario y emite una sesión, tu app extrae el identificador de usuario de esa sesión, y tu código pasa ese identificador explícitamente a cada llamada del SDK de runtime. Por ejemplo, getTools({ tools: [...], userId: userEmail }) y tools.execute({ ..., user_id: userEmail }). El runtime resuelve entonces los tokens OAuth guardados de ese usuario específico para el proveedor y scope solicitados. Sin esta vinculación explícita de usuario en cada llamada, el runtime no puede aplicar la regla de intersección.
Capacidad 2: Separar autenticación con OpenID Connect de autorización con OAuth
Debes separar estrictamente la autenticación humana de la autorización delegada del agente. OpenID Connect maneja la sesión de inicio de sesión. OAuth 2.1 maneja la autorización posterior de herramientas.
Al separar estas responsabilidades, evitas la confusión de identidades. Un agente comprometido por un prompt malicioso no puede reutilizar cookies de sesión humana para acceder a sistemas no relacionados.
Capacidad 3: Emitir tokens de acceso de corta duración, con scope y audiencia vinculados
Los tokens de acceso de agentes deben cumplir los estándares criptográficos más estrictos para prevenir replay de tokens y movimiento lateral.
Cada token de acceso delegado debe incluir el contexto completo de ejecución como claims. En un token delegado, el sujeto (sub) identifica al usuario humano en cuyo nombre se realiza la acción (p. ej., user:alice). El actor (act) identifica al agente que hace la llamada (p. ej., agent:support-copilot). La audiencia (aud) vincula el token a un servidor de recursos específico (p. ej., gmail-api), y el scope otorga un permiso concreto (p. ej., email.draft, no email.send). La expiración (exp) se configura en una ventana corta, típicamente de 5 a 30 minutos. Un claim de tenant (p. ej., tenant:acme) lleva el contexto del cliente o workspace, y un ID de tarea (p. ej., task_123) vincula la llamada con la tarea o sesión de usuario que la originó.
Esta estructura de claims aplica la regla de intersección de forma criptográfica: cada token lleva el usuario, el agente y el contexto de ejecución acotado, y el servidor de recursos valida los tres antes de atender la solicitud.
Tu stack debe aplicar RFC 8707 resource indicators para vincular tokens a una audiencia específica, asegurando que un token emitido para una API de calendario no pueda usarse contra un CRM.
Usa RFC 8693 token exchange para intercambiar de forma segura tokens de usuario amplios por tokens de agente con scope restringido.
Vincula los tokens al emisor usando RFC 9449 demonstrating proof of possession (DPoP), asegurando que aunque un token de acceso sea interceptado, los atacantes no puedan usarlo sin la clave privada del cliente. El stack también debe soportar RFC 9126 pushed authorization requests y RFC 9396 rich authorization requests para una granularidad mejorada y resistente a manipulaciones.
Capacidad 4: Guardar tokens y automatizar la renovación entre proveedores
Un runtime que gestione el almacenamiento y renovación de tokens por usuario y por proveedor es innegociable para agentes en producción. Administrar el ciclo de vida de tokens OAuth para miles de usuarios y decenas de proveedores es un problema de ingeniería considerable por sí solo.
Los tokens de acceso y actualización deben guardarse encriptados de forma estricta por usuario y por proveedor. Tu sistema necesita manejar automáticamente los detalles específicos de cada proveedor fuera del contexto del modelo de lenguaje.
Por ejemplo, Google aplica un límite rotativo de 100 refresh tokens por cliente, y Microsoft Entra rota los refresh tokens en cada canje con una ventana deslizante de inactividad de 90 días. Un token vault dedicado debe abstraer esta lógica de actualización del desarrollador de agentes.
Capacidad 5: Aplicar pasos de lectura, borrador y aprobación de commits
Los arquitectos de seguridad deben implementar flujos de aprobación fuera de banda para cualquier acción irreversible.
Leer datos o redactar respuestas requiere poca fricción y puede ejecutarse de forma síncrona. Pero los efectos externos, como enviar correos, eliminar registros o hacer commits de código, deben activar aprobaciones humanas explícitas.
Estas aprobaciones deben ocurrir por un canal seguro y fuera de banda: una app de autenticación empresarial, una interfaz separada o una plataforma de mensajería directa.
Capacidad 6: Evaluar la política antes de cada llamada a herramienta conectándose a los sistemas de permisos existentes
Nunca confíes en la solicitud directa a la API de un modelo de lenguaje. Cada llamada a herramienta debe pasar por una capa de política centralizada que intersecte al usuario, agente, tenant, acción, recurso y tarea, y evaluarla en milisegundos para no aumentar la latencia conversacional del agente.
Esto no es una invitación a levantar otro sistema de políticas. Las empresas ya tienen sistemas de permisos y proveedores de identidad como Okta, Entra, SailPoint y stores propios de roles. El trabajo del runtime es conectarse a esos sistemas, obtener tokens con alcance limitado en tiempo real y aplicar las políticas ya definidas, no duplicarlas en una nueva herramienta.
Open Policy Agent, Cedar, Oso, OpenFGA, WorkOS FGA y los grafos de relaciones estilo Zanzibar son útiles como motor de aplicación local. Pero la fuente de verdad sobre quién puede hacer qué debe permanecer en tus sistemas de identidad y gobernanza actuales. Un runtime que te pide redefinir tu modelo de autorización en su propio DSL mueve el problema, no lo resuelve.
Capacidad 7: Usar consentimiento y autorización justo a tiempo
El consentimiento general durante el onboarding viola el principio de mínimo privilegio.
Implementa autorización justo a tiempo. Cuando un agente necesita acceso a un sistema nuevo o un alcance no otorgado para cumplir un prompt, el runtime pausa la ejecución. Devuelve al usuario una interfaz de consentimiento granular y específica al contexto, captura el consentimiento criptográfico, gestiona el nuevo token y reanuda la tarea sin perder el contexto conversacional.
La MCP’s URL Elicitation Specification Enhancement Proposal (SEP), creada por Arcade.dev en colaboración con Anthropic y aceptada en la especificación de MCP, estandariza cómo un runtime de agentes entrega URLs de consentimiento granulares y específicas al contexto al usuario durante la tarea.
Capacidad 8: Vincular los flujos de auth iniciales a un usuario verificado de la app
El consentimiento granular (Capacidad 7) solo importa si el runtime puede confirmar qué usuario está frente al teclado durante la primera autorización OAuth. Sin esa confirmación, un atacante que intercepte un flow_id puede redirigir el paso de consentimiento a su propio navegador y secuestrar la autorización en la sesión del usuario o capturar su permiso.
La mitigación es un verificador de usuario del lado del servidor. Cuando un usuario autoriza una herramienta por primera vez, el runtime lo redirige a una ruta verificadora en tu app. Tu verificador lee el flow_id del query string, consulta al usuario autenticado en la sesión de tu app (Stytch, Auth0, Okta como IdP, o un sistema de auth en capa de app como Supabase) y envía ese user_id al runtime mediante una llamada server-side confirm_user firmada con tu API key.
Si el user_id de tu sesión coincide con el user_id especificado al iniciar el flujo, el runtime continúa. Si no, lo rechaza. Así, cada primera autorización queda vinculada a una identidad verificada y autenticada en tu app, lo que cierra la superficie de ataque de flow-phishing.
En despliegues multiusuario en producción, esto no es negociable. Las implementaciones de referencia de Arcade muestran el patrón en Next.js con Stytch y Next.js con Supabase, y la guía de Auth Seguro en Producción de Arcade recorre la ruta del verificador de extremo a extremo.
Capacidad 9: Generar registros de auditoría inmutables para cada acción del agente
Cada acción de un agente debe generar un registro de auditoría inmutable con una cadena de custodia completa.
Esto implica capturar el usuario solicitante, la identidad del agente, el tenant, el ID de tarea, la herramienta invocada, el recurso accedido, la decisión de política y su versión, el hash del prompt, referencias de entrada, hash de salida, estado de aprobación y la marca de tiempo exacta.
Estos registros deben ser compatibles con OpenTelemetry, con trazas estructuradas que se exporten limpiamente a los sistemas empresariales de gestión de información y eventos de seguridad para respuesta inmediata a incidentes.
La historia de auditoría no se trata solo de los registros en sí, sino de los controles que los producen. La certificación SOC 2 Tipo 2 valida que los controles de auditoría, acceso y gestión de cambios del runtime funcionan según lo diseñado bajo auditoría independiente. Trata la certificación como el piso mínimo de compra y la estructura de log por acción como la capacidad real del producto. Necesitas ambas cosas.
Por qué un runtime y no un gateway: el cambio arquitectónico detrás de la autorización multiusuario
En el modelo tradicional, los usuarios interactúan con aplicaciones, las aplicaciones llaman APIs, y un gateway se sienta entre ellos para enrutar, autenticar y limitar solicitudes en el perímetro. El proxy es el punto de control porque es el cuello de botella: todas las solicitudes pasan por él.
En el modelo agéntico, esa topología se invierte. El agente ya es el proxy. Un usuario habla con un agente. El agente razona, planifica y llama herramientas en nombre del usuario. Ya maneja la mediación, el enrutamiento y la orquestación. Añadir un API gateway tradicional frente a las herramientas no agrega un punto de control; agrega un salto redundante que no puede ver el contexto de ejecución que realmente importa: qué usuario, qué acción, qué permiso, ahora mismo.
Por eso “MCP gateway” es el enfoque equivocado para el problema de autorización. Un proxy sin estado evalúa cada solicitud de forma aislada. No puede rastrear que una solicitud es el paso 3 de un flujo de trabajo de 6 pasos, actuando en nombre de un usuario específico que autorizó un alcance determinado hace unos minutos. Agregarle soporte MCP a un API gateway no es un cambio de dirección. Es un parche.
El punto de control en una arquitectura agéntica es la capa de ejecución donde corre la herramienta. Ahí es donde se resuelven las credenciales, se verifican los permisos y se ejecutan acciones en nombre de una persona concreta. Eso es el runtime. Las nueve capacidades anteriores solo pueden aplicarse ahí.
Dónde encaja cada capa en el stack de auth para agentes (IdP, vault OAuth, motor de políticas, runtime MCP)
Entender el panorama de vendors significa categorizar las plataformas por su función arquitectónica estricta. Confundir el lugar de una herramienta en el stack genera brechas de autorización peligrosas.
El problema de fondo es la consistencia a escala. Aunque tengas las piezas correctas (un IdP, un vault de tokens, un motor de políticas), la mayoría de los stacks no tienen una forma uniforme de aplicarlas en cada agente, cada usuario y cada sistema. Cada equipo arma su propia integración, y dos equipos en la misma empresa terminan aplicando la misma política de manera distinta. El runtime es lo que hace que un modelo de autorización único sea aplicable en todos los agentes, sin que cada equipo reconstruya la plomería.
| Capa arquitectónica | Vendors de ejemplo | Función principal | Brecha clave para agentes multiusuario |
|---|---|---|---|
| Proveedores de identidad | Okta, Auth0, Entra, WorkOS y Clerk | Autentican al usuario humano en la aplicación mediante OpenID Connect. | Carece del stack completo de autorización para agentes. El soporte para flujos de delegación explícita, como RFC 8693 y sender-constraining vía DPoP, varía considerablemente y suele requerir acciones personalizadas. La auditoría cubre eventos de autenticación, no acciones por llamada de herramienta. |
| Librerías OAuth y vaults | Authlib, HashiCorp Vault, Doppler | Almacenan, cifran y gestionan tokens OAuth de forma segura. | Carece de un motor de decisiones contextual, evaluación robusta de políticas y la lógica de refresco dinámico multi-proveedor necesaria para flujos agénticos asíncronos. La auditoría captura operaciones de token, no el contexto de usuario, agente y herramienta detrás de cada llamada. |
| Motores de políticas y plataformas FGA | Open Policy Agent, Cedar, Oso (Polar DSL), OpenFGA, WorkOS FGA, Zanzibar-style, Sailpoint | Evalúan políticas de autorización granular sobre grafos de relaciones complejos. | Deja el brokering de tokens, las experiencias de consentimiento y la conectividad física de herramientas para que el equipo de ingeniería los construya desde cero. La auditoría registra la decisión de política, no el contexto completo de ejecución que vio el servidor de recursos. |
| Frameworks de agentes | LangChain, Mastra, Crew AI | Proveen abstracción de herramientas para flujos de trabajo de agentes. | Regresan la carga de auth a tu código de aplicación; tratan las herramientas como claves en un archivo dotenv y silenciosamente se rompen en cuanto un segundo cliente se registra. Sin rastro de auditoría nativo para acciones de agentes. |
| Gateways MCP y wrappers de integración | Composio | Conectan modelos de lenguaje con herramientas externas usando interfaces estandarizadas. | Diseñado para prototipos rápidos y agentes de prueba de concepto de un solo usuario. Es un wrapper de integración a nivel SDK, no un runtime. El OAuth por usuario está soportado, pero SSO, OIDC y auditoría son limitados en lugar de nativos, y la intersección de permisos agente/usuario no se aplica. |
| Runtimes MCP | Arcade.dev | El primer runtime MCP construido para autorización de agentes. Ofrece permisos específicos por usuario post-prompt, gestión aislada del ciclo de vida de tokens (refresco, rotación, inconsistencias), brokering de protocolo OAuth, aplicación de políticas de acceso contextual y logs de auditoría inmutables por acción exportables vía OpenTelemetry. | No aplica. Esta capa unifica explícitamente las capas anteriores y cubre sus brechas operativas. |
Arquitecturas de referencia para auth de agentes multiusuario
Estas capacidades solo importan si puedes mapearlas a arquitecturas reales. Los tres patrones a continuación muestran cómo un runtime MCP aplica la autorización multiusuario en producción.
Los patrones asumen la configuración multiusuario canónica: una aplicación de agente que autentica usuarios mediante su propio proveedor de identidad (Stytch, Auth0, Okta o Entra) y llama al runtime a través de su SDK cliente, pasando el user_id autenticado en cada llamada de herramienta. El runtime es el backend que gestiona OAuth, guarda tokens por usuario y aplica políticas. Para integraciones con clientes MCP como Copilot, Cursor o Claude Desktop, se usa la ruta del gateway MCP del runtime, pero la semántica del runtime es la misma.
Dentro de cada patrón corren dos flujos de auth distintos. Auth a nivel de servidor determina si la aplicación de agente (un cliente MCP) puede conectarse al servidor MCP. Auth a nivel de herramienta determina si el usuario actualmente autenticado puede invocar una herramienta específica contra este recurso con estos parámetros ahora mismo. La auth a nivel de servidor ocurre una vez por conexión cliente-servidor. La auth a nivel de herramienta se ejecuta en cada llamada, y es donde operan el verificador de usuario (Capacidad 8), el consentimiento just-in-time vía URL Elicitation (Capacidad 7) y la regla de intersección de permisos. La guía de Autorización a Nivel de Servidor vs. Nivel de Herramienta de Arcade explica la distinción en detalle.
Patrón 1: agente de productividad interno (Google Workspace)
Flujo arquitectónico: Usuario Humano -> [Proveedor de Identidad OIDC] -> Aplicación de Agente -> Runtime MCP -> Herramientas MCP de Gmail y Calendar -> Google Workspace
Escenario: Un asistente interno basado en Claude organiza reuniones y resume correos en un entorno Google Workspace multiusuario.
Implementación: El agente nunca debe tener delegación a nivel de dominio. En cambio, el runtime de MCP gestiona un flujo OAuth específico por usuario. El runtime solicita los permisos delegados gmail.readonly y gmail.compose, vinculando el token resultante estrictamente al empleado individual.
En la primera autorización del usuario, el runtime redirige su navegador a una ruta verificadora en la app. El verificador lee el flow_id, identifica al usuario autenticado desde la sesión OIDC y confirma el user_id al runtime. El grant de OAuth solo procede después de que el runtime compara el user_id confirmado por el verificador con el user_id que inició el flujo. A partir de ese momento, el token del usuario queda almacenado por proveedor y se reutiliza en llamadas posteriores sin necesidad de re-autorización.
Cuando el agente intenta leer una bandeja de entrada, la app pasa el user_id autenticado de su sesión al llamado del SDK del runtime. El runtime evalúa el motor de políticas, recupera el token específico de ese usuario desde el vault y ejecuta la llamada.
Si el agente alucina o recibe un prompt malicioso para enviar un correo, solicita el permiso gmail.send. El runtime detecta esta solicitud no autorizada, pausa la ejecución y fuerza una aprobación fuera de banda al dispositivo del usuario. Un humano autoriza explícitamente el envío, o simplemente no ocurre.
Patrón 2: agente de Slack multi-tenant (aislamiento por workspace)
Flujo de arquitectura: Usuario humano -> [Proveedor de identidad OIDC] -> Aplicación del agente -> Runtime de MCP -> Herramientas MCP de Slack -> Workspace de Slack
Escenario: Una aplicación B2B despliega un agente que agrega alertas y ejecuta acciones administrativas en múltiples workspaces de Slack de clientes.
Implementación: Gestionar el acceso entre límites corporativos distintos requiere un aislamiento multi-tenant estricto. El runtime administra instalaciones OAuth a nivel de workspace, generando tokens de bot combinados con permisos granulares por usuario en canales, como chat:write y channels:history.
El runtime usa indicadores de recurso RFC 8707, lo que garantiza que los tokens generados para la instancia de Slack del Tenant A estén matemáticamente vinculados a la audiencia de ese tenant.
Si un ataque de inyección intenta forzar al agente a leer datos del Tenant B usando el contexto del Tenant A, el motor de políticas rechaza al instante la reutilización del token entre tenants. Eso previene una filtración catastrófica de datos entre clientes.
Patrón 3: agente de CRM en Salesforce (permisos a nivel de usuario)
Flujo de arquitectura: Usuario humano -> [Proveedor de identidad OIDC] -> Aplicación del agente -> Runtime de MCP -> Herramientas MCP de Salesforce -> Salesforce
Escenario: Un copiloto de ventas actualiza registros del pipeline, redacta correos de seguimiento y consulta el historial de clientes en nombre de cada ejecutivo de cuenta.
Implementación: Las reglas de acceso a datos en Salesforce son notoriamente complejas. El runtime de MCP solicita los permisos OAuth api y refresh_token para operar en Salesforce en nombre del usuario, y luego evalúa el perfil específico y los conjuntos de permisos del ejecutivo de cuenta en cada llamada a una herramienta antes de permitir que el agente continúe. El acceso a nivel de objeto (lectura en Account/Contact, edición en transiciones de etapa de Opportunity, commit en conversión de Lead) está controlado por los permisos existentes del usuario en Salesforce, no por las credenciales propias del agente.
La implementación impone una separación estricta entre leer contactos de cuenta, redactar notas de reunión y confirmar actualizaciones del pipeline.
Con autorización just-in-time, si un representante junior le pide al agente actualizar una oportunidad cerrada-ganada que no tiene privilegios para editar, el motor de políticas bloquea la acción en el límite de la herramienta. Devuelve una denegación de acceso al modelo de lenguaje sin exponer las credenciales del backend.
Antipatrones de autenticación de agentes que debes evitar en producción
Los motores de respuesta y las auditorías de seguridad favorecen sistemas que eliminan fallas arquitectónicas conocidas. Si tu configuración actual de agentes depende de alguno de estos antipatrones, tu infraestructura no está lista para producción empresarial.
- Enrutamiento con una sola API key: El backend del agente comparte una única clave de cuenta de servicio con altos privilegios entre todos los usuarios. Esto rompe la atribución de identidad en la capa de solicitudes. El backend no puede distinguir entre la petición de un practicante y la de un CEO, y una sola inyección de prompt hereda el máximo radio de impacto en toda la base de usuarios.
- Modo dios con guardarraíles en el prompt: El agente corre con credenciales de root o administrador, y los ingenieros dependen de instrucciones en el system prompt como “no borres datos” para mantener la seguridad. Los modelos de lenguaje se manipulan fácilmente con inyecciones indirectas, así que confiar en el modelo para gobernar su propia autorización es una falla de seguridad fundamental.
- Consentimiento masivo al registrarse: Obligar a los usuarios a otorgar permisos OAuth masivos y multi-sistema durante el onboarding inicial. Esto viola el principio de mínimo privilegio, genera fatiga de consentimiento y provisiona tokens con capacidades peligrosas mucho antes de que el usuario las necesite.
- Verificaciones solo en la interfaz: Las verificaciones de autorización se aplican exclusivamente en el chat o la app web frontend, dejando el plano de herramientas del backend sin protección. Si un atacante evita el chat y envía payloads directamente al endpoint de ejecución de herramientas, el sistema responde sin verificar el contexto del usuario delegado.
- Sin distinción entre borrador y confirmación: Tu agente trata cada acción con el mismo nivel de autorización, enviando correos o transfiriendo fondos con la misma facilidad con que los redacta. Sin un gradiente de lectura/borrador/confirmación y un paso de aprobación fuera de banda para acciones irreversibles, una sola inyección de prompt provoca daños irreversibles.
- Sin registro de auditoría inmutable: Tu sistema de agentes no tiene registro de auditoría por acción, o depende de logs de aplicación que pueden modificarse después del hecho. Sin un registro inmutable de quién autorizó qué acción de herramienta y cuándo (con versión de política, hash del prompt y estado de aprobación), los incidentes de seguridad no se pueden reconstruir y los reportes de auditoría para reguladores se vuelven imposibles.
Conclusión: la regla de autorización delegada para agentes multiusuario
La transición a agentes de AI multiusuario en producción exige un cambio fundamental en cómo arquitectamos la seguridad. Toda la filosofía de autorización de agentes se reduce a una regla estricta:
Este agente específico puede ejecutar esta acción específica sobre este recurso específico, para este usuario específico, en este tenant específico, para esta tarea específica, durante un período de tiempo estrictamente limitado.
Si tu infraestructura actual no puede aplicar criptográficamente y auditar esa oración exacta desde el prompt del chat hasta la capa de API del backend, tu sistema no está listo para producción multiusuario en 2026.
Un gateway no puede aplicar esa regla. Un runtime sí.
Antes de comprometerte con un runtime, haz tres cosas. Audita tu mapeo de identidad actual para confirmar que tus sistemas backend modelan la tupla usuario-agente-contexto en cada llamada a herramienta. Deja de construir plomería OAuth a medida. La lógica de refresco, las interfaces de consentimiento just-in-time y el almacenamiento de tokens multi-tenant son deuda técnica indiferenciada que tus ingenieros no deberían escribir. Y prueba la regla de intersección de forma agresiva: envía prompts maliciosos contra tus propios agentes para verificar que tu motor de políticas los intercepta en el límite de red.
Arcade es el runtime MCP diseñado específicamente para la autorización de agentes, con manejo nativo de OAuth por usuario, consentimiento just-in-time, bóveda de tokens, intersección de políticas y auditoría inmutable, no como plugins añadidos. Las nueve capacidades anteriores se unifican bajo un solo plano de control, junto con el catálogo de herramientas optimizado para agentes y la gobernanza del ciclo de vida de Arcade, para que tus equipos de ingeniería se concentren en desarrollar lógica de agentes de alto valor en lugar de mantener plomería de identidad frágil.
Preguntas frecuentes
¿Cuál es la mejor forma de gestionar la autenticación y autorización de agentes de AI multiusuario en 2026?
Trata cada llamada a herramienta como acceso delegado del usuario, no como acceso propio del agente. Implementa un modelo de dos identidades (la aplicación del agente y el usuario en cuyo nombre se ejecuta la acción), vincula cada llamada a un contexto de ejecución delegada y aplica la regla de intersección mediante tokens delegados OAuth 2.1, un motor de políticas frente a las herramientas, tokens de corta duración con alcance limitado y logs de auditoría inmutables.
¿Qué es el modelo de dos identidades para la autorización de agentes?
Cada solicitud lleva dos identidades: la clave a nivel de proyecto (la aplicación del agente que hace la llamada) y la identidad a nivel de usuario (la persona en cuyo nombre se toma la acción). El runtime evalúa estas dos identidades contra un contexto de ejecución delegada, un vínculo acotado que liga a un usuario específico con un agente específico para una tarea específica, de modo que el backend pueda atribuir y limitar cada acción.
¿Qué es la “regla de intersección” y por qué importa?
Los permisos efectivos del agente deben ser la intersección de los permisos del usuario y las capacidades permitidas del agente. Nunca la unión. Esta regla previene fallas de “diputado confundido”, donde un prompt inyectado lleva al agente a abusar de acceso amplio al sistema.
¿Cómo deben usarse juntos OpenID Connect y OAuth 2.1 para agentes?
Usa OpenID Connect para autenticar al usuario (quién es). Usa OAuth 2.1 para autorizar las llamadas a herramienta del agente (qué puede hacer el agente en nombre del usuario) con tokens con alcance limitado y audiencia específica.
¿Cómo se evita que la inyección de prompts derive en mal uso de herramientas?
No dependas de los prompts para la seguridad. Enruta cada llamada a herramienta a través de una capa de aplicación de políticas que verifique usuario, agente, contexto, alcances, tenant y recurso. Usa tokens de corta duración con audiencia específica para que incluso una inyección exitosa no pueda pivotar entre sistemas.
¿Qué propiedades debe tener un token para el acceso seguro de agentes delegados?
Los tokens deben ser de corta duración, con alcance limitado y audiencia específica (para que no puedan reutilizarse contra otras APIs). Para mayor resistencia a la reutilización, usa tokens vinculados al remitente (por ejemplo, DPoP), de modo que los tokens robados sean inútiles sin la clave del cliente.
¿Cómo se gestionan de forma segura los tokens de actualización OAuth para miles de usuarios?
Guarda los tokens en una bóveda cifrada por usuario y proveedor, y automatiza la actualización y rotación fuera del LLM. Esto evita que los secretos se filtren en los prompts y que los casos especiales de actualización específicos de cada proveedor rompan los flujos del agente.
¿Cuándo debe un agente requerir aprobación escalonada o confirmación humana?
Exige aprobación escalonada para acciones irreversibles o de alto impacto (como enviar un correo externo, eliminar registros, hacer un commit de código o transferir fondos). Deja que el agente lea y redacte con menos fricción, pero bloquea las acciones de “confirmación” mediante un flujo de aprobación fuera de banda.
¿Qué es la autorización just-in-time para agentes de AI?
El agente solicita nuevos alcances o acceso a sistemas solo cuando los necesita para una tarea específica. El runtime hace una pausa, recopila el consentimiento granular, genera un token con alcance reducido y continúa. Esto reduce el exceso de permisos y la fatiga de consentimiento.
¿Qué es MCP URL Elicitation?
URL Elicitation es una Propuesta de Mejora de Especificación redactada por Arcade.dev con Anthropic y aceptada en la especificación del Model Context Protocol. Define cómo un runtime MCP devuelve al usuario, en medio de una tarea, una URL de consentimiento granular y específica al contexto cuando el agente necesita un nuevo alcance o sistema, lo que permite al usuario autorizar la solicitud fuera de banda antes de que el runtime retome la ejecución. URL Elicitation es el mecanismo estandarizado detrás de la autorización de agentes just-in-time.
¿Qué debe incluir un log de auditoría para las llamadas a herramienta de un agente?
Registra la identidad del usuario, identidad del agente, tenant, herramienta, acción, recurso, decisión de política, marca de tiempo y un hash del prompt o la solicitud. Haz los logs inmutables y exportables en formatos compatibles con OpenTelemetry para respuesta a incidentes y cumplimiento normativo.
