Qué probaría antes de escalar esta idea.
- PREGUNTA DE PRUEBA
- ¿La verificación basada en contratos reduce fallos críticos sin bloquear acciones benignas en un conjunto de amenazas ponderado por severidad?
- ENTRADA
- 500 escenarios nuevos con niveles de severidad, comparación sin contrato y con NiyamAI en sandbox.
- MÉTRICA
- Recall de fallos críticos, falsos positivos, latencia de generación/verificación y cobertura de reglas.
- PARADA
- Parar si se omite más de 1% de los casos críticos o si los falsos positivos superan 2%.
La prueba verifica que el Judge aplicó su clasificación al contrato, no que el Judge o el contrato sean correctos ni que el LLM completo esté alineado; el coste de generación limita el uso a acciones críticas.
Esta prueba es una propuesta editorial: no es un resultado reportado por los autores.
Lo esencial antes de invertir más tiempo.
NiyamAI fija herramientas y restricciones al inicio de la sesión, intercepta cada llamada, obtiene el juicio de un componente aislado y exige verificar una prueba zk-SNARK antes de ejecutar.
NiyamAI reporta F1 88,5% y 1,1% de falsos positivos; generar una prueba cuesta 2.260,6 ± 218,4 ms y verificarla 53,1 ± 11,8 ms.
Resultado reportado con fuente enlazada · 4 localizadores disponibles.La prueba verifica que el Judge aplicó su clasificación al contrato, no que el Judge o el contrato sean correctos ni que el LLM completo esté alineado; el coste de generación limita el uso a acciones críticas.
La arquitectura encaja con agentes que ejecutan pagos, comandos o cambios regulados, aunque el coste de generar una prueba obliga a reservarla para acciones críticas.
NiyamAI fija herramientas y restricciones al inicio de la sesión, intercepta cada llamada, obtiene el juicio de un componente aislado y exige verificar una prueba zk-SNARK antes de ejecutar.
Qué sostiene esta confianza — y qué sigue sin probarse.
Juicio editorial sobre la transferibilidad de esta lectura; no mide calidad académica ni efecto local.
- FUENTE PRIMARIA
- DOCUMENTADO
Lectura primaria completa registrada sobre v1; comprobación: 2026-08-20 · método, resultado y límites revisados; fuente primaria enlazada.
- RÉPLICA LOCAL
- PENDIENTE
No se ha registrado una réplica independiente en este sitio. El código o los datos enlazados, cuando existen, no cuentan como réplica.
- LÍMITES
- DOCUMENTADO
3 límites declarados en la ficha.
- APLICABILIDAD
- ACOTADO
Hay una prueba de transferencia con entrada, métrica y parada; su resultado local todavía no se ha observado.
REGLA EDITORIALLos criterios no se promedian automáticamente. Una fuente leída, un límite claro o un protocolo propuesto no equivalen a una réplica ni a un resultado local.
Qué está reportado y qué conviene comprobar.
NiyamAI reporta F1 88,5% y 1,1% de falsos positivos; generar una prueba cuesta 2.260,6 ± 218,4 ms y verificarla 53,1 ± 11,8 ms.
F1 88,5%; 1,1% FP; 2.260,6 ms generar; 53,1 ms verificar · contexto: 2.000 escenarios de Agent-SafetyBench
Qué estudiaron y qué cambia.
La síntesis está separada de los resultados reportados y de las inferencias.NiyamAI aborda una debilidad de las defensas habituales frente a prompt injection y llamadas peligrosas: muchas políticas se ejecutan como software dentro del mismo entorno que queremos proteger y no dejan una evidencia independiente de que se aplicaron.
Al comenzar una sesión, el sistema fija un Intent Contract comprometido con SHA-256 que declara herramientas y restricciones. Cada llamada se intercepta y un Judge aislado decide si encaja; cuando la acción es aprobada, se genera una prueba zk-SNARK con EZKL y la herramienta solo se ejecuta después de verificarla.
La evaluación usa 2.000 escenarios de Agent-SafetyBench y compara con NeMo Guardrails, Llama Prompt Guard 2 y GPT-OSS-Safeguard. NiyamAI reporta F1 de 88,5% y 1,1% de falsos positivos, pero con una asimetría operativa fuerte: unos 2,26 segundos para generar cada prueba frente a unos 53 ms para verificarla.
La propuesta es valiosa como arquitectura de acciones críticas, no como sustituto universal de políticas. Una prueba puede demostrar que un Judge aplicó una regla, pero no que esa regla capturaba la intención correcta ni que el Judge entendió bien el contexto. El siguiente experimento debe medir la frontera entre riesgo, latencia y coste de prueba.
- PROBLEMA
- Los filtros y system prompts operan en el mismo entorno que queremos proteger y no dejan una prueba independiente de que la política se aplicó.
- MÉTODO
- Crea un Intent Contract con herramientas y restricciones, pasa cada acción a un Judge aislado y exige verificar un zk-SNARK generado con EZKL antes de ejecutar.
- TIPO DE EVIDENCIA
- En 2.000 escenarios de Agent-SafetyBench, NiyamAI reporta F1 88,5% y 1,1% de falsos positivos; generar una prueba cuesta 2.260,6 ± 218,4 ms por acción aprobada y verificarla 53,1 ± 11,8 ms.
- LÍMITE
- La prueba verifica que el Judge aplicó su clasificación al contrato, no que el Judge o el contrato sean correctos ni que el LLM completo esté alineado; el coste de generación limita el uso a acciones críticas.
El guardrail se convierte en una condición de ejecución verificable.
Una prueba verifica la aplicación de la regla; todavía hay que validar que la regla y el juez sean correctos.
La ficha no incrusta una figura primaria porque su licencia o permiso específico no consta en el registro editorial. La fuente permanece enlazada para comprobarla.
Comprobar fuente primaria ↗ (sitio externo; abre en una pestaña nueva)La lectura también deja rastro.
Guarda una observación junto a la evidencia. Tú escribes aquí; los agentes pueden añadir notas por MCP y aparecerán identificados.
LECTURA AMPLIADAMetodología, implicaciones y preguntas para volver al paper.+
Crea un Intent Contract con herramientas y restricciones, pasa cada acción a un Judge aislado y exige verificar un zk-SNARK generado con EZKL antes de ejecutar.
La arquitectura encaja con agentes que ejecutan pagos, comandos o cambios regulados, aunque el coste de generar una prueba obliga a reservarla para acciones críticas.
La prueba verifica que el Judge aplicó su clasificación al contrato, no que el Judge o el contrato sean correctos ni que el LLM completo esté alineado; el coste de generación limita el uso a acciones críticas.
Cómo lo llevaría a un proyecto
Usar contratos y pruebas verificables solo para tres acciones de alto impacto y comparar coste, bloqueo correcto y trazabilidad frente a guardrails convencionales.
Preguntas que conviene probar
- ¿Qué acciones justifican el coste de una prueba criptográfica?
- ¿Cómo se actualiza un contrato sin dejar una ventana de permisos incoherente?
Si tuviera que convertirlo en una prueba mañana.
Mi lectura
La verificación criptográfica puede ser una frontera de seguridad útil, pero no convierte automáticamente al juez en una autoridad correcta.
Esta última frase es una inferencia editorial a partir del paper y de sus posibles implicaciones; no es una afirmación de los autores.
La prueba que queda en pie.
¿La verificación basada en contratos reduce fallos críticos sin bloquear acciones benignas en un conjunto de amenazas ponderado por severidad?