La revolución de los agentes de inteligencia artificial ha avanzado a un ritmo vertiginoso, pero con ella ha llegado un desafío que muchos pasaron por alto hasta hace poco: la identidad. Durante meses, sistemas capaces de leer archivos, invocar APIs y encadenar herramientas operaban sin una respuesta clara a la pregunta más básica de seguridad: quién está actuando exactamente ahora. Las cuentas compartidas, las claves API reutilizadas y los permisos excesivos eran la norma. Sin embargo, desde principios de 2026, el panorama ha cambiado. La capa de identidad para agentes de IA se está construyendo, no de forma aislada, sino como un ecosistema de protocolos, estándares empresariales e investigación académica que por fin reconocen el problema.
Empresas como Q2BSTUDIO, especializadas en desarrollo de software y tecnología, observan de cerca esta evolución porque la implementación de agentes seguros es crítica para sus clientes. No basta con que un agente ejecute tareas; debe hacerlo con una identidad verificable, autorizaciones limitadas y un registro de auditoría claro. La combinación de protocolos como A2A y MCP, junto con propuestas académicas como PAuth y AIP, está sentando las bases de una infraestructura que promete transformar la seguridad en entornos empresariales multiagente.
El primer hito relevante llegó en marzo de 2026 con la versión 1.0.0 del protocolo A2A (Agent-to-Agent). Esta especificación eliminó flujos OAuth obsoletos, introdujo soporte para Device Code y PKCE, y sobre todo formalizó las Agent Cards firmadas criptográficamente. Ya no basta con que un agente se autoproclame; ahora los clientes pueden verificar la identidad y metadatos del agente antes de confiar en una interacción entre organizaciones. Es un avance significativo, pero limitado: la tarjeta demuestra quién publicó la descripción del agente, no qué está haciendo una instancia concreta en un momento dado. La identidad por instancia, portable entre pilas heterogéneas, sigue siendo una asignatura pendiente.
Por otro lado, el protocolo MCP (Model Context Protocol) centró sus esfuerzos en la autorización. En mayo de 2026 publicó su mayor revisión, y en junio lanzó la Autorización Gestionada por Empresa (EMA). Esta característica permite a las organizaciones controlar el acceso a los servidores MCP a través de su proveedor de identidad central (IdP). Los usuarios inician sesión una vez y heredan el acceso a todos los servidores aprobados, sin pantallas de consentimiento OAuth por aplicación. Implementaciones como las de Anthropic en Claude, Microsoft en VS Code y múltiples servidores de Asana, Atlassian, Figma, Linear y Supabase demuestran que EMA resuelve un problema real: reemplazar las cuentas de servicio compartidas con tokens de larga duración por un modelo gobernado por el IdP, con reglas de acceso condicional y desaprovisionamiento automático al salir de la organización. Sin embargo, EMA responde qué humanos pueden conectarse a qué servidores, no qué instancia de agente recibió qué autorización delegada para realizar una acción específica dentro de una cadena de herramientas.
Mientras los protocolos empresariales endurecían sus bordes, la investigación académica atacó el corazón del problema. PAuth, presentado en marzo de 2026, propone una autorización implícita con alcance de tarea. En lugar de conceder un permiso genérico de transferencia que cubre cualquier cantidad a cualquier destinatario, al enviar una tarea en lenguaje natural solo se autorizan las operaciones concretas necesarias para ejecutarla fielmente. En la evaluación AgentDojo, todas las tareas benignas se completaron sin permisos extra y todos los ataques inyectados generaron alertas, con cero falsos positivos y cero falsos negativos. Por su parte, AIP (Agent Identity Protocol) va aún más lejos: propone tokens de capacidad vinculados a la invocación, una cadena de solo adición que fusiona identidad, autorización atenuada y procedencia en un solo artefacto criptográfico. Con bindings para MCP, A2A y HTTP plano, su sobrecarga medida es de 2,35 ms en un despliegue multiagente real, y rechazó el 100% de 600 intentos adversariales. AIP es ahora un Internet-Draft del IETF, lo que indica hacia dónde se dirige la conversación.
Desde la perspectiva de una empresa de servicios cloud AWS/Azure como Q2BSTUDIO, estos avances tienen implicaciones prácticas inmediatas. La implementación de agentes de IA en la nube requiere no solo escalabilidad, sino también un modelo de identidad que permita auditorías fiables. Actualmente, la mayoría de las organizaciones que despliegan agentes en entornos productivos siguen usando cuentas de servicio compartidas, un enfoque que dificulta el rastreo de quién hizo qué. La combinación de EMA para la gobernanza empresarial y protocolos como AIP para la delegación verificable podría cerrar esa brecha. Sin embargo, aún no existe una capa estándar que una la identidad por instancia en ejecución, la autorización que se atenúa correctamente a través de delegaciones de múltiples saltos y la procedencia auditable sin confiar en cada intermediario.
La evolución de la seguridad en agentes de IA no es un problema que se resuelva con un solo parche. Es una pila de capas que se están construyendo en paralelo: la autorización empresarial para MCP ya funciona; la confianza entre agentes con A2A v1.0 tiene una base sólida; las propuestas de alcance de tarea y delegación verificable están medidas y validadas. Lo que falta es el pegamento que las convierta en un comportamiento predeterminado interoperable. Hasta que cada instancia de agente tenga una identidad verificable, una autoridad acotada y una procedencia auditable como parte de su funcionamiento normal, la crisis de identidad de los agentes no habrá terminado. Pero al menos, por primera vez, el ecosistema admite en especificaciones y en código que un agente no puede seguir siendo tratado como un usuario extraño o como otro servicio más. La capa de identidad se está construyendo, y las empresas que inviertan hoy en una arquitectura preparada para ello estarán mejor posicionadas para el futuro de la inteligencia artificial.
