Semana agentic: lo que decide el servidor

Esta semana Cloudflare empezó a cobrar inferencia vía x402 detrás de un filtro por país. Solana recibió canales de pago x402 en los que el vendedor puede firmar el medidor. Y dos SDKs de MCP corrigieron clientes que dejaban al servidor elegir adónde iban los secretos OAuth. Todo se reduce a una pregunta: ¿qué le deja decidir el cliente al servidor?

Entre el 25 de septiembre y el 2 de octubre se mergearon 19 pull requests en x402-foundation/x402. phdargen fue autor de 5, notorious-d-e-v de 4 y PhilBot402 de 3. mintlify[bot] y JulienKervarrec tuvieron 2 cada uno, y NotMcAfee, Bartok9 y lgalabru uno cada uno. El release del 29 de septiembre publicó @x402/core 2.28.0, x402 2.25.0 para Python y Go v2.28.0. La mayoría de las líneas nuevas fueron a un solo scheme en una sola chain.

La semana pasada la pregunta era qué compró exactamente un pago. Esta semana es quién fija los términos después de que el cliente firma: el precio final, el camino del reembolso, el código que corre en el navegador, el token endpoint. Cada vez, el protocolo acota una cosa y confía en otra.

1. Cloudflare abre el gateway y cobra por inferencia

El 30 de septiembre, Cloudflare pasó la Monetization Gateway de lista de espera a beta cerrada. Cubrimos el anuncio de julio en nuestro post sobre enforcement en el edge. Los dueños de dominios ya pueden cobrarles a los agentes por sitios web, APIs, herramientas MCP y datasets. Las reglas de precio matchean la URL, los headers o los query parameters. Cloudflare se encarga de la verificación y el settlement "a través del x402 Facilitator de Coinbase", en USDC sobre Base. La beta está abierta a "vendedores y compradores elegibles con base en EE.UU.".

Hay cuatro clientes en producción. Ceramic.ai vende búsqueda web a 0,001 USDC por consulta, según su repo de ejemplo, sin cuenta y sin API key. Su documentación dice que el cliente firma exactamente el monto cotizado y que las búsquedas fallidas nunca se liquidan. Stocktwits vende señales de sentimiento por request. API2PDF usa precio variable: cotiza lo máximo que podría costar un request y después liquida el consumo real. Su registro anterior pedía una tarjeta después del primer mes, y según Cloudflare más de la mitad de los usuarios abandonaba en ese paso.

El cuarto cliente es el que más nos importa. El propio AI Gateway de Cloudflare ahora acepta x402 para inferencia. La documentación de Machine Payments muestra la llamada:

curl -iX POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Payment-Method: x402" \
  --header "Content-Type: application/json" \
  --data '{"model": "z-ai/glm-4.7-flash", "input": {...}}'

La documentación enumera las condiciones. El header es específico de Cloudflare. El cliente igual necesita un API token de Cloudflare, tener base en Estados Unidos y una tarjeta registrada. Solo POST /ai/run es elegible, con cuatro modelos abiertos: z-ai/glm-4.7-flash, google/gemma-4-26b-a4b-it, openai/gpt-oss-20b y alibaba/qwen3.8-27b. La mayoría usa el scheme upto. La wallet firma un máximo. Cloudflare ejecuta la llamada y liquida el costo real, "que no puede superar el máximo autorizado". El precio viene del origen. Cloudflare lo llama origin-controlled pricing: la Monetization Gateway le pregunta al módulo de precios de AI Gateway cuánto cobrar.

Sondeamos ambos caminos desde Finlandia el 2 de octubre. Sin el header x402, una llamada sin autenticar a /ai/run devuelve 401. Con el header, el mismo request devuelve 403, y el endpoint de búsqueda paga de Ceramic devuelve el mismo body de 60 bytes:

# /ai/run, sin header x402, sin token
401 {"result":null,"success":false,"errors":[{"code":10000,"message":"Authentication error"}],"messages":[]}

# mismo request + Payment-Method: x402
403 {"error":"forbidden","message":"disallowed visitor country"}

# POST https://api.ceramic.ai/search, sin pago
403 {"error":"forbidden","message":"disallowed visitor country"}

El chequeo de país corre antes de la autenticación y antes del 402, así que un agente fuera de Estados Unidos nunca ve un precio. API2PDF se comportó distinto: devolvió su propio 401 por falta de API key, no el 402 que muestra el post de Cloudflare. En este producto, x402 es un medio de pago atado a una cuenta, no un reemplazo de la cuenta. El servidor decide quién puede ver el precio y, después de la llamada, cuánto costó.

2. Solana recibe batch-settlement, con un medidor opcional firmado por el vendedor

El PR #3164 implementa el scheme batch-settlement para Solana en TypeScript. Ludo Galabru lo abrió el 14 de agosto y se mergeó el 25 de septiembre: +33.778 líneas en 165 archivos, con 426 tests en 22 archivos. La spec se había mergeado el 21 de agosto. El #3603 de phdargen lo portó a Go (+38.781 líneas, 241 archivos), y salió en Go v2.28.0 el 29 de septiembre. Cubrimos el scheme genérico en julio: depositar una vez, firmar commitments acumulativos, redimir después en batch.

En Solana corre sobre el programa payment-channels, el mismo que ya usa upto en SVM. La spec fija su id en mainnet como CHNLxYvVA28MJP9PrFuDXccuoGXAx7jBacfLEkahyGsX y prohíbe negociarlo desde el 402. El cliente abre un canal con un depósito y firma vouchers Ed25519 acumulativos. El servidor verifica cada voucher off-chain, sirve el request y después redime el último voucher on-chain.

Los roles están repartidos con cuidado. El pago queda fijado al abrir el canal: 100% a payTo, comprometido con un distribution hash y verificado de nuevo en distribute. El facilitator paga fees y renta, y ocupa el asiento de payee del canal con participación cero. Puede sellar un canal abandonado y recuperar su renta, pero no puede avanzar el monto liquidado. El plazo de cierre forzado debe estar entre 15 minutos y 30 días. Los vouchers nunca expiran.

Lo nuevo es el server mode. Con voucherSigner: "server", la clave del operador pasa a ser el firmante autorizado del canal on-chain. El monto anunciado se vuelve un techo, y el operador firma el cargo acumulado real después de servir. La spec es directa sobre la consecuencia:

"Por lo tanto, el operador puede llevarse hasta el depósito completo sin otra firma del cliente ni prueba de que entregó el servicio."

Y lleva la lógica hasta el final. En server mode, sobredimensionar el depósito "es exposición a robo", "no simplemente fondos del cliente bloqueados temporalmente". El cliente debe mantener una allowlist local de claves de operadores confiables, "nunca por 402", y debería ponerle un tope al escrow por operador. Un cierre forzado tampoco es defensa: durante el período de gracia el operador todavía puede enviar un voucher por hasta el depósito completo, así que la spec lo llama "una carrera". Y: "El precio medido por el servidor supone un operador honesto". El release de Go agrega un fallback para este caso. Si un cliente no confía en una oferta firmada por el servidor, un nuevo handler de fallos de creación reintenta con una firmada por el cliente.

El programa está vivo. El 2 de octubre era un programa ejecutable y actualizable en mainnet. Registró poco más de 100 transacciones diarias el 30 de septiembre y el 1 de octubre, un conteo que incluye a todos los usuarios del programa. El código sigue moviéndose. El #3637 y su port a Go, el #3664, se mergearon el 2 de octubre y todavía no tienen release. Corrigen los reembolsos de canales firmados por el servidor después de reiniciar el cliente. Con el discovery de canales apagado, el cliente reescribía los requisitos a client mode antes de leer el storage y fallaba con NoBatchChannelToRefundError.

3. Mergeado no es publicado: el paywall de x402 era un build de mayo

El PR más silencioso de la semana es el que más dice sobre higiene de releases. El #3599, de notorious-d-e-v, agrega una opción rpcUrls al paywall de Solana. El autor declara que trabaja en PayAI, un facilitator. El disparador es el issue #867, abierto desde el 25 de diciembre de 2025. El paywall lee el saldo USDC del pagador desde el navegador contra api.mainnet-beta.solana.com, y ese endpoint devuelve 403 a los requests con header Origin de navegador. Los pagos en mainnet a través del paywall integrado se cortaban en "Unable to read your USDC balance".

Al arreglarlo, el autor encontró algo más grande. La publicación corre tsup, no el build del paywall, y el check de CI que verifica los templates embebidos llevaba desde mayo solo en modo manual. Así que los templates commiteados se reconstruyeron por última vez el 16 de mayo (#2160). Los fixes del paywall mergeados después nunca llegaron al bundle publicado. Entre ellos, el fix de los network IDs CAIP-2 de Algorand (#2931, 23 de julio), el manejo de spend controls (#3124, 13 de agosto) y los links de faucet de Celo Sepolia y Sei.

Verificamos la afirmación contra lo que instalan los vendedores. En el repositorio, los cuatro archivos de template que revisamos pasan del 16 de mayo directo al 2 de octubre. En el @x402/paywall 2.28.0 publicado el 29 de septiembre, setSpendControls aparece cero veces; el template regenerado lo tiene tres veces. En el mismo paquete, la tabla de lookup de USDC dentro del bundle de navegador de Algorand sigue indexada por el network ID viejo, algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=. Desde el #2931, las constantes de red del propio SDK usan algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k. La versión del paquete decía 2.28.0. El código del navegador decía mayo.

El fix regenera los nueve templates y corre el check en cada pull request que toque el código del paywall. También corrige un camino de Python que ignoraba faucet_urls. Sale con el próximo release.

4. Los clientes MCP dejaban al servidor elegir el token endpoint

El 28 de septiembre el SDK de Python de MCP publicó el GHSA-qx49-fqc8-xw99, con severidad alta (7,5). El cliente OAuth dejaba que el servidor MCP decidiera adónde iban las credenciales del cliente, porque faltaban dos chequeos. El issuer del authorization server no se validaba en todos los caminos de discovery, y las credenciales guardadas no estaban atadas al servidor al que pertenecían. Un servidor malicioso tenía dos caminos. Podía nombrar su propio authorization server en su protected resource metadata. O podía no publicar metadata y servir la suya, nombrando como issuer al servidor real del usuario. En cualquiera de los dos casos recibía el client_secret, el authorization code y el code_verifier de PKCE destinados al servidor real.

Las versiones afectadas son mcp 1.9.1 a 1.29.1 en todos los caminos, y 2.0.0 a 2.1.1 en el fallback legacy y en respuestas 403 insufficient_scope. Los fixes son 1.30.0 y 2.2.0. Actualizar no alcanza para proteger a los providers desatendidos. ClientCredentialsOAuthProvider y PrivateKeyJWTOAuthProvider siguen al authorization server que anuncie el servidor MCP hasta que pases issuer=. En 1.30.0, omitirlo emite un DeprecationWarning, que Python oculta por defecto. Los registros guardados antes del fix quedan sin atar y hay que borrarlos.

El SDK de TypeScript publicó la misma clase de bug el 30 de septiembre como GHSA-6qxp-vccf-f47h (CVE-2026-104850), también 7,5. Ahí un servidor podía llevarse el refresh_token y el client_secret guardados sin interacción del usuario. Los fixes son @modelcontextprotocol/sdk 1.31.0 y @modelcontextprotocol/client 2.2.0, y los providers incluidos también necesitan expectedIssuer.

Un segundo advisory de Python, el GHSA-rwrf-2pqf-9j8j (medio), tiene la misma forma. Cuando un servidor declaraba un outputSchema para una herramienta, el cliente validaba los resultados con el resolver por defecto de jsonschema. Ese resolver abre cualquier $ref que no puede resolver localmente, sea http, https o file. El fetch corría de forma sincrónica y sin timeout, así que un solo servidor podía congelar todas las sesiones del proceso. Para agentes desatendidos, el advisory lo puntúa 7,5. El 30 de septiembre siguieron dos advisories más de Python: sesiones Streamable HTTP que nunca se liberaban por defecto (CVE-2026-59951) y bodies de request leídos sin límite de tamaño.

5. Items menores

La x402 Foundation tiene director ejecutivo. El 1 de octubre la Linux Foundation nombró a Michael Hursta en el cargo y dijo que la fundación tiene más de 50 miembros activos. Hursta dirigió payment acceptance and experience para Norteamérica en Amazon, encabezó la práctica de asesoría en pagos empresariales de PwC y pasó más de una década en First Data. En sus palabras, x402 es una oportunidad "de construir esa próxima capa como infraestructura abierta y no como otro sistema de pagos propietario".

Mastercard puntúa si hubo un agente. El 30 de septiembre, Mastercard sumó servicios de confianza e inteligencia a Agent Pay. El primero, en pruebas en Estados Unidos, es "un puntaje de probabilidad que indica qué tan probable es que una transacción haya sido iniciada por un agente de IA". Cloudflare y Skyfire figuran como partners. Una red de tarjetas tiene que estimar si hubo un agente involucrado. Un rail x402 parte del otro extremo: sabe que una wallet firmó por este request, y tiene que averiguar quién está detrás de la wallet. Ambos lados convergen en el mismo problema de identidad.

XRPL cuenta 10 millones. J. Ayo Akinyele, head of engineering de RippleX, dijo que se liquidaron más de 10 millones de pagos x402 en el XRP Ledger, menos de tres meses después del primer millón. Ubicó el promedio de siete días en unos 500.000 diarios, según reportó The Crypto Basic. Es un conteo, no un valor. La declaración no da volumen en dólares.

Nuevos assets por defecto. v2.28.0 agrega Arc mainnet (eip155:5042) y Arc Testnet (eip155:5042002), con USDC nativo en 0x3600000000000000000000000000000000000000 como asset por defecto (#3590). El autor verificó el dominio EIP-712 (USDC, versión 2) contra el DOMAIN_SEPARATOR() de cada contrato en ambas redes. También se sumó USDC en Monad testnet (#3570). Por otro lado, el extra svm de Python ahora tiene tope en solana<0.40 (#3573). La versión 0.40 eliminó el cliente RPC sincrónico que importa el SDK, así que las instalaciones nuevas venían fallando.

El contador de x402.org no se movió. El 2 de octubre la home seguía mostrando, para los últimos 30 días, 75,41M transacciones, $24,24M de volumen, 94,06K compradores y 22K vendedores. Son las mismas cuatro cifras que mostraba el 25 de septiembre. Una ventana móvil de 30 días que queda congelada una semana es una foto, no un feed. Si la citas, cita también la fecha.

Qué significa para LLM4Agents

Cloudflare ahora es un comparable directo. Opera un marketplace de modelos y acepta x402 por inferencia, con upto y precios fijados en el origen. Esa es la forma que venimos defendiendo. Por ahora pesan las barreras: una cuenta, una tarjeta, ubicación en EE.UU., cuatro modelos abiertos y un endpoint específico de Cloudflare. Los agentes sin cuenta, fuera de Estados Unidos o que llaman a una ruta compatible con OpenAI quedan hoy fuera de ese producto. La brecha es real, pero es una restricción de beta, no una decisión de diseño. Conviene planificar como si se fuera a cerrar.

El 403 que llega antes del 402 es el detalle del que hay que aprender. Un 402 es la forma en que un agente descubre un precio. Si un chequeo de política corre primero, un agente fuera de la política no puede distinguir "no puedes comprar" de "esto cuesta X". Para el vendedor, mantener el precio legible es barato. Para el comprador, decide si puede rutear a otro lado o si simplemente falla sin saber por qué.

El server mode describe nuestra propia posición. LLM4Agents mide tokens y descuenta el costo de cada llamada de un saldo prepago fondeado en Solana o Polygon. El agente confía en nuestro medidor, igual que un cliente en server mode confía en su operador y un comprador de AI Gateway confía en el módulo de precios de Cloudflare. El consejo de la spec nos aplica desde el lado del vendedor: mantener baja la exposición, ofrecer una alternativa verificable y hacer posibles los chequeos posteriores. Nuestro modelo de saldo ya limita la exposición a lo que el agente depositó. La verificabilidad es lo que hay que reforzar.

El hallazgo del paywall y los advisories de MCP enseñan una misma lección en dos capas. Lo que hace un componente depende de lo que realmente se construyó y de lo que le dijo el otro lado, no del string de versión ni del changelog. Nuestro gateway está entre los agentes y muchos proveedores upstream. Cualquier lugar donde una respuesta upstream decide adónde mandamos algo, como un redirect, una URL de metadata o una referencia de schema, es un lugar donde fijar el destino.

Cómo mantenerse en la frontera

Cinco pasos, en orden.

Primero, parchear los clientes MCP esta semana. Esto aplica a cualquier componente que actúe como cliente MCP sobre HTTP con OAuth. En Python, pasar a mcp 1.30.0 o 2.2.0 y configurar issuer=. En TypeScript, pasar a @modelcontextprotocol/sdk 1.31.0 o @modelcontextprotocol/client 2.2.0 y configurar expectedIssuer. Borrar los registros guardados sin issuer. Rotar cualquier secreto que se haya usado contra un servidor que no controlamos.

Segundo, poner el medidor en el recibo. Devolver con cada llamada los conteos de tokens, los precios unitarios y el cargo resultante, firmados, para que un agente pueda recalcular lo que descontamos. La spec de batch-settlement describe los chequeos del cliente en server mode como "detección y contabilidad post-hoc". Tenemos que volver trivial esa detección. De paso, sumar un check de CI que confirme que lo que publicamos es lo que construimos. El bundle del paywall muestra por qué.

Tercero, mantener el precio legible. Devolver los payment requirements antes de cualquier chequeo de política que no sea sobre el request en sí. Si una regla bloquea a un comprador, decirlo en un error legible por máquina que explique el motivo, no con un simple 403.

Cuarto, prototipar upto con precio en el origen. El diseño de Cloudflare es la referencia: un máximo firmado por llamada y después el settlement del uso real. Nuestro módulo de precios actual puede calcular ese máximo a partir de max_tokens y los precios del modelo. Correrlo en una testnet antes de cualquier exposición en mainnet. Defendimos este scheme en el deep dive de upto, y Cloudflare acaba de ponerlo en producción para inferencia.

Quinto, seguir batch-settlement en Solana, primero en client mode. Solana es uno de nuestros rails de depósito, y un canal que se abre una vez y se va consumiendo con vouchers encaja con agentes que hacen muchas llamadas pequeñas. Esperar un release de TypeScript que incluya el #3637 y después probar canales firmados por el cliente en devnet. Tratar el server mode como apagado salvo que un agente ponga explícitamente nuestra clave de operador en su allowlist con un depósito acotado. La spec fija esa misma regla para todo operador.