zkTLS para agentes de IA: demostrar datos web sin exponer secretos

zkTLS permite que un agente de IA demuestre de dónde proceden datos web privados y revele solo los campos que necesita un verificador. Puede convertir una respuesta HTTPS autenticada en evidencia como «esta cuenta está activa» o «esta compra se completó», sin exponer la cookie de sesión, el registro completo ni datos irrelevantes de la respuesta.

La promesa es más limitada que «agentes trustless», y por eso resulta útil. La investigación fundacional DECO mostró cómo demostrar la procedencia de datos TLS sin hardware de confianza ni cambios en el sitio de origen (ACM CCS, 2020). En 2026 la pregunta comercial ya no es si los web proofs son posibles. La pregunta es si la confianza restante, la latencia, la fragilidad de la fuente y el coste operativo encajan en el flujo del agente.

Esta guía responde a esa decisión concreta. Para el panorama general, consulta nuestra guía de zero-knowledge en producción para 2026. Los casos de identidad, KYC y supply chain están en la guía separada de usos de zero-knowledge fuera de cripto.

¿Qué es zkTLS para un agente de IA?

zkTLS es una familia de protocolos que hace verificables para otra parte determinados hechos de una sesión HTTPS. El sitio suele ver una conexión TLS normal y no necesita añadir una API de atestación. TLSNotary, proyecto open source de Privacy Stewards of Ethereum de la Ethereum Foundation, describe un flujo en el que el prover solicita datos mientras un verifier participa en la sesión TLS, seguido por divulgación selectiva y verificación (documentación de TLSNotary).

1. Petición: el dispositivo del usuario o el agente accede a una fuente HTTPS identificada. El material de autenticación queda en la parte privada.
2. Testigo: un verificador participa mediante MPC-TLS u observa la ruta cifrada en modo proxy.
3. Compromiso: el protocolo vincula campos concretos de petición y respuesta a la sesión observada.
4. Divulgación: el prover revela un valor, un fragmento redactado o un predicado derivado y oculta lo demás.
5. Decisión: la aplicación verifica la prueba o la atestación de un notario de confianza antes de permitir la siguiente acción.

El límite de privacidad debe ser preciso: zkTLS puede ocultar credenciales al verificador posterior cuando la prueba se genera en el dispositivo del usuario. No las oculta automáticamente al runtime local del agente, a la extensión del navegador ni a un TEE que realice la petición. Dibuja dónde existe texto plano antes de llamar privada a la arquitectura.

¿Qué puede demostrar realmente un agente de IA?

Una afirmación zkTLS útil vincula una fuente identificada, un campo concreto de la respuesta, un sujeto y una ventana temporal. «El agente revisó un sitio» es demasiado vago para autorizar dinero o acceso a datos.

La última columna marca el límite de producto. zkTLS demuestra procedencia del transcript y divulgación fiel. No hace verdadera una mala fuente, reciente una página antigua, seguro un prompt ni correcta una decisión del agente.

¿Es zkTLS trustless o verificable públicamente?

Ninguna afirmación zkTLS portable está libre de confianza. Un verificador debe participar mientras ocurre la sesión TLS, porque de otro modo el cliente conoce las claves simétricas y podría fabricar el transcript. Si tu backend está online y ejecuta el verificador, puede confiar directamente en el resultado. Si lo necesitan un smart contract, un auditor posterior o muchos consumidores, un verificador delegado firma una atestación y esos consumidores confían en el notario.

La explicación de TLSNotary de junio de 2026 llama a esto un límite de designated verifier: zero knowledge protege la divulgación selectiva e impide editar el fragmento mostrado, pero quien no participó sigue dependiendo de quien presenció la sesión en vivo (TLSNotary, junio de 2026). Trata la clave del notario, el quorum, la revocación y el audit trail como infraestructura de producción, no como defaults del SDK.

¿Por qué es relevante zkTLS ahora?

Tres cambios lo hacen actual para equipos de agentes en 2026:

• El caso pasó de pruebas de identidad a recibos de acciones. Los agentes leen paneles autenticados, llaman APIs de pago, reservan servicios y cambian estado externo. Una respuesta verificable puede alimentar settlement o aprobación.
• Las rutas de navegador y proxy reducen la fricción. La prueba puede generarse cerca de la sesión autenticada del usuario, sin mover credenciales a un scraper central.
• Los trade-offs ya se pueden medir. TLSNotary publica datos reproducibles de su harness y ofrece modos MPC y proxy.

No confundas impulso con madurez. En la revisión del 11 de agosto de 2026, la última versión de TLSNotary en GitHub es v0.1.0-alpha.15 y está marcada como pre-release (notas de versión oficiales). Fija versiones, ejecuta tu propia revisión de seguridad y aísla las fronteras de migración del prover, verificador, parser y formato de atestación.

¿Qué arquitectura zkTLS debes elegir?

Los benchmarks oficiales de TLSNotary de mayo de 2026 midieron una petición pequeña de 1 KB y una respuesta de 2 KB entre 1,0 y 2,0 segundos en modo proxy. En modo MPC fueron de 3,6 a 15,5 segundos entre los perfiles de red nativos y de navegador probados (harness de benchmarks de TLSNotary). Son medidas de referencia mantenidas por el proyecto, no tu SLA. Tamaño, lógica de redacción, dispositivo, red, comportamiento de la fuente y afirmación cambian el resultado.

¿Qué falla en producción?

• Source drift: un cambio de JSON path, redirección, compresión, regla anti-bot o test A/B puede romper la extracción sin cambiar el significado de negocio.
• Replay: una prueba antigua pero válida es peligrosa si el verificador no comprueba nonce, timestamp, audiencia, sujeto y expiración adecuados.
• Ambigüedad de parser: la criptografía autentica bytes aunque dos componentes discrepen sobre su significado. Canonicaliza petición, respuesta, números, encoding y errores.
• Exposición de credenciales: el tooling del navegador necesita acceso potente al tráfico autenticado. TLSNotary usa una sandbox QuickJS basada en capacidades, pero producción sigue necesitando permisos mínimos, consentimiento, plugins firmados y política de actualizaciones (documentación de plugins de TLSNotary).
• Concentración del verificador: un solo notario delegado es una única dependencia de política y clave, aunque nunca vea texto plano.
• Autorización falsa: demostrar que un sitio respondió «éxito» no demuestra que el usuario quisiera la petición.

La comodidad de un SDK puede ocultar estos límites. La documentación de zkFetch de Reclaim, por ejemplo, separa opciones públicas y privadas, matching de respuesta, redacción, verificación de prueba y transformación on-chain (documentación para developers de Reclaim). Revisa cada capa por separado con cualquier proveedor y nunca desactives la validación de contenido para hacer pasar una demo.

¿Debes construir, comprar o evitar zkTLS?

Compra o usa un SDK gestionado cuando buscas un piloto reversible, la fuente ya tiene una plantilla mantenida, el volumen es moderado y la afirmación no autoriza acciones catastróficas. Exige estabilidad del formato, política del notario, retención, aviso de incidentes y ruta de salida.

Controla el verificador y la integración cuando la fuente es propietaria, la afirmación desbloquea dinero o datos regulados, latencia y disponibilidad son requisitos o riesgo no puede delegar la política del notario. Aunque uses un protocolo open source, tu equipo es responsable del parser, defensa contra replay, subject binding, observabilidad y recovery.

Evita zkTLS cuando una fuente colaboradora pueda ofrecer un recibo first-party firmado, los datos sean públicos y exista un oracle maduro o OAuth más autorización server-to-server resuelvan el problema. TLSNotary indica que su flujo de referencia actual soporta TLS 1.2, mantiene TLS 1.3 en la hoja de ruta y que MPC añade un overhead importante de ancho de banda (FAQ de TLSNotary). La compatibilidad de la fuente es un gate, no una nota al pie.

¿Qué debe demostrar un piloto de producción?

Usa siete gates antes de comprometerte con una plataforma:

1. Afirmación: escribe en una frase origen, campo, umbral, sujeto, audiencia y frescura exactos.
2. Threat model: define qué podrían hacer usuario, agente, fuente, verificador, extensión y notario maliciosos.
3. Compatibilidad: prueba sesiones autenticadas reales, redirecciones, payloads, versiones de navegador y respuestas de error.
4. Privacidad: rastrea cada lugar con credenciales o texto plano, incluidos logs, crash reports, colas y enclaves.
5. Fiabilidad: mide éxito, p50, p95, ancho de banda, tamaño de prueba, fallos por source drift y recuperación.
6. Verificación: rechaza orígenes incorrectos, pruebas antiguas, nonces reutilizados, sujetos o audiencias erróneos, contenido malformado y notarios revocados.
7. Salida: demuestra que puedes cambiar adaptador, verificador o proveedor sin reescribir el núcleo de autorización.

Si el agente también debe hacer cómputo privado, no obligues a zkTLS a resolver ese problema distinto. Nuestro marco para decidir entre ZK, FHE, MPC y TEE coloca cada garantía en la capa correcta. El servicio de ingeniería zero-knowledge de Wavect convierte afirmación, threat model y gates en una arquitectura auditable antes de que la elección del SDK salga cara.