Qué ha cambiado y qué no en Autenticación e Identidad para aplicaciones agenticas

Recientemente revisé este artículo, y se mencionó la autenticación de agentes:

Estamos viendo pistas de cómo podría ser esto. La última especificación de MCP, por ejemplo, incluye un marco de autorización basado en OAuth 2.1, señalando la posibilidad de avanzar hacia la concesión de tokens con alcance revocable a los agentes de IA en lugar de secretos sin procesar. Podemos imaginar un escenario donde un agente de IA no obtenga tus claves reales de AWS, sino que obtenga una credencial de corta duración o un token de capacidad que le permita realizar una acción de forma restringida.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

Muchos amigos y personas ajenas al campo de la seguridad o CIAM tienen la impresión de que esto es algo nuevo, pero definitivamente no lo es. OAuth es un protocolo estándar de autorización basado en tokens que involucra tokens con permisos delimitados (tokens de acceso). Estos son sensibles al tiempo y limitados en alcance, lo que garantiza la seguridad y el control de acceso adecuado a los recursos y servicios. En el mercado global de SaaS (antes de la IA), la mayoría de las soluciones profesionales de identidad ya están construidas sobre esto.

Cuando conectas tu cuenta de Google a una aplicación de terceros como Notion o Zoom, utiliza OAuth para solicitar solo los permisos necesarios, como el acceso a tu calendario o contactos, sin exponer nunca tu contraseña de Google. Puedes revocar ese acceso en cualquier momento desde la configuración de tu cuenta de Google. Este patrón de acceso delegado es exactamente para lo que OAuth está diseñado y es la misma base que se está extendiendo a aplicaciones agenticas hoy en día.

Qué no cambia en el mundo agentico#

La autenticación no es nueva, aún se basa en OAuth 2.1#

Hay dos protocolos principales emergentes: MCP y A2A.

• MCP se enfoca en la interacción entre LLMs y las herramientas y contexto de tu aplicación.
• A2A se enfoca en habilitar el intercambio de tareas entre agentes.

Pero cuando se trata de autenticación y autorización, ambos aún dependen de estándares bien establecidos de la industria como OAuth.

Los servidores de autorización MCP DEBEN implementar OAuth 2.1 con medidas de seguridad apropiadas para clientes confidenciales y públicos.

El Cliente A2A es responsable de obtener los materiales de credencial necesarios (por ejemplo, tokens de OAuth 2.0, claves de API, JWTs) a través de procesos externos al propio protocolo A2A. Esto podría involucrar flujos de OAuth (código de autorización, credenciales de cliente), distribución segura de claves, etc.

Como lo expresa Google:

En lugar de inventar nuevos estándares propietarios para seguridad y operaciones, A2A busca integrarse sin problemas con la infraestructura empresarial existente y las mejores prácticas ampliamente adoptadas.

¿Un agente necesita una identidad única?#

Mucho contenido de hype y FOMO empuja la idea de que, a medida que los agentes se vuelven más comunes, necesitamos un sistema para gestionar identidades de agentes.

La respuesta es: sí y no.

Sí, porque estamos introduciendo una nueva capa entre humanos y máquinas. Existen necesidades reales de:

• Gestionar e identificar agentes
• Asignar IDs únicos
• Rastrear registros
• Auditar acciones (para saber si una tarea fue realizada por un humano o por un agente)

Sin embargo, en la mayoría de los casos técnicos, no hay necesidad de crear un concepto formal de “Identidad de Agente.”

Agente ≠ Usuario, ≠ Cuenta de Servicio.

Detrás de cada agente, todavía hay un usuario y la identidad del usuario suele ser suficiente.

Hoy en día, la mayoría de los agentes:

• Actúan basados en la autorización del usuario (por ejemplo, tokens de OAuth)
• Ejecutan lógica o realizan una llamada a API
• Realizan tareas de corta duración, puntuales (sin necesidad de seguimiento)

En ese sentido, el agente es simplemente una función-como-herramienta y no necesita un ID globalmente único.

Por ejemplo:

• Un agente GPT llamando a tu API de Calendario solo necesita el acceso que concediste.
• Un agente de LangChain no necesita una identidad siempre que pueda llamar a las herramientas correctas, funciona.

Incluso antes de la IA, teníamos el concepto de autenticación de máquina a máquina (M2M).

M2M significa intercambio automático de datos entre servicios, sin un humano en el medio.

En este contexto, la autenticación a menudo usa una aplicación cliente o cuenta de servicio.

Si realmente deseas que tu agente tenga una identidad (para auditoría, etc.), puedes usar el ID de la aplicación y eso es suficiente.

Aún necesitas definir la arquitectura de tu producto#

Esto no ha cambiado. Ya sea que tu producto involucre agentes o no, la arquitectura de tu sistema de identidad depende de quiénes son tus usuarios y cómo interactúa tu sistema con ellos.

Si estás construyendo un producto agentico orientado al consumidor: Necesitarás métodos de inicio de sesión ligeros (correo electrónico, teléfono, inicio de sesión social), y un grupo de usuarios unificado para gestionar a quienes interactúan con tu aplicación y sus agentes. Los agentes actúan en nombre de estos usuarios utilizando tokens delegados (por ejemplo, a través de OAuth).

Ejemplo:

Imagina que estás construyendo un asistente de programación de IA, o un bot de calendario impulsado por IA.

Cada usuario inicia sesión con su cuenta personal de Google. Tu sistema utiliza OAuth para obtener permiso para acceder a su calendario. El agente no tiene su propia identidad, utiliza el token del usuario para programar reuniones, verificar disponibilidad o enviar recordatorios. La arquitectura de identidad es simple: un grupo de usuarios global, almacenamiento de tokens y seguimiento de consentimiento por usuario.

Si estás construyendo una plataforma agentica B2B:

Necesitarás soportar identidad a nivel organizacional, no solo de usuarios individuales. Eso incluye:

1. SSO para clientes empresariales
2. Separación a nivel de espacio de trabajo o inquilino
3. Políticas de delegación de agentes a nivel organizacional (por ejemplo, controlando lo que los agentes pueden hacer entre equipos)
4. Visibilidad a nivel de administrador y registros de toda la actividad de los agentes en nombre de los empleados

Ejemplo:

Imagina que estás construyendo una plataforma que proporciona agentes de IA para automatizar flujos de trabajo internos, como un bot analista de seguridad que monitorea registros y envía alertas, o un asistente de ventas que redacta correos electrónicos a partir de datos de CRM.

Cada empresa que utiliza tu plataforma quiere:

1. Iniciar sesión con su SSO existente
2. Controlar a qué pueden acceder los agentes (por ejemplo, herramientas internas, sistemas de documentos)
3. Ver qué agente realizó qué tarea, bajo la autorización de qué empleado

En este caso, tu arquitectura de identidad necesita soportar un diseño multi-inquilino, permisos de agente delimitados, y políticas específicas por organización. Los agentes aún actúan en nombre de los usuarios, pero los permisos y los límites de identidad se aplican por cada inquilino empresarial.

En ambos casos, el modelo de identidad define cómo operan los agentes, a qué pueden acceder y cómo tu sistema garantiza la responsabilidad.

Usa esta guía para ayudarte a planificar la arquitectura de tu identidad y producto.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

Aún necesitas capas de seguridad para mantener tus aplicaciones impulsadas por agentes seguras#

Ya sea una aplicación agentica o no, estas capas de seguridad fundamentales son necesarias para proteger a tus usuarios y sistemas:

• Autenticación multifactor (MFA)

  Previene el acceso no autorizado incluso si las credenciales son comprometidas.

  Ejemplo: Si un agente te ayuda a realizar una acción de alto riesgo, como realizar una transacción o cambiar configuraciones de identidad, debería mantener a un humano en el bucle y usar MFA para confirmar la acción antes de proceder.

• CAPTCHA

  Bloquea abusos automatizados como relleno de credenciales o registros impulsados por bots.

  Ejemplo: Mostrar CAPTCHA después de 3 intentos fallidos de inicio de sesión para prevenir ataques de fuerza bruta.

• Control de acceso basado en roles (RBAC)

  Asegura que los usuarios y agentes solo accedan a lo que se les permite.

  Ejemplo: Un asistente de IA en un espacio de trabajo de la empresa puede leer eventos del calendario, pero no puede acceder a datos de facturación a menos que se le asigne explícitamente un rol más alto.

• Inicio de sesión sin contraseña

  Mejora la experiencia del usuario y reduce el riesgo de contraseñas débiles.

  Ejemplo: Permitir a los usuarios iniciar sesión usando un enlace mágico enviado a su correo electrónico o un aviso biométrico como Face ID.

Estas características se aplican tanto a aplicaciones tradicionales como basadas en agentes, especialmente a medida que los agentes comienzan a operar con datos y sistemas sensibles.

Qué ha cambiado en el mundo agentico#

La autenticación es más importante que nunca#

A medida que emergen agentes y flujos de trabajo multi-agente, estamos viendo nuevos casos de uso donde usuarios, agentes, APIs y servidores MCP interactúan todos. La cantidad y variedad de estos escenarios crecen rápidamente, mucho más que en el pasado.

Cada vez que ocurren estas conexiones, la autorización se vuelve más visible que nunca. Los usuarios deben dar un consentimiento claro y los permisos necesitan ser gestionados cuidadosamente a través de los sistemas. Por eso ahora todos están hablando de mantener un “humano en el bucle” asegurándose de que los usuarios tengan suficiente control y visibilidad sobre lo que los agentes pueden hacer, y para qué se les va a autorizar.

Tu aplicación de IA puede necesitar integrarse con muchos servicios externos#

El ecosistema de MCP se está expandiendo, y eso significa que tu aplicación ya no es solo un servicio autónomo: es parte de una red más amplia y conectada.

Para proporcionar un contexto rico y útil a los LLMs, tus agentes pueden necesitar:

• Acceder a múltiples servidores MCP

  Ejemplo: Imagina un gestor de proyectos de IA que extrae actualizaciones de tareas de Jira, disponibilidad del equipo de Google Calendar, y datos de ventas de Salesforce y cada uno de estos podría estar potenciado por un servidor MCP diferente. Para generar un resumen semanal, el agente debe interactuar de manera segura con múltiples fuentes de datos. Ahí es donde entran en juego la autenticación y la autorización, para proteger cada conexión y controlar cómo se comparte la data.

• Conectarse con APIs y herramientas externas

  Ejemplo: Un agente de soporte al cliente podría necesitar recuperar el historial de pedidos de Shopify, actualizar tickets en Zendesk, y desencadenar flujos de trabajo en Slack. Sin integraciones, el agente se vuelve aislado e ineficaz.

A medida que los agentes asumen más responsabilidades, la integración se convierte en la clave para la utilidad. Tu producto de IA no solo se trata de lo que puede hacer por sí mismo, sino de lo que puede acceder, orquestar y razonar en un ecosistema conectado. Por eso, construir para la interoperabilidad, de manera segura y flexible, es más importante que nunca.

Necesitas abrazar estándares abiertos: OAuth/OIDC son más importantes que nunca#

En la era de la IA, la necesidad de integraciones seguras y flexibles está creciendo. Eso hace que OAuth 2.0 y OIDC sean más importantes que nunca.

Los casos de uso clave incluyen:

• Servidores MCP remotos: Permitir que agentes de terceros accedan de manera segura a tu producto usando tokens delegados.
• Integraciones de terceros: Permitir que otras herramientas o agentes se conecten a tu aplicación (por ejemplo, una plataforma de gestión de proyectos) sin necesidad de credenciales sin procesar.
• Desarrollo de agentes: Construir agentes de IA que actúen de manera segura en nombre de los usuarios a través de servicios.
• Dispositivos inteligentes: Usar OAuth/OIDC para cosas como tomadores de notas impulsados por IA para autenticar a los usuarios y conectar a la nube — especialmente con una interfaz mínima.

Estos protocolos proporcionan acceso seguro, basado en tokens, y consentido por el usuario.

Eso es crítico en un mundo de sistemas agenticos y conectados. Consulta este artículo para ver por qué OAuth y OIDC son importantes

Diseñando para la confianza y la escala en la era del software agentico#

A medida que los productos agenticos evolucionan, los principios centrales de identidad y autorización permanecen iguales, pero el contexto está cambiando. Los agentes introducen nuevas superficies para delegación, consentimiento y acceso. Por eso adherirse a estándares abiertos como OAuth, construir una arquitectura clara, y aplicar prácticas de seguridad sólidas no son solo mejores prácticas, son fundamentales. Diseñar con cuidado ahora significa que tu sistema se escalará con confianza, flexibilidad y confianza en un futuro impulsado por IA.