VeraCTO · te explica cómo funciona

Teoría

Última pieza del modelo. Todo lo anterior asume que el código lo escribiste tú. ¿Y cuando no? Un archivo que sube un cliente, la salida de un LLM, un plugin de terceros. Para eso hay tres capas, y la regla de oro: gana siempre la más restrictiva.

1. El bloque (o expresión) `sandbox`

sandbox
    let resultado be transformar(dato_externo)   -- aquí NO hay red/disco/db/secretos

let limpio be sandbox validar(dato_externo)      -- como expresión: aísla Y devuelve

Dentro se despojan todas las capacidades, incluso las que el programa declaró afuera.
Un require interno es un no-op: el código aislado no puede auto-concederse permisos.
Solo queda cómputo puro y print. Perfecto para procesar datos envenenables.

2. El techo del host: `--cap-set` / `--sandbox`

synsema run --sandbox programa.syn                   # solo stdout + time
synsema run --cap-set "stdout,db=:memory:" prog.syn  # techo a medida

Quien ejecuta impone un techo que el código no puede exceder, declare lo que declare: efectivas ⊆ require ∩ techo. Aplica también a los agentes que el programa lance. Así funciona el sandbox donde corre TU código en este sitio.

3. `call_tool`: mínimo privilegio por herramienta

task consultar_bcra()
    require net("api.bcra.gob.ar")     -- lo que ESTA herramienta declara
    give fetch("https://api.bcra.gob.ar/tasas")

let r be call_tool(consultar_bcra, nothing)

call_tool ejecuta la tarea con SOLO las capacidades que ella declaró (intersectadas con las del programa). Es la pieza clave cuando un LLM elige qué herramienta llamar: cada herramienta corre con lo suyo y nada más.

Ejecuta el ejemplo: el mismo cálculo funciona dentro del sandbox, y el intento de red dentro del sandbox muere aunque quisiéramos permitirlo.

Sandbox: código en el que no confías

+10 xp

Estás en modo lectura. Crea una cuenta o entra para enviar tu solución y ganar estrellas. Puedes ejecutar código igual.

Ejemplo de Vera — modifícalo y ejecútalo