La crisis de identidad de los agentes, cuatro meses después

En febrero escribí que los agentes de IA no tienen identidad, y que eso ya era una crisis de seguridad. El argumento era práctico, no filosófico: les estábamos dando a los sistemas la capacidad de leer archivos, llamar APIs y encadenar herramientas, mientras respondíamos "¿quién está actuando exactamente ahora?" con una cuenta compartida y una API key con más permisos de los necesarios.

Cuatro meses no es nada en seguridad y es una eternidad en este ecosistema. Es hora de hacer lo que, para mí, merece toda afirmación fuerte: volver atrás y ponerle nota a la luz de lo que efectivamente salió.

La versión corta: el diagnóstico se sostuvo, y la industria se puso a construir. Entre marzo y junio, la identidad de los agentes pasó de ser una queja en blog posts a releases de protocolo, features enterprise y papers con resultados medidos. Incompleto, pero ya no ignorado.

¿Qué arregló de verdad A2A v1.0?

Hizo verificable la metadata de los agentes entre organizaciones. El proyecto A2A llegó a su primera especificación estable en marzo, y el contenido de seguridad de ese release es denso: se fueron los flujos legacy de OAuth implicit y password, entraron Device Code (RFC 8628) y PKCE, mTLS se sumó a los esquemas de seguridad y la multi-tenancy pasó a ser nativa.

La pieza que más me importa es la firma de Agent Cards. Bajo v0.x, una Agent Card era una autodescripción; nada impedía que un agente dijera ser lo que quisiera. Con v1.0, las cards se firman con JWS sobre un payload JSON canonicalizado, así que un cliente puede verificar quién publicó la identidad y las capacidades de un agente antes de confiar en la interacción. La spec también estandarizó una forma de que un agente se pause en medio de una task cuando una operación necesita la aprobación de un humano.

El límite, dicho sin vueltas: una card firmada prueba quién publicó la descripción. No prueba nada sobre qué está haciendo ahora mismo una instancia específica en ejecución, ni con qué autoridad delegada. La identidad a nivel de instancia, portable entre stacks, sigue ausente de la spec.

¿Qué trajo MCP para la identidad?

MCP atacó el extremo enterprise del problema. El roadmap 2026 del proyecto convirtió la autorización en una línea de trabajo de primera clase, el equipo de maintainers creció para absorber el volumen de propuestas, y el release candidate de la revisión 2026-07-28 es, según los propios maintainers, el más grande desde el lanzamiento: un núcleo stateless, Tasks y Apps como extensiones, una política formal de deprecación y seis propuestas que endurecen la autorización para acercarla a cómo se despliegan de verdad OAuth 2.0 y OpenID Connect.

La pieza concreta es Enterprise-Managed Authorization, estable desde el 18 de junio. EMA mueve el acceso a servers MCP bajo el identity provider de la organización: iniciás sesión una vez, heredás el acceso a todos los servers aprobados, y lo perdés todo cuando IT te da de baja. Okta es el primer IdP soportado, Anthropic lo activó en Claude, Claude Code y Cowork, Microsoft lo publicó en VS Code, y los servers de Asana, Atlassian, Figma, Linear y Supabase lo soportaban desde el día uno.

Quiero ser preciso sobre qué arregla esto, porque es la mejora práctica más grande desde mi artículo original. El patrón que EMA mata es la cuenta de servicio compartida con un token de larga vida en un archivo .env: sin auditoría, sin scopes, sin forma de revocarlo. Lo que EMA responde es qué personas de esta organización pueden conectarse a qué servers. Lo que todavía no puede responder es qué instancia de agente ejerció qué autoridad delegada dentro de una cadena de herramientas. La gobernanza mejoró muchísimo. La identidad por acción, no.

¿Dónde se adelantó la investigación a los protocolos?

En la capa intermedia que ambos protocolos dejan abierta. Dos papers de marzo se destacan.

PAuth va al origen del sobreprivilegio. Los scopes de OAuth se atan a operadores, no a operaciones: si tu agente necesita mandarle 100 dólares a una persona, OAuth te obliga a otorgar permiso de transferencia por cualquier monto a cualquiera. PAuth deriva la autorización de la task misma, así que enviar "pagale 100 dólares a Bob" autoriza exactamente las operaciones que esa task requiere. En el benchmark AgentDojo, las tasks benignas corrieron sin permisos extra y cada operación de ataque inyectada disparó una advertencia, con cero falsos positivos y cero falsos negativos. Esa es la capa de política a nivel de operación que mi artículo de febrero solo podía bosquejar, hoy corriendo como prototipo.

AIP es lo más cercano a una confirmación directa de la tesis. Arranca afirmando que ni MCP ni A2A verifican de forma nativa la identidad de los agentes, y cita un escaneo de Knostic sobre unos 2.000 servers MCP expuestos a internet en el que ni uno tenía autenticación. Su propuesta, los Invocation-Bound Capability Tokens, fusiona identidad, autoridad atenuada y procedencia en una única cadena criptográfica append-only, con bindings para MCP, A2A y HTTP plano. El costo medido: 2,35 milisegundos en un despliegue multiagente en vivo, y una tasa de rechazo del 100% sobre 600 intentos adversariales. Ya existe un Internet-Draft en la IETF, una señal clara de a qué nivel se movió esta conversación.

¿Cómo envejecieron las afirmaciones de febrero?

Bien, en general. Hice cinco; les pongo nota una por una.

Los agentes no encajan en los modelos de identidad de humanos, servicios ni bots. Se sostuvo. Todos los papers serios que aparecieron desde entonces parten exactamente de esa insuficiencia.

La delegación en nombre de un usuario está mal modelada. Se sostuvo, con matices. MCP sigue construido sobre OAuth 2.1 estándar; EMA hizo que operar esos flujos sea muchísimo mejor sin introducir una identidad nativa de agente. Mejor plomería sobre el mismo hueco conceptual.

Componer múltiples herramientas crea privilegios que nadie aprobó. Se sostuvo, y el ecosistema se puso al día: las anotaciones de herramientas se volvieron un vocabulario de riesgo, el tool poisoning quedó nombrado como un vector crítico del lado del cliente, y A2A agregó autorización dentro de la task. Hoy hay consenso sobre dónde viven los ataques.

No se puede auditar de forma confiable quién hizo qué. Arreglado en parte. Las cards firmadas y los registros al estilo AIP suman procedencia, pero todavía no domina ningún estándar de auditoría por instancia entre stacks.

La solución es un stack en capas, no un parche. Se sostuvo por completo. MCP está construyendo autorización, A2A está construyendo confianza declarativa, y la investigación está construyendo el acotamiento por task y la delegación verificable. Nadie está publicando una solución única porque no existe.

¿Cuál es la pregunta correcta para lo que queda de 2026?

No es "¿tienen los agentes una crisis de identidad?"; ese debate terminó y las specs lo dicen por escrito. La pregunta es qué capas existen y cuáles siguen siendo aspiracionales.

Mi mapa actual: la autorización enterprise para MCP existe y funciona. Una base real para la confianza entre agentes existe en A2A v1.0. El acotamiento por task y la delegación verificable existen como prototipos medidos. Lo que no existe es la capa que une todo: identidad por instancia en ejecución, autoridad que se atenúa bien salto a salto, y procedencia de punta a punta que no exija confiar en cada intermediario.

En febrero escribí que el mejor momento para cerrar esta brecha era antes del despliegue. La actualización que le debo a esa frase: ya no partimos de cero. El ecosistema hoy reconoce, en specs y en código publicado, que un agente no es ni un usuario raro ni un servicio más. Hasta que la identidad verificable, la autoridad acotada y la procedencia auditable sean el default en producción, la crisis no terminó. Empezó a profesionalizarse.

Disclosure: fundé Oktsec, que construye seguridad para el trabajo con agentes de IA, así que tengo un interés obvio en que este problema se resuelva. Es también la razón por la que lo sigo de cerca.