Agents are workloads: auditoría de WIMSE, WIT-SVID y el stack AIMS

El mundo de la identidad enterprise resolvió en silencio la pregunta de qué es un agente de IA. La respuesta, según el IETF, SPIFFE y un draft co-firmado por AWS, OpenAI y Okta: un agente es un workload. Leímos cada spec de ese stack y verificamos qué se despliega de verdad.

Esta es otra entrega de nuestra serie de auditorías de fuentes primarias. Mismo método que en nuestras revisiones de KYAPay, Web Bot Auth y los registries de ERC-8004: clonar los repos, leer los drafts, consultar los registros y reportar la brecha entre lo que los documentos prometen y lo que existe el 23 de agosto de 2026.

El sujeto esta vez es el stack de workload identity: el working group WIMSE del IETF (Workload Identity in Multi System Environments), el conjunto de especificaciones de SPIFFE que implementa su formato de token, y draft-klrc-aiagent-auth — el documento "AIMS" que mapea todo eso sobre agentes de IA. Esta es la capa de identidad que las empresas probablemente exigirán antes de dejar que agentes autónomos toquen sistemas de producción. Vale la pena saber con precisión qué tan terminada está.

La tesis: agents are workloads

En una reunión interim de WIMSE el 3 de junio de 2026, Pieter Kasselman de Defakto Security presentó el draft de autenticación de agentes con una justificación de una línea registrada en las minutas oficiales: "Agents are workloads - this is why we feel draft is relevant to WIMSE."

Ese framing hace trabajo real. Si un agente es un workload, no necesita un sistema de identidad nuevo. Necesita el que ya reciben los pods de Kubernetes, los runners de CI y los microservicios: un identificador atestado por la plataforma, una credencial criptográfica de vida corta, y cero API keys estáticas. Toda la conversación de identidad agéntica colapsa en infraestructura existente — SPIFFE IDs, X.509 SVIDs, OAuth token exchange — más un perfil delgado encima.

El documento de arquitectura de WIMSE ya contiene la cláusula de agentes. La sección 3.4.11 de draft-ietf-wimse-arch-08 (6 de julio de 2026, 33 páginas), titulada "AI and ML-Based Intermediaries", clasifica los sistemas de IA como "a special case of delegated workloads" y emite dos requisitos normativos que se leen como checklist para plataformas de agentes: las acciones autónomas "MUST be clearly distinguished" de las delegadas — por ejemplo con workload identities o token scopes separados — y en cadenas agente-a-agente "each hop in the chain MUST explicitly scope and re-bind the security context". Sin eso, advierte el draft, "a chain of AI-to-AI interactions could unintentionally extend authority far beyond what was originally granted". Es el mismo problema de delegación multi-hop que examinamos en nuestro post sobre cadenas de delegación SD-JWT, reformulado por un organismo de estándares en lenguaje MUST.

El censo WIMSE: siete drafts, uno a punto de expirar

Al 23 de agosto de 2026, el working group WIMSE tiene seis documentos de WG activos más uno enviado al IESG. La arquitectura (arch-08), el workload identifier (identifier-03, 13 páginas), autenticación por mutual TLS (mutual-tls-02, 9 páginas), autenticación con HTTP Message Signatures (http-signature-06, 22 páginas, refrescado el 4 de agosto), los formatos de credencial (workload-creds-02, 27 páginas, 2 de julio), y el Workload Proof Token (wpt-01, 19 páginas). Un séptimo, workload-identity-practices-06 (11 de agosto), está en AD Evaluation en el IESG en el track Informational.

Dos detalles resaltan del datatracker. Primero, los documentos de proof token y de HTTP signature descienden de una sola spec — draft-ietf-wimse-s2s-protocol pasó por las versiones 00 a 07 antes de dividirse. Segundo, el draft de WPT se tocó por última vez el 2 de marzo de 2026 y expira el 3 de septiembre de 2026 — once días después de este post. Los drafts se reenvían de forma rutinaria y expirar no es morir, pero es una señal de frescura: la mitad proof-of-possession del protocolo lleva casi seis meses sin revisión mientras la mitad de credenciales iteró.

Qué es realmente un WIT

El artefacto central es el Workload Identity Token, definido en WIMSE Workload Credentials (autores de Ping Identity, CyberArk, Defakto, Intuit y Zscaler). Un WIT es un JWT con header typ: wit+jwt cuyo rasgo definitorio es el claim cnf obligatorio: la clave pública del propio workload, ligada al token por la firma del emisor. El mismo documento define un hermano X.509, el Workload Identity Certificate (WIC).

La decisión de diseño que separa este stack de casi todos los tokens que hemos auditado en esta serie: un WIT no es un bearer token, por prohibición. Solo tiene sentido junto a una prueba de posesión de la clave del cnf. El draft compañero WPT define esa prueba: un segundo JWT de vida corta (typ: wpt+jwt) firmado con la clave del workload, con aud (la URI destino), exp, jti, y una familia de claims de binding por hash — wth (hash del WIT), ath (hash del access token OAuth, si existe), tth (hash del transaction token) y oth (otros tokens). El camino de presentación alternativo, draft-ietf-wimse-http-signature, liga el WIT a HTTP Message Signatures de RFC 9421 — la misma primitiva que usa Web Bot Auth de Cloudflare para identidad de crawlers.

Compara eso con los tokens de identidad adyacentes a pagos que hay en producción hoy. Los tokens de KYAPay, que probamos end-to-end contra Skyfire, son JWTs bearer en un header custom — intercepta uno y puedes gastarlo. Los autores de WIMSE atacaron el riesgo equivalente de forma estructural: roba un WIT y tienes un documento público; sin la clave privada no autentica nada.

El WIT-SVID de SPIFFE: mergeado en julio, Incubating, un link placeholder

La convergencia formal entre el track IETF y el ecosistema CNCF aterrizó el 1 de julio de 2026, cuando WIT-SVID.md se mergeó al repo de estándares spiffe/spiffe (PR #362, un solo commit, del maintainer de SPIRE Noah Stride). El repo — creado en agosto de 2017, Apache-2.0, 1.829 stars al momento de la auditoría — ahora lista el WIT-SVID junto al X509-SVID y el JWT-SVID como SPIFFE Verifiable Identity Document de primera clase.

El documento es explícitamente un sub-perfil: "all WIT-SVIDs are WIMSE WITs", no al revés. El perfil SPIFFE es más estricto que el draft upstream en formas que reflejan cicatrices operativas. El header kid es obligatorio (upstream: opcional) porque, como admite el Apéndice C, go-spiffe y SPIRE ya rechazan JWT-SVIDs conformes a spec que no lo traen — "making this a de-facto requirement". El sub debe ser un SPIFFE ID. El claim aud está prohibido de plano. La lista de alg permitidos se fija en nueve valores RSA y ECDSA. Y las reglas de presentación son directas:

// WIT-SVID.md, Sección 5 — Token Presentation
The WIT-SVID MUST NOT be presented as a bearer token.
The WIT-SVID MUST NOT be presented using the HTTP Authorization header.

// y el header JOSE que lleva todo WIT-SVID
{ "alg": "ES256", "kid": "lQSi3hZ…", "typ": "wit+jwt" }

La prohibición del header Authorization tiene una razón concreta: evitar que un WIT-SVID sea tragado por validadores que esperan un bearer token OIDC y aceptado sin prueba de posesión. El claim iss lleva la misma regla defensiva — si está presente, "SHOULD NOT be a value compatible with OpenID Connect Discovery".

La spec está marcada Incubating en la escalera de STABILITY.md de SPIFFE: breaking changes evitados pero permitidos en respuesta a experiencia de implementación, features "typically gated behind a feature flag". Y viene con un cabo suelto honesto: la referencia [8], el documento "Best Practices: SVID Type Comparison" citado dos veces en los apéndices, resuelve a la URL literal https://example.com/todo-svid-type-compare. Un placeholder en un estándar mergeado es algo menor, pero en esta serie aprendimos a leerlos como medidores de madurez — la spec de RSL que auditamos la semana pasada tenía la misma señal en forma más grande.

Lo que se despliega: SPIRE detrás de un flag, go-spiffe en exp/

Las specs son baratas; el código desplegado es evidencia. Clonamos SPIRE (2.496 stars, v1.15.3 publicada el 21 de agosto de 2026) y grepeamos. El soporte de WIT-SVID toca 42 archivos — la CA, el marshaller de bundles, las APIs del server, los nombres de telemetría. Es ingeniería incremental real: el changelog registra soporte del claim iss en un release (#6857) y soporte en el cliente de la API svid.v1 en otro (#7132, #7134).

También está completamente desarmado por defecto. La maquinaria de feature flags en pkg/common/fflag/fflag.go es explícita:

// FlagWITSVID controls if WIT-SVID and the APIs for it are enabled. When set
// to false all WIT-SVID APIs will return Unimplemented.
FlagWITSVID Flag = "wit-svid"
…
FlagWITSVID: false,

go-spiffe, la librería cliente de referencia (v2.8.1, 19 de junio de 2026), cuenta la misma historia en su layout de paquetes: el soporte de WIT vive en exp/svid/witsvid y exp/bundle/witbundle — el namespace experimental. Un resultado más de grep que vale registrar: el string "wimse" aparece exactamente cero veces en todo el codebase de SPIRE. La implementación sigue el perfil SPIFFE, y el linaje IETF es invisible en la capa de código.

AIMS: el perfil de agentes, con OpenAI y Okta en la firma

draft-klrc-aiagent-auth ("AI Agent Authentication and Authorization") es donde la tesis del workload se aplica a agentes en lenguaje normativo. La versión -00 apareció el 2 de marzo de 2026 con cuatro autores de Defakto Security, AWS, Zscaler y Ping Identity. Para la versión -03 (6 de julio de 2026, Informational, expira el 7 de enero de 2027) la firma había crecido a seis: se sumaron Nick Steele de OpenAI y Aaron Parecki de Okta. Esa autoría es en sí un dato — la empresa que opera la mayor superficie de agentes de consumo y la empresa que escribió buena parte de la spec de autorización de MCP están firmando el framing de workload.

El draft define AIMS — Agent Identity Management System — como un modelo conceptual de ocho funciones apiladas, desde identificadores abajo pasando por credenciales, provisioning, autenticación, autorización, observabilidad, política, y compliance arriba. Sus requisitos más filosos están en las dos capas de abajo. Un agente "MUST be assigned exactly one WIMSE identifier, which MAY be a SPIFFE ID". Las credenciales "MUST provide a cryptographic binding to the agent identifier", "SHOULD be short-lived", y las API keys estáticas quedan nombradas como antipatrón de identidad de agentes. También el pass-through de tokens: "It is an anti-pattern for Tools to forward access tokens it received from the Agent to Services or Resources".

En la interim de junio, la recepción del working group fue cálida pero procedimental: no hubo call de adopción, los chairs optaron por medir interés por email, y los participantes notaron que WIMSE "must clear existing work items first". Hay un segundo draft de agentes en la cola con menos momentum: draft-ni-wimse-ai-agent-identity-02 de Huawei ("WIMSE Applicability for AI Agents", 28 de febrero de 2026) propone una "Dual-Identity Credential" que liga criptográficamente al agente y a su dueño humano — una idea que nuestra auditoría de KYAPay encontró expresada como el par de claims hid/aid. No define claims concretos, no pide nada a IANA, y expira el 1 de septiembre de 2026.

El reality check de IANA

Como en cada auditoría de esta serie, verificamos los registros que los drafts prometen llenar. Los documentos WIMSE piden cinco registros: los media types application/wit+jwt y application/wpt+jwt; los HTTP field names Workload-Identity-Token y Workload-Proof-Token; y los claims JWT wth, tth y oth.

Verificado contra IANA el 23 de agosto de 2026: el árbol de media types application tiene 1.795 entradas y ninguno de los dos tipos de token está entre ellas. El registro de HTTP field names tiene 258 entradas; ningún header Workload aparece. El registro de claims JWT tiene 172 entradas; wth, tth y oth están ausentes. Esto es esperable — el registro normalmente llega con la publicación del RFC, y nada de esto es RFC todavía. Pero pone a WIMSE en exactamente la misma madurez de registros que los dieciocho claims sin registrar de KYAPay y el media type sin registrar de RSL: un stack que existe en drafts y código, todavía no en la infraestructura de namespaces de internet. La diferencia es la trayectoria — WIMSE es un working group con charter y un documento ya en el IESG; los otros son individual submissions.

Las costuras: MCP está adentro, x402 y A2A en ninguna parte

La parte más interesante de cualquier auditoría de stack son los bordes. Grepeamos tres repos de protocolo buscando "spiffe" y "wimse" el día de la auditoría.

El repo del Model Context Protocol tiene cuatro hits, todos recientes y direccionales. El post oficial de roadmap de MCP, publicado el 22 de agosto de 2026 — el día antes de esta auditoría — se compromete a "defining an opinionated path for agent identity and delegation through Workload Identity Federation" y a crecer el engagement "with the IETF OAuth and WIMSE working groups". El vehículo concreto es SEP-1933: Workload Identity Federation — abierto el 5 de diciembre de 2025 por PieterKas, el mismo Pieter Kasselman que lidera la autoría de AIMS. Argumenta que los workloads en "Kubernetes, SPIFFE/SPIRE, and cloud-native runtimes" ya tienen JWTs atestados de vida corta y deberían autenticarse ante servidores MCP con esos, en vez de registrar clientes OAuth con secretos estáticos. Sigue abierto, 38 comentarios, última actualización el 17 de agosto. Encaja junto a la maquinaria ID-JAG que cubrimos en nuestra auditoría de Enterprise-Managed Authorization, y el SEP-1046 de MCP (client credentials) ya difiere su perfil JWT a un documento WIMSE, draft-levy-wimse-headless-jwt-authentication.

El lado de pagos es lo opuesto. El repo de x402: cero ocurrencias de cualquiera de los dos strings. El repo de A2A: cero. Y la ausencia es mutua — AIMS menciona MCP una vez, lista A2A solo en sus referencias, y contiene cero menciones de x402, payments o stablecoins en sus cuatro versiones. El stack de workload identity y el stack de pagos máquina-a-máquina se están diseñando en los mismos doce meses, en parte por empresas que se sientan en ambas salas, sin ningún contacto normativo.

Eso importa porque los dos stacks responden preguntas adyacentes con mecánicas incompatibles. x402 autentica un pago: el header X-PAYMENT lleva una autorización EIP-3009 cuya firma prueba control de fondos — prueba de posesión de una clave de wallet, por request, que es la razón por la que walk-up-and-pay no necesita cuentas. WIMSE autentica un caller: prueba de posesión de una clave de workload, por request. Dos sistemas PoP, dos jerarquías de claves, cero binding entre ellas. Nada hoy le permite a un seller afirmar "este pago vino del workload que presentó este WIT" — el claim oth del WPT, hashes de otros tokens del request, es el gancho futuro obvio, sentado en el draft que expira en once días.

Qué significa para LLM4Agents

La adopción enterprise de agentes autónomos va a llegar envuelta en este stack. Cuando el equipo de plataforma de un banco deje que una flota de agentes llame a un gateway de LLMs, la credencial que presente va a parecerse a un WIT-SVID de un deployment de SPIRE, no a una API key estática de un dashboard. AIMS nombra las keys estáticas como antipatrón con todas las letras. Para un gateway como el nuestro, cuya autenticación base es exactamente el patrón API-key-más-wallet, esa es una señal clara de mediano plazo: la escalera de claves que describimos en nuestro threat model de agentes eventualmente necesita un peldaño donde la workload identity del cliente — no un secreto que nosotros acuñamos — sea la raíz de autenticación.

La amenaza es sobre todo para los rieles de identidad alternativos. Si "agente = workload + SPIFFE ID" gana en la empresa, entonces los registries de identidad de agentes a medida — el modelo AgentFacts de NANDA, los tokens de identidad estilo KYA — se comprimen a las capas de discovery y compliance, y la capa de autenticación queda por defecto en infraestructura que las empresas ya operan. La oportunidad es el puente sin construir: nadie ha especificado cómo un workload atestado por WIMSE se convierte en un pagador x402. Un gateway que acepte un WIT para autenticación, lo mapee a una política de gasto, y liquide por llamada en stablecoins estaría componiendo las dos mitades que los organismos de estándares todavía no se presentaron entre sí.

Cómo mantenerse en la frontera

Pasos concretos, en orden. Primero, aceptar JWTs atestados por plataforma como método de autenticación junto a las API keys: validar un JWT de workload emitido por el cliente contra un JWKS configurado es un cambio contenido en el middleware de auth del gateway, y es precisamente el patrón que SEP-1933 propone para servidores MCP — implementarlo temprano posiciona nuestra superficie MCP hacia donde va esa spec. Segundo, ligar identidad a gasto: dejar que un operador fije la política de gasto x402 de una wallet a un workload identifier, de modo que una API key filtrada por sí sola no pueda mover dinero — el sub del JWT atestado debe coincidir. Tercero, instrumentar la costura: loguear el hash SHA-256 de cualquier credencial de workload presentada junto a un pago x402, para que cuando un claim de binding estilo WPT se estandarice, nuestros recibos ya lleven la clave de join. Cuarto, seguir tres fechas — la expiración del draft WPT el 3 de septiembre (¿se refresca la mitad PoP?), el email de adopción de AIMS en la lista de WIMSE, y las release notes de SPIRE por si FlagWITSVID pasa a default-true. Ese flip de flag, no ningún RFC, será el momento en que la workload identity de agentes se vuelva realidad desplegable.