Selvedge y ejecución con pruebas
Un sandbox no es un testigo
Ejecutar código no confiable es una de esas ideas que suenan bien en una reunión porque nadie ha redactado aún el informe del incidente. Deja que el agente llame a una herramienta. Deja que el plugin transforme un archivo. Deja que el módulo asociado procese los datos. Ponlo en un sandbox. Encantador. El código no puede escapar. Todos asienten. Luego el auditor pregunta qué hizo realmente el código dentro del sandbox, y de repente la sala descubre que la contención no es lo mismo que la evidencia.
Un sandbox responde una pregunta: ¿se mantuvo la carga de trabajo dentro del límite? Eso es necesario. Pero no es suficiente. La pregunta más difícil es qué sucedió durante la ejecución. ¿Qué artefacto se ejecutó? ¿Qué política se aplicó? ¿Qué capacidades se solicitaron? ¿Qué llamadas al host se permitieron o denegaron? ¿Cuánto combustible, memoria y tiempo consumió? ¿Qué salió? ¿Se puede reproducir la ejecución sin confiar en la máquina original? Si esas respuestas viven en registros y confianza, el sistema tiene un disfraz, no un rastro de auditoría.
Selvedge existe para cubrir esa brecha. La página lo llama la capa de transcripción de ejecución para código no confiable: AION demuestra el razonamiento, Ledger registra los eventos del sistema y Selvedge captura la ejecución. La implementación sigue esa forma. El espacio de trabajo es un proyecto Rust 2024 con crates para resúmenes de núcleo y límites de recursos, motores de ejecución, backends Wasmtime y Kera, determinismo, hosts WASI y Kera, política, verificación AION, CLI, MCP, registro, ejecutor, demonio, auditoría y superficies del SDK invitado. La promesa pública es deliberadamente sencilla: Selvedge ejecuta código no confiable bajo ejecución determinista, aplicación de políticas y disciplina de verificación.
La distinción útil es pequeña y brutal. Un sandbox dice que el código no salió. Selvedge está diseñado para decir qué hizo el código.
La transcripción no es un registro
Los registros son útiles para los humanos que ya están depurando. Son menos útiles cuando la pregunta es si una ejecución puede verificarse más tarde por alguien que no confiaba en el host original. Una línea de registro puede faltar, reordenarse, filtrarse, truncarse, reformatearse o explicarse de forma evasiva. Una transcripción tiene que ser parte del contrato de ejecución.
El núcleo de Selvedge define resúmenes SHA3-256, tipos de error, validación de rutas, tokens de autenticación y límites de recursos compartidos. El README describe transcripciones con hashes del bytecode, la configuración, la salida estándar, la salida de error, la salida, la memoria y los globales, además del consumo de combustible y los recuentos de llamadas al host. La página describe que cada llamada al host se incorpora a una cadena SHA3-256 y que el resultado se envuelve en un sobre de prueba estilo AION con sellado Ed25519. Esa es la diferencia entre un sistema que dice confía en mí y un sistema que dice aquí está el paquete.
Hay una dosis saludable de paranoia en ese diseño. El resumen del artefacto nombra el código. El resumen de la configuración nombra el perfil determinista. La transcripción nombra lo que cruzó el límite del host. El sobre firmado hace visible la manipulación. La verificación sin conexión significa que el runtime original no es el único testigo. Esta es la parte que muchas historias de sandbox omiten porque es menos divertida que mostrar un plugin ejecutándose en una demo. Las demos rara vez preguntan quién editó el registro de auditoría. Los auditores sí.
La denegación por defecto también necesita recibos
El denegado por defecto es una buena postura y un pésimo eslogan si se queda en la diapositiva. La política de Selvedge le da dientes al eslogan. El crate de políticas define capacidades WASM como reloj, aleatoriedad, sistema de archivos, red, entorno, stdio, proceso y personalizadas. Lleva límites de recursos para memoria, tamaño de archivo, número de instrucciones y tiempo. Valida invariantes, rechaza capacidades duplicadas, proporciona errores estructurados y mapea los fallos al vocabulario común de fallos de Dweve. El ejecutor aplica entonces los límites de recursos a la configuración de ejecución antes de que comience la carga de trabajo.
Eso significa que la política no es un cuestionario que se responde después de la ejecución. Es una entrada para la ejecución. Si la carga de trabajo solicita tiempo, aleatoriedad, sistema de archivos, red, entorno o acceso a procesos, esa solicitud tiene que pasar la política. Si gasta demasiado combustible, memoria o tiempo de pared, la ejecución termina como un fallo controlado. Si una política es inconsistente, debería fallar antes de que el artefacto empiece a hacer nada interesante. Muy aburrido. Muy útil. El aburrimiento es como mantenemos los fines de semana.
El punto importante es que las decisiones de política no están separadas de la evidencia. Un sandbox puede permitir o denegar una categoría amplia y aun así dejar el rastro de auditoría escaso. Selvedge está construido en torno a la idea de que cada decisión de puerta y lectura de recursos pertenece a la historia de la ejecución. Eso es lo que lo hace útil para herramientas de agentes, ejecución de plugins de terceros, inferencia de Kera, cargas de trabajo reguladas y código de socios. El trabajo puede no ser de confianza. La evidencia no debería serlo.
El determinismo es donde el host deja de improvisar
La reproducción es fácil de prometer y difícil de mantener. El host tiene un reloj. El host tiene aleatoriedad. El comportamiento de NaN en coma flotante puede ser incómodo. SIMD puede diferir entre arquitecturas. Los sistemas de archivos, las variables de entorno y el estado del proceso son excelentes formas de colar no determinismo en lugares donde nadie lo esperaba. Si quieres reproducción, tienes que eliminar o controlar esas fuentes antes de que se conviertan en excusas.
Selvedge hace de la ejecución determinista el valor por defecto. El README describe un reloj virtual fijado a la época 2024-01-01, aleatoriedad ChaCha20 con semilla, medición de combustible, generación de registros y canonicalización de NaN. También dice que la detección de SIMD es la más rápida pero solo para la misma arquitectura, mientras que deshabilitar SIMD es la ruta totalmente portable entre plataformas. Esa última parte importa porque el determinismo no es una oración. Es una decisión de configuración y arquitectura, y a veces el intercambio honesto es velocidad por portabilidad.
El ejecutor usa por defecto el backend de Wasmtime con ejecución determinista habilitada. Kera es el otro backend, orientado a IR de grafos y cargas de trabajo de redes neuronales binarias. Esa división es sensata. WASM es la ruta general para componentes no confiables. Kera es la ruta de grafos de IA. Ambos necesitan la misma disciplina circundante: política antes de la ejecución, ajustes deterministas, registro después de la ejecución y prueba alrededor del resultado.
Por qué los agentes hacen que esto sea menos opcional
Los sistemas de agentes vuelven a poner de moda la ejecución de código no confiable, una frase que debería hacer que cualquier profesional de seguridad se siente un poco más erguido. Un modelo solicita una llamada a una herramienta. Un plugin ejecuta una transformación. Un script auxiliar generado toca datos. Una herramienta de un socio llega a través de MCP. El modelo no escribió la herramienta, es posible que la herramienta no se haya revisado con el mismo cuidado que el código del producto, y el usuario aún espera que el sistema explique lo que sucedió. Buena suerte con eso si la única respuesta es un directorio de registros y buenas vibraciones.
Selvedge tiene una superficie de servidor MCP para herramientas de agentes, una CLI para flujos de trabajo de compilación, verificación, ejecución y reproducción, un daemon para ejecución de larga duración, agrupación de runners y calentamiento de caché, crates de cliente y servidor de registro, y un SDK invitado. La cuestión no es que todas las superficies sean iguales. La cuestión es que la forma de la evidencia debería ser comparable. Ya sea que una carga de trabajo entre como un componente WASM, un grafo Kera, una herramienta de agente o un trabajo de servicio, la ejecución debería terminar con algo que se pueda verificar.
El rendimiento es un intercambio, no un hechizo
La página de Selvedge incluye cifras de referencia del BENCHMARKS.md del repositorio: el arranque en frío es la victoria principal, la ruta en caliente es más matizada, Kera JIT tiene una buena historia con grafos en caliente, y Wasmtime estándar aún mantiene algunas rutas en caliente de llamadas repetidas. Esa es la forma correcta de hablar de ello. El trabajo de ejecución está lleno de compensaciones. Si un modelo de componentes produce una transcripción y un sobre de prueba, tiene costes diferentes a los de la ruta mínima. Si el arranque en frío es tu problema, esa ruta de evidencia puede ayudar. Si la carga de trabajo es una llamada repetida ajustada sin necesidad de sobrecarga de transcripción, la respuesta puede ser diferente. Muy inconveniente, la realidad. Se niega a ser un folleto.
La versión en artículo de la historia del rendimiento es, por tanto, simple: elige el runtime para la carga de trabajo. No uses un sobre de prueba como una poción mágica de velocidad. Úsalo cuando el coste de no tener evidencia reproducible sea mayor que la sobrecarga. Para herramientas de agentes, procesamiento de datos regulados, plugins de terceros y ejecución donde más tarde un humano preguntará qué sucedió, ese coste suele ser real.
Qué revisar antes de usarlo
Primero, decide si necesitas contención, evidencia o ambas. Si la carga de trabajo es confiable e interna, Selvedge puede ser más maquinaria de la necesaria. Si la carga de trabajo no es confiable, proviene de un socio, es activada por un modelo o está orientada a auditorías, la transcripción empieza a ganarse su lugar.
Segundo, revisa la política. ¿Qué capacidades están permitidas? ¿Cuáles están denegadas? ¿Cuáles son los límites de combustible, memoria y tiempo? ¿El modo determinista es obligatorio o meramente permisivo? ¿El acceso al sistema de archivos y a la red es lo suficientemente restringido? ¿La política está versionada con el artefacto? Si la política vive en una wiki y la ejecución vive en otro lugar, el diseño ya está derivando.
Tercero, prueba la reproducción como un comportamiento del producto. No esperes a una auditoría para descubrir si el sobre se verifica sin conexión. Ejecuta el mismo artefacto, la misma política y las mismas entradas dos veces. Compara las transcripciones. Prueba capacidades denegadas. Rompe la suma de verificación. Cambia la semilla. Desactiva SIMD si la identidad multiplataforma importa. Las pruebas molestas son el punto.
La lección
Selvedge no es una caja de arena más bonita. Es una capa de evidencia de ejecución. Ejecuta artefactos WASM y Kera, parte de denegación predeterminada, restringe recursos, controla entradas deterministas, cifra la ejecución en transcripciones y envuelve los resultados en un sobre de prueba que se puede verificar más tarde. Esa es una promesa diferente de la de el código se quedó en su rincón.
A medida que los sistemas de IA invocan más herramientas, ejecutan más asistentes generados y aceptan más componentes de terceros, esa distinción deja de ser académica. La pregunta no será solo si la carga de trabajo escapó. La pregunta será qué hizo, bajo qué política, con qué entradas, produciendo qué salidas, y si alguien más puede reproducir esa afirmación.
Un sandbox es un muro. Selvedge intenta ser también el testigo.