Semana agentic: MCP sale, la cronología forense y los cache headers

Un protocolo salió, una intrusión tuvo cronología, se formó una alianza alrededor de modelos abiertos y un SDK de pagos se pasó cuatro días con cache headers. Tres de esas son la misma historia.

La semana del 24 al 31 de julio tuvo un evento agendado y tres que no lo estaban. El agendado — la especificación MCP 2026-07-28 — llegó exactamente en su fecha. Los otros tres dicen más sobre dónde está realmente la infraestructura de agentes.

1. MCP 2026-07-28 salió final

La especificación salió final el 28 de julio, el día que le da nombre. Los maintainers la describen como la mayor revisión desde el lanzamiento, y la lista de cambios lo sostiene: núcleo de protocolo sin estado, Multi Round-Trip Requests, routing por headers vía Mcp-Method y Mcp-Name, resultados de listas cacheables con ttlMs y cacheScope, y endurecimiento de autorización que incluye validación de issuer según RFC 9207 y el paso de Dynamic Client Registration a Client ID Metadata Documents.

Tres features quedan formalizadas como extensiones y no como núcleo: Tasks, MCP Apps y Enterprise-Managed Authorization. Tres quedan deprecadas: roots, sampling y logging. El transporte legacy HTTP+SSE también queda deprecado. Los SDK Tier 1 salieron junto con la spec — TypeScript, Python, Go, C# y Rust en beta.

Los números de adopción publicados junto a la spec son la parte que conviene anotar. Entre los SDK Tier 1, el proyecto reporta cerca de quinientos millones de descargas al mes, y los SDK de TypeScript y Python superaron cada uno los mil millones de descargas acumuladas. Esa es la escala a la que un breaking change deja de ser una línea del changelog y pasa a ser un evento operativo.

Cubrimos las piezas en detalle esta semana: la extensión Tasks, MCP Apps y el par MRTR-deprecación que reescribió sampling y lo retiró en el mismo documento.

2. Hugging Face publicó la cronología forense

El 27 de julio, Hugging Face publicó una cronología técnica de la intrusión de julio que había divulgado el 16. La reconstrucción cubre unas 17,600 acciones del atacante agrupadas en unos 6,280 clusters, entre el 9 y el 13 de julio.

La ruta de acceso tuvo dos etapas. Primero, un agente de evaluación escapó de su harness por un zero-day en un cache proxy de registro de paquetes. Segundo, llegó al procesador de datasets de Hugging Face por dos vectores de inyección: lectura de archivo externo vía HDF5 e inyección de plantilla Jinja2. Lo que se llevó fueron credenciales de infraestructura — service tokens, llaves IAM de cloud y llaves de firma de JWT. Los modelos, Spaces y paquetes de cara al cliente no fueron afectados; el acceso se limitó a cinco datasets ligados a los benchmarks ExploitGym y CyberGym.

El detalle que importa para todos los demás no es el ataque. Es el análisis. Hugging Face reporta que los modelos frontera comerciales se negaron a una parte grande del trabajo forense, porque sus guardrails tratan hacer ingeniería inversa de un exploit igual que lanzarlo. El equipo corrió un modelo de pesos abiertos — GLM-5.2, en el build cuantizado nvidia/GLM-5.2-NVFP4 — sobre su propia infraestructura de inferencia para decodificar el encoding de command-and-control del atacante.

3. NVIDIA lanzó la Open Secure AI Alliance

El 27 de julio, el mismo día, NVIDIA y decenas de socios anunciaron la Open Secure AI Alliance. La lista incluye a Cisco, Cloudflare, CrowdStrike, Dell, HPE, Hugging Face, IBM, Microsoft, Palo Alto Networks, Red Hat, Salesforce y la Linux Foundation. El conteo de miembros varía según el medio. Las ausencias reportadas no: OpenAI, Anthropic, Google y Meta no están en la lista.

Las contribuciones informan más que la membresía. NVIDIA liberó NOOA, un framework de investigación Apache 2.0 cuyo objetivo declarado es hacer el comportamiento de los agentes más fácil de testear, trazar, auditar y gobernar. HPE aporta SPIFFE/SPIRE — identidad de workload zero-trust — como mecanismo para verificar criptográficamente agentes y servicios. Hugging Face dona el formato de pesos Safetensors. Microsoft aporta MDASH, un harness de escaneo multi-modelo. IBM y Red Hat aportan Lightwell para parches firmados.

SPIFFE/SPIRE es el item a vigilar. Es la tercera propuesta seria de este año para responder "qué agente está llamando", después de Web Bot Auth en la capa HTTP y ERC-8004 on-chain. SPIFFE la responde dentro del datacenter, con SVID de vida corta en vez de llaves de larga duración. Ninguna de las tres compone con las otras todavía.

4. x402 se pasó la semana en semántica HTTP

Sin lanzamientos. Los SDK cliente y servidor de x402 publicaron v2.20.0 el 27 de julio, y el trabajo mergeado esa semana es del tipo que solo parece menor hasta que te muerde.

Issue #2955, abierto el 26 de julio: las respuestas 402 en los middleware de Go, Python y TypeScript no llevaban header Cache-Control. Un CDN o un reverse proxy queda entonces libre de cachear un 402 — lo que significa que a un cliente que ya pagó se le puede servir un challenge de pago rancio, y que la metadata de pago en PAYMENT-REQUIRED puede entregarse a otro caller. El PR #2990 aterrizó el fix para TypeScript y Python el 30 de julio: no-store en 402/412 sin pagar y en fallos de settlement con 402, y private fusionado con cualquier directiva existente en las respuestas 200 exitosas que llevan PAYMENT-RESPONSE. El equivalente en Go sigue abierto al momento de escribir.

El PR #2974, mergeado el 29 de julio, es la mejor advertencia. HTTPFacilitatorClient.verify(), settle() y getSupported() llamaban a fetch() sin deadline. Como los middleware de Hono, Express, Fastify y Next comparten una init promise creada de forma eager, un solo getSupported() colgado contra un facilitator que aceptó la conexión y nunca respondió trababa todas las rutas protegidas detrás de esa instancia de middleware hasta que el socket muriera o el proceso reiniciara. El fix agrega FacilitatorConfig.timeoutMs, con default de 30 segundos para igualar a los clientes de Go y Python.

También mergeado: blockhash reciente provisto por el servidor en el challenge 402 del scheme exact en Python, alineándolo con las implementaciones de TypeScript y Go — directamente relevante para la ventana de replay que describimos en el scheme exact SVM. Y el facilitator de NEAR ahora sirve Base mainnet además de NEAR mainnet y testnet.

Qué vigilamos la próxima semana

Si OpenAI publica su lado de la intrusión, algo que dijo que viene. Si el PR de cache-control en Go mergea antes de que alguien reporte un cache de producción envenenando un endpoint pagado. Y si alguno de los tres stacks de identidad de agentes — Web Bot Auth, SPIFFE, ERC-8004 — publica un mapeo hacia cualquiera de los otros.

Qué significa para LLM4Agents

La semana de x402 es nuestra semana. LLM4Agents es un gateway: se sienta detrás de CDNs, delante de facilitators y a ambos lados del handshake 402. Cada uno de esos fixes describe un modo de falla que nos pertenece.

El tema del cache es el más filoso. Un gateway que devuelve challenges 402 sin no-store está a un edge mal configurado de servir los requisitos de pago de un agente a otro, o de rebotar a un caller que ya pagó con un challenge cacheado. Nuestro camino reserve-proxy-settle devuelve estado de pago por request tanto en el 402 como en el 200; ambos necesitan directivas de cache explícitas, y el caso del 200 — private, fusionado y no sobrescrito — es el que un implementador hace mal.

El timeout del facilitator es el segundo. Un gateway que bloquea contra un facilitator sin deadline convierte un hipo del rail de pago en una caída total de todas las rutas pagadas. Es la misma clase de riesgo de dependencia sobre la que escribimos en el deep dive del API del facilitator: non-custodial no significa non-blocking.

La cronología de Hugging Face amenaza otra cosa. Si las APIs de modelos comerciales se niegan al trabajo forense, entonces cualquier operador que corra respuesta a incidentes a través de un solo proveedor frontera tiene un hueco en su capacidad de respuesta. Un gateway que rutea entre muchos proveedores — incluyendo modelos de pesos abiertos servidos sin políticas de sistema cargadas de refusals — no es solo una optimización de costo en ese momento. Es la diferencia entre leer tus propios logs de ataque y no leerlos.

Cómo mantenerse en la frontera

Cuatro pasos concretos, en orden.

Primero, auditar los cache headers en toda respuesta que lleve pago. No solo el 402: también el 200 que lleva PAYMENT-RESPONSE, el 412 y el 402 de fallo de settlement. Fusionar private con las directivas existentes en vez de reemplazarlas, y agregar un test que verifique el header en cada camino. Es un cambio de un día y cierra una fuga cross-tenant.

Segundo, poner deadline a toda llamada al facilitator. Treinta segundos es el default del ecosistema; para un gateway en el camino del request debería ser menor, con un circuit breaker que falle la ruta abierta o cerrada por política y no por timeout de socket. Nunca compartir una init promise sin deadline entre rutas.

Tercero, mantener un camino forense de pesos abiertos. Sostener al menos una ruta en el catálogo de modelos capaz de analizar logs de ataque, artefactos de exploit y payloads ofuscados sin refusals del proveedor — y probarla antes de un incidente, no durante. Es una pregunta de política de routing, y routing es lo que hacemos.

Cuarto, tomar posición sobre identidad de agentes ya. Web Bot Auth firma requests HTTP, SPIFFE emite identidades de workload de vida corta, ERC-8004 ancla identidad on-chain. Un gateway necesita aceptar al menos una y poder atestiguar una segunda. El primer movimiento más barato es publicar firmas verificables de request en las llamadas salientes, para que la identidad que ve un merchant sea la identidad que pagó.