Pagaste por Opus. ¿Qué prueba que respondió Opus?

Un agente manda un prompt, recibe tokens y paga por ellos. Cada capa de esa transacción es hoy verificable criptográficamente, menos la única que el agente está comprando de verdad: qué modelo produjo los tokens.

El stack de pagos de agentes pasó dos años volviéndose muy bueno en probar el pago. Las firmas EIP-3009 prueban la autorización. Los facilitators de x402 prueban el settlement. Los recibos atan un hash de transacción a una request. Escribimos sobre casi todo eso.

El stack de confidential computing pasó los mismos dos años volviéndose muy bueno en probar el hardware. Un quote de Intel TDX prueba una CPU genuina en un estado de boot medido. Un reporte de attestation de NVIDIA prueba una GPU genuina con firmware sin modificar y el modo confidential compute activo. Auditamos esa maquinaria desde el lado de la wallet en wallets de agente con attestation TEE.

Junta las dos mitades y obtienes una afirmación que suena hermética: tu prompt corrió dentro de hardware verificado y tienes un recibo firmado. Las dos mitades son ciertas. Ninguna dice qué pesos se cargaron.

Ese hueco no es teórico. El 5 de mayo de 2026, un registro público que testea proveedores de inferencia detectó un gateway sirviendo en silencio un modelo distinto al pedido: entraba deepseek-ai/DeepSeek-V3.1, salía Qwen/Qwen3.5-122B-A10B. La attestation de hardware estaba bien. Siempre iba a estar bien.

Qué dice realmente la attestation de la GPU

Empecemos por abajo. La suite de attestation de NVIDIA tiene tres piezas: el Remote Attestation Service (NRAS), el servicio Reference Integrity Manifest (RIM) que guarda las mediciones golden, y un servicio OCSP para el estado de los certificados. El procesador de seguridad de la GPU produce un reporte firmado; NRAS lo verifica y devuelve un JWT con claims de Entity Attestation Token.

El ejemplo de Hopper con una sola GPU son seis llamadas contra https://nras.attestation.nvidia.com/v4/attest/gpu:

client = attestation.Attestation()
client.set_service_key("YOUR_API_KEY")
client.add_verifier(attestation.Devices.GPU,
                    attestation.Environment.REMOTE,
                    NRAS_URL, "")

evidence_list = client.get_evidence()
result = client.attest(evidence_list)
token = client.get_token()

El token que vuelve trae un eat_nonce para frescura y un conjunto de claims booleanos: x-nvidia-gpu-attestation-report-signature-verified, x-nvidia-gpu-driver-rim-signature-verified y un resultado global x-nvidia-overall-att-result. Lee esos claims literalmente. Dicen que el silicio es genuino, que la VBIOS y el driver coinciden con manifiestos que NVIDIA firmó, y que el modo confidential compute está activo.

No dicen nada del userspace. El procesador de seguridad de la GPU mide firmware, no el proceso que después abre un contexto CUDA. Un análisis académico de la implementación de confidential computing en la H100 encontró que el reporte de attestation lleva 64 registros estructurados, cada uno con una especificación de medición, un campo de tamaño y un hash criptográfico: un inventario de firmware. El mismo trabajo midió qué cambia el modo CC en la frontera de hardware: sobre 4.394.976 lecturas del espacio de registros BAR0 de la H100, el 99,78% devolvió ceros en modo CC, contra un 7,94% devolviendo valores reales con CC apagado. Eso es un firewall haciendo su trabajo, y es ortogonal a qué modelo cargaste.

La cadena de la CPU a los pesos

El lado de la CPU llega más lejos. Una VM confidencial mide su propio boot: primero el firmware, después el kernel y el initrd. Todo lo que logres meter en esa cadena de medición se vuelve atestiguable.

La mayoría de los proveedores usa esto para comprometerse con una configuración de contenedor. La documentación de verificación de modelo de NEAR AI describe el patrón con precisión: el cliente llama a /v1/attestation/report con un nonce hex de 64 caracteres, y la respuesta trae una signing_address generada dentro del TEE, más un intel_quote o un nvidia_payload. El report data ata la signing address y el nonce. El manifiesto de Docker compose se hashea con SHA-256 y se compara contra la medición mr_config del quote verificado.

Es una cadena real. Hardware, estado de boot, config del contenedor y una llave que firma las respuestas, todo atado y todo chequeable por un cliente que nunca confía en el operador. Y aun así se queda a un eslabón. La propia documentación de NEAR es honesta sobre dónde: la attestation establece la confiabilidad del hardware, mientras que la identidad del modelo viene del slug del endpoint o del parámetro de la request. Dicho de otro modo, el nombre del modelo es una afirmación que viaja al lado de una prueba de otra cosa.

El compose hash ayuda solo hasta donde el compose file sea específico. Si fija un digest de imagen y una ruta de pesos, acotaste el problema. Si el contenedor descarga pesos en runtime, o el proceso de serving elige backend por regla de routing, la medición cubre el envoltorio y no el contenido.

Modelwrap: el único mecanismo que llega a los pesos

Tinfoil construyó la excepción. Su diseño Modelwrap cierra el último eslabón en tres pasos.

Primero, los pesos se descargan de Hugging Face en un commit hash específico y se normalizan en una imagen de filesystem EROFS de solo lectura. Segundo, se computa un árbol Merkle de dm-verity sobre esa imagen — bloques de 4KB, hasheados de a pares hasta una raíz única de 32 bytes — y la raíz se le pasa al kernel por la command line. Como la medición del enclave ya cubre la kernel command line, la attestation ahora cubre el árbol de hashes. Tercero, en runtime dm-verity intercepta cada lectura de disco, recorre el árbol y lanza error si un solo bit discrepa de la raíz comprometida.

Lo elegante es que el servidor de inferencia no participa. Como lo dice Tinfoil, vLLM "no tiene idea de que esta verificación está ocurriendo": el chequeo vive en el kernel, debajo de la aplicación, verificando lecturas a medida que pasan.

Vale la pena decir por qué lo construyeron así, porque es la misma razón por la que una firma sobre un model card no alcanza. Firmar los pesos y verificar la firma después de descargarlos protege el artefacto en reposo. Tinfoil asume un adversario más fuerte: un hypervisor malicioso que manipula el contenido del disco después del chequeo de firma. La verificación continua en cada lectura responde a ese threat model; una firma única no.

La arquitectura alrededor sigue la misma disciplina. La arquitectura de attestation fija una versión específica de firmware OVMF para reproducibilidad, embebe el SHA-256 de la config de deployment en la kernel command line, y publica las mediciones esperadas como bundles firmados de Sigstore construidos por un GitHub Action — así los valores contra los que compara un cliente vienen de un transparency log público y no de la API del proveedor. El boot además consulta cada GPU con el verificador local de NVIDIA para confirmar el modo CC, encadenando CPU con GPU. Los clientes verifican la cadena de certificados hasta la raíz del fabricante de la CPU.

Qué encontró el registro

No hace falta creerle a ningún proveedor, porque alguien los está testeando de forma continua. El registro awesome-private-inference puntúa proveedores sobre nueve capas: TDX quote, GPU attestation, report-data binding, key derivation, compose-hash commitment, backend attestation, channel binding, attested session y receipt. Un décimo chequeo, "catalog to served", simplemente pregunta si los modelos que un proveedor anuncia efectivamente responden.

Los hallazgos enseñan más que los puntajes.

Con ese telón de fondo, la sustitución de mayo se lee distinto. Un cliente de cadena cerrada que chequeaba el nombre del modelo detectó un swap silencioso de gateway en vivo el 2026-05-05. No lo detectó el quote de TDX, ni la attestation de la GPU. Lo detectó el único chequeo que comparaba lo pedido contra lo devuelto.

Quién guarda los valores esperados

Una attestation es una comparación. El quote te dice qué mediciones reporta la máquina; algo más tiene que decirte cuáles deberían ser esas mediciones. Esa segunda mitad es donde vive la confianza de verdad, y los tres proveedores que pasan la vara del registro la responden de tres formas distintas.

Tinfoil ancla en un transparency log de software. Las mediciones esperadas las produce un GitHub Action que construye un repositorio público y se publican como bundles firmados de Sigstore, así que cambiar el código sin cambiar los valores esperados publicados queda visible en un log append-only.

NEAR AI ancla on-chain. El registro le acredita Stage 1 por un cliente de cadena cerrada construido sobre eventos ComposeHashAdded, con la implementación del contrato verificada en Sourcify a mayo de 2026. El conjunto de compose hashes aceptables es una lista pública, append-only y on-chain — que para un agente que ya lee estado de cadena es la fuente de verdad más barata posible.

La tercera respuesta, y la habitual, es que el proveedor sirve sus propios valores esperados desde su propia API. Eso no es inútil — todavía detecta un nodo comprometido que el control plane del proveedor no bendijo — pero colapsa al problema que nombra OpenPcc: la entidad que opera el servicio también define qué significa correcto.

La distinción importa especialmente para agentes. Un desarrollador humano verifica una vez, al integrar, y lee un post sobre la postura de seguridad del proveedor. Un agente autónomo verifica en cada sesión, no tiene capacidad de quedarse tranquilo, y necesita que los valores esperados vengan de algún lado que pueda consultar sin pedir permiso. Un transparency log y una lista de eventos on-chain califican. Un endpoint del proveedor no.

Esto también explica por qué el registro puntúa "backend attestation" como capa propia. Un gateway que reenvía un quote upstream sin tocarlo se ve idéntico, en el cable, a uno que lo verificó. El cliente no puede distinguirlos solo por la respuesta, lo que lo vuelve exactamente el tipo de chequeo que se degrada a nada en silencio.

Cuánto cuesta verificar

La objeción razonable es que todo esto es demasiado lento para inferencia por llamada. Las mediciones dicen otra cosa.

El paper de OpenPcc mide serving confidencial de LLMs sobre TEEs de commodity con attestation compuesta de CPU y GPU. El overhead de time-to-first-token contra un baseline no confidencial dio una mediana de 6,73%, en un rango de 0,44% a 28,9% — los peores casos en las celdas más chicas, donde dominan los costos fijos, y por debajo del 1% en las más grandes. El throughput de decode fue de −4,3% a +11,5% contra baseline, mediana 3,8%, con un pico de 4.340 tokens por segundo.

La attestation en sí es un costo fijo que se amortiza. Una única request atestiguada paga 2.032 ms. Con 100 requests por TTL de attestation eso cae a 21,9 ms por request, y pasadas las 1.000 a menos de 2,6 ms. Para un agente que hace una sola llamada esto es punitivo. Para un gateway que sostiene una sesión, redondea a cero.

El diseño del paper también nombra el problema de confianza detrás de toda la categoría. En Private Cloud Compute de Apple y en el equivalente de Google, el operador del servicio de inferencia es también el operador de la raíz de confianza de hardware — así que una vulnerabilidad de hardware o un insider en el operador no tienen mitigación verificable desde afuera. Por eso los transparency logs y los verificadores de terceros importan más que una página de seguridad bien escrita. Y por eso vale citar las exclusiones de alcance: OpenPcc defiende contra un operador malicioso que lea o loguee prompts, y excluye explícitamente los side channels y el prompt injection.

Qué significa para LLM4Agents

Esto pega incómodamente cerca, porque LLM4Agents hace routing. Un gateway que ofrece model fallback es, por construcción, un gateway que a veces devuelve un modelo distinto al nombrado en la request. Describimos la mecánica en cadenas de model fallback: cuando el primario está rate-limited o caído, la request va al siguiente modelo de la cadena, y el agente recibe una respuesta en vez de un 503.

Ese es el mismo acto físico que la sustitución de mayo. La única diferencia es autorización y divulgación. Un fallback que el agente configuró, coteó y puede ver en la respuesta es una feature. El mismo swap, no divulgado, es fraude. Nada en la capa de attestation de hardware distingue los dos casos — lo que significa que la distinción tiene que vivir en la capa de pagos, donde ya tenemos un recibo.

El lado de pagos está más avanzado de lo que se asume. En prompt caching y el scheme upto de x402 argumentamos que un precio por llamada solo es defendible si el recibo explica por qué el número es el número: cache reads contra writes, tokens de entrada y salida. La identidad del modelo es el mismo argumento un nivel más arriba. Un recibo que dice cuánto pagaste sin decir qué corrió está respondiendo la pregunta fácil.

La amenaza que nos importa no es exótica. Un agente bajo un spend cap elige un modelo barato deliberadamente. Un gateway que en silencio sube o baja esa elección rompe el modelo de costos del agente en una dirección y sus supuestos de calidad en la otra. Y un agente con identidad on-chain bajo ERC-8004 acumula reputación a partir de outputs que no puede atribuir a un modelo específico, lo que vuelve esa reputación más ruidosa de lo que parece.

Cómo mantenerse en la frontera

Pasos concretos, en el orden en que rinden.

Primero, nombrar el modelo en la respuesta, siempre. El campo model compatible con OpenAI en una completion debería llevar lo que efectivamente sirvió la request, no un eco de lo que se pidió. Si disparó un fallback, la respuesta lo dice. Esto no cuesta nada y cierra exactamente el hueco por donde pasó la sustitución de mayo. Cualquier gateway que devuelve el parámetro de la request está publicando una afirmación que nunca chequeó.

Segundo, extender el recibo con la identidad del modelo servido. La extensión offer-and-receipt de x402 es deliberadamente privacy-minimal y no lleva detalle de uso. Ese es un default razonable y un mal encaje para inferencia medida. Un recibo debería atar, como mínimo: el modelo pedido, el modelo servido, los conteos de tokens y un hash de la respuesta, firmado por el gateway. Así un cargo disputado es chequeable después de los hechos en vez de ser una cuestión de confianza.

Tercero, correr los chequeos del registro contra nosotros mismos. Las nueve capas son una rúbrica de auditoría gratis. La mayoría no aplica a un gateway sin TEE, pero las dos que más importan sí: catalog-to-served, y un recibo que ate los hashes de request, ruta y response. Ambas se pueden implementar sin nada de confidential computing, y ambas son las que de hecho detectaron fallas reales.

Cuarto, tratar la inferencia atestiguada como un tier de routing, no como un rewrite. Los proveedores con cobertura real ya hablan HTTP compatible con OpenAI. Agregar uno como destino premium — para agentes que lo piden y lo pagan — es una regla de routing más un paso de verificación, no un programa de infraestructura. Los números de overhead de arriba lo vuelven viable hoy para cargas que sostienen sesión. Se cotiza como tier propio y que el agente elija.

Quinto, verificar la attestation upstream antes de reenviar, y decir si lo hicimos. La capa "backend attestation" del registro existe precisamente porque reenviar un quote upstream al cliente no es lo mismo que chequearlo. Si ruteamos a un proveedor atestiguado, verificamos el quote en nuestro borde y registramos el resultado en el recibo. Un upstream sin verificar es algo perfectamente usable y algo pésimo de insinuar.

El punto de fondo es que la industria resolvió primero la mitad equivocada, y la resolvió muy bien. Podemos probar el chip, el firmware, la cadena de boot, el contenedor y el pago. Lo que se está vendiendo es el único elemento sin probar de la cadena. Hasta que un compromiso sobre el modelo servido sea tan rutinario como un hash de settlement, "qué modelo respondió" sigue siendo una cuestión de confianza dentro de una arquitectura construida específicamente para eliminarla.