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.
Recall de fallos críticos, falsos positivos, latencia de generación/verificación y cobertura de reglas.
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é 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.
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.
- 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.
No se incrusta el recorte original hasta confirmar licencia o permiso; la fuente queda enlazada para comprobar la evidencia.
Abrir fuente primaria ↗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.