Resumen Técnico: Pureza Certificada para Ejecutores de Flujos de Trabajo Cognitivos

1. El Problema: La Brecha de Pureza en los Flujos de Trabajo Cognitivos

Los sistemas de flujos de trabajo cognitivos (que orquestan la inferencia de IA, el uso de herramientas y el razonamiento) operan cada vez más en dominios de alto riesgo. Trabajos anteriores (McCann [2026e]) establecieron una arquitectura de gobernanza de tres capas que garantiza la Completitud de la Gobernanza, la Completitud de la Proveniencia y la Imposibilidad de Efectos No Gobernados. Sin embargo, estos teoremas de seguridad se basaron en una premisa crítica: la Restricción del Módulo Puro, que exige que los módulos ejecutores no puedan realizar efectos de E/S y solo puedan devolver directivas declarativas.

En la implementación anterior, esta restricción se hacía cumplir mediante análisis estático del gráfico de importación de módulos en la máquina virtual BEAM (Erlang/OTP). Aunque más robusto que la gobernanza basada en convenciones, este mecanismo es insuficiente frente a la evasión adversaria. Las características dinámicas de BEAM permiten cinco clases distintas de evasión que el análisis estático no puede prevenir de manera fiable:

1. Despacho Dinámico: Uso de :erlang.apply/3 para invocar funciones arbitrarias sin importaciones estáticas.
2. Evaluación de Código: Uso de Code.eval_string/1 para ejecutar código arbitrario en tiempo de ejecución.
3. Funciones Implementadas de Forma Nativa (NIFs): Carga de bibliotecas compartidas con acceso ilimitado al sistema.
4. Puertos: Creación de procesos externos mediante :erlang.open_port/2.
5. Carga Dinámica de Módulos: Carga de bytecode arbitrario en tiempo de ejecución mediante :code.load_binary/3.

Debido al Teorema de Rice, ningún análisis estático puede decidir la propiedad semántica no trivial de "sin efectos de E/S" para todos los programas posibles. Una sobreaproximación sólida rechazaría la mayoría del código idiomático legítimo de Elixir. Esto crea una brecha de pureza: el modelo formal asume pureza, pero el mecanismo de aplicación (análisis estático) no puede garantizarla estructuralmente frente a un adversario determinado.

2. Metodología: De la Detección a la Prevención Estructural

Este artículo propone una Arquitectura de Pureza Certificada que convierte la restricción del módulo puro de una convención aplicada por análisis en una frontera de capacidad estructural aplicada por el entorno de ejecución. La metodología se basa en cuatro mecanismos centrales:

A. Objetivo de Compilación Restringido (WebAssembly)

Los ejecutores se compilan a un objetivo restringido de WebAssembly (WASM). Se aprovecha el modelo de capacidades de WASM para eliminar estructuralmente las cinco clases de evasión de BEAM:

• Sin Despacho Dinámico: WASM carece de instrucciones para resolver llamadas a funciones mediante nombres de cadenas/átomos en tiempo de ejecución; las llamadas se restringen a índices estáticos en una tabla de funciones.
• Sin Evaluación de Código: WASM ejecuta bytecode precompilado; no existe ningún mecanismo para generar o cargar nuevo código en tiempo de ejecución.
• Sin NIFs/Puertos: Los módulos WASM se ejecutan en una máquina virtual en un entorno aislado (sandbox) sin acceso a sistemas de archivos del host, bibliotecas compartidas o creación de procesos.
• Sin Carga Dinámica: La instanciación de módulos está controlada enteramente por el host; los módulos no pueden cargar otros módulos.

B. Lista Blanca de Funciones del Host ($W$)

El módulo WASM solo puede invocar funciones declaradas explícitamente en su sección de importación. Estas importaciones se restringen a una Lista Blanca ($W$) finita y enumerada:

• $W_{data}$: Operaciones de datos puros (gestión de memoria, manipulación de cadenas, aritmética, serialización JSON, lecturas de contexto).
• $W_{dir}$: Constructores de directivas (funciones que construyen estructuras de datos que representan efectos previstos, por ejemplo, directive_http_request, pero que no los ejecutan).
• Exclusión: Las importaciones de WASI (WebAssembly System Interface), que otorgan capacidades de efectos, están explícitamente excluidas.

C. Certificados de Pureza

Un Certificado de Pureza es un artefacto de prueba criptográfica que vincula un binario de ejecutor con su clasificación de pureza.

• Estructura: Contiene el hash SHA-256 del binario del ejecutor, el hash de la prueba de pureza (lista de importaciones + clasificación) y una firma Ed25519 sobre estos hashes.
• Integridad: Debido a la resistencia a colisiones de SHA-256 y la inforgeabilidad de Ed25519, un certificado no puede transferirse a un artefacto modificado.

D. Puerta de Verificación en Tiempo de Ejecución

Antes de que un ejecutor ingrese al flujo de gobernanza, una Puerta de Verificación realiza:

1. Verificación de Firma: Valida la firma Ed25519.
2. Vinculación de Artefacto: Confirma que el hash del binario coincide con el certificado.
3. Derivación Independiente de la Prueba: Analiza la sección de importaciones del binario WASM de novo y verifica que coincida con la prueba de pureza reclamada frente a la lista blanca actual.
4. Validación de Clasificación: Asegura que todas las importaciones estén clasificadas como puras.

Solo los ejecutores que superan esta puerta son instanciados. Esta puerta actúa como un precondición estructural, asegurando que ningún ejecutor sin un certificado de pureza válido pueda ejecutarse.

3. Contribuciones Clave

1. Modelo de Amenazas Formal: Una caracterización rigurosa de las cinco clases de evasión de BEAM y los límites teóricos del análisis estático (Teorema de Rice) en este contexto.
2. Pureza Estructural por Construcción: Una prueba (Teorema 4.5) de que la compilación al objetivo restringido de WASM satisface la restricción del módulo puro por construcción, independientemente del contenido del código del ejecutor.
3. Eliminación de Evasión: Pruebas formales (Teorema 5.5) de que cada una de las cinco clases de evasión de BEAM es estructuralmente imposible en el entorno restringido de WASM.
4. Atestación Criptográfica: Un esquema para Certificados de Pureza y Registros de Atestación Remota que permite la verificación portátil y transorganizacional de la pureza del ejecutor sin acceso al código fuente.
5. Definición de la Base de Computación Confiable (TCB): Una definición explícita de los cinco componentes requeridos para la garantía (entorno de ejecución WASM, funciones del host, lista blanca, puerta de verificación, intérprete de directivas), reduciendo la superficie de confianza desde el código ilimitado del ejecutor hasta un conjunto acotado y auditables.
6. Niveles de Confianza Graduados: Una arquitectura de implementación que soporta tres niveles (Pureza Verificada, Análisis Estático, Experimental) para permitir una adopción incremental.

4. Resultados y Evaluación

La arquitectura se evaluó en cuatro ejecutores implementados (basados en Rust, compilados a WASM) ejecutándose en un procesador de la serie M de Apple con el backend JIT de Wasmtime.

• Latencia de Verificación: La puerta de verificación tarda 39–42 µs (mediana) para ejecutores de producción. Con la caché basada en hashes, el costo amortizado se acerca a cero para invocaciones repetidas.
• Sobrecarga en Tiempo de Ejecución: El ciclo completo de planificación (instanciación, ejecución, deserialización) se completa en 256–398 µs. Esto representa una sobrecarga de <0.4% en una solicitud HTTP de 100 ms y <0.05% en una llamada típica de LLM de 800 ms.
• Determinismo: No se observaron divergencias en 40 invocaciones repetidas con entradas idénticas, confirmando la naturaleza determinista del entorno de ejecución WASM.
• Tamaño del Certificado: Los certificados son compactos (~1.3 KB), muy por debajo de los presupuestos de ancho de banda.
• Correctitud: Todos los ejecutores produjeron las formas de directiva esperadas, y el sistema mantuvo salidas idénticas a nivel de bytes entre ejecuciones.

5. Significado y Afirmaciones

El artículo afirma un cambio fundamental en el estatus epistemológico de las garantías de gobernanza:

• De la Detección a la Prevención: Los enfoques anteriores dependían de detectar patrones de evasión conocidos mediante análisis estático. Esta arquitectura previene la evasión al hacer que las capacidades de producción de efectos estén estructuralmente ausentes.
• Fortalecimiento de Teoremas Existentes: Los teoremas de seguridad de McCann [2026e] (Completitud de la Gobernanza, Completitud de la Proveniencia, Sin Efectos No Gobernados) permanecen formalmente idénticos. Sin embargo, su premisa fundamental se descarga mecánicamente en lugar de asumirse. La garantía ahora descansa en las propiedades matemáticas del modelo de capacidades de WASM y los primitivos criptográficos (SHA-256, Ed25519) en lugar de las limitaciones de un analizador estático.
• Confianza Portátil: Al convertir pruebas de pureza locales en registros de atestación portátiles, la arquitectura permite la composición de gobernanza transorganizacional, permitiendo que la Organización A verifique criptográficamente la pureza de los ejecutores de la Organización B sin revisión del código fuente.

El artículo señala explícitamente que esto no es una prueba mecanizada en el sentido de Rocq o Lean (lo cual está reservado para la lógica de gobernanza subyacente en artículos complementarios), sino una garantía estructural verificada en tiempo de ejecución. La contribución es la reducción de la superficie de confianza desde "todo el código del ejecutor" hasta una pequeña Base de Computación Confiable explícitamente definida.