Modelo de seguridad

Una tarea ejecuta a propósito entradas no fiables: tu código, un modelo y páginas web que puede escribir cualquiera. El diseño supone que cualquiera de ellos puede portarse mal.

#El sandbox

El script o el bucle del agente de cada ejecución corre en su propio contenedor, que:

• no tiene red en absoluto; llega al navegador, al runner y al modelo solo por sockets locales que sirve el runner;
• tiene un sistema de ficheros de solo lectura con un pequeño directorio temporal;
• renuncia a todas las capacidades de Linux, no puede ganar privilegios y corre como usuario sin privilegios;
• tiene límites de CPU, memoria, procesos y tiempo (max_run_minutes);
• no guarda secretos: ni token de la API, ni clave de navegador, ni credencial del proveedor.

La conexión DevTools que recibe no puede cerrar el navegador ni abrir otros canales de depuración. La guardia de solo lectura va en una conexión aparte a la que no llega.

#La credencial del modelo

Una tarea agent llama a su modelo a través de OpenWAF Egress. La tarea tiene su propio agente de Egress; su token se rota al empezar una ejecución y otra vez al terminar, así que solo vale durante esa ejecución y nunca se guarda. El runner lo añade a las peticiones al modelo fuera del contenedor. Tu credencial del proveedor se queda en Egress y nunca llega al runner. Egress aplica sus controles de inyección y fuga de datos a cada llamada.

#Inyección de prompts

El contenido de las páginas es dato. El agente lo recibe entre delimitadores explícitos de contenido no fiable, y sus instrucciones le dicen que nunca siga instrucciones encontradas en las páginas. Esa es la primera capa, y puede fallar. Las demás no dependen del modelo:

1. El navegador es de solo lectura mientras el agente trabaja: una escritura a la que le engañen se bloquea y se registra.
2. El navegador solo llega a los dominios permitidos de la tarea.
3. Lo que el agente proponga espera a una persona, que ve los pasos exactos y el destino.
4. Solo se ejecutan los pasos aprobados, por el runner, en el dominio de la acción.

Lo probamos contra una página que ordena a los agentes ignorar su objetivo y publicar en otro sitio: la petición se bloquea, la propuesta queda pendiente y una propuesta rechazada nunca se ejecuta.

#Qué puedes hacer tú

• Deja allow tan estrecho como necesite la tarea.
• Lee cada paso antes de aprobar, no solo el resumen. Comprueba el dominio de destino.
• Usa un perfil de navegador propio para cada tarea, con sesión iniciada solo donde la tarea lo necesite.
• Fija action_limits más estrictos en los sitios donde un error saldría caro.