Sandbox, capacidad e identidad: seguridad basada en tareas en sistemas agentes

Dos agentes trabajan en diferentes sucursales. Ninguno sobrescribe el archivo del otro. El equipo concluye que la ejecución es aislada.

Pero ambos pueden seguir usando la misma credencial, consultar la misma base de datos, llamar a la misma herramienta y llegar a la misma red. La separación de archivos resolvió una colisión laboral; no resolvió la frontera de seguridad.

En los sistemas agentes, la seguridad debe acompañar toda la tarea: quién ejecuta, en qué entorno, con qué capacidades, con qué datos, durante cuánto tiempo y bajo qué autoridad.

Resumen ejecutivo

Un worktree protege la simultaneidad en el repositorio. Un sandbox limita la ejecución. Acciones de atributos de identidad. Las capacidades restringen lo que cada identidad puede hacer. Policy decide cuándo la combinación es válida.

Ninguna capa reemplaza a las demás. La seguridad de las tareas surge de la intersección entre ellas.

Worktree no es sandbox

Worktrees son excelentes para aislar cambios competitivos. Cada sesión recibe su propio árbol de trabajo, rama e historial. Esto reduce las colisiones y facilita la revisión.

Sin embargo, el sistema operativo no interpreta una rama como un límite de permiso. Un proceso puede continuar leyendo rutas externas, variables, llaveros, sockets o servicios de red si el entorno lo permite.

El contrato correcto es:

worktree = isolamento de mudança
sandbox  = isolamento de execução
policy   = isolamento de autoridade

La documentación del agente de código público describe el acceso y las redes de sandbox, workspace como controles distintos. FORGE utiliza esta separación como principio de diseño; la existencia de un sandbox específico no certifica el producto que lo adopta. [R2-C3]

La identidad debe pasar a la acción

“El agente lo hizo” es una frase operativamente débil. ¿Qué agente? ¿En nombre de quién? ¿En qué sesión? ¿Con qué papel? ¿Qué versión de workflow otorgó el permiso?

Una identidad útil debería permitirle llamar:

1. persona o sistema que inició la tarea;
2. sesión que recibió el objetivo;
3. rol o especialidad asumida;
4. grant efectivo;
5. acción realizada;
6. artefacto o efecto producido;
7. decisión de revisión o aceptación.

Esto no requiere exponer razonamientos internos. Requiere registrar suficientes hechos operativos para asignar, investigar y revocar.

Capability es más preciso que "acceso"

Permitir “GitHub” dice poco. Es posible que una tarea necesite leer un problema, crear una rama y abrir un PR, sin poder cambiar secretos, reglas de protección o releases.

Modelo grants como verbos sobre recursos:

issue:read
branch:create
repository:write@worktree
pull_request:create
secret:read = denied
release:publish = denied

Lo mismo se aplica a bases de datos, CRM, archivos e infraestructura. La capability debe ser mínima, vinculada a la tarea y revocable. Modelos y adapters pueden sugerir operaciones; el enforcement debe estar fuera del texto que controla el propio ejecutor. Las fuentes públicas muestran implementaciones distintas de agents, workspaces y permisos, no un estándar universal de autorización. [HARNESS31-C4]

Una matriz de cinco dimensiones

Antes de iniciar una ejecución con efecto material, responda:

El grant no debería sobrevivir a la razón por la que fue creado. Una sesión completa no necesita mantener acceso de escritura; una vista previa no necesita credencial de producción; un revisor no necesita ejecutar el código que revisa.

La red es parte del contrato.

Los agentes que navegan, instalan dependencias o consultan servicios externos amplían la superficie de prompt injection, exfiltración y supply chain.

Tres políticas son más útiles que el binario "Internet activado":

• denegar: Sin salida; las dependencias y los datos ingresan a través de artefactos aprobados;
• lista de permitidos: sólo destinos y métodos requeridos;
• escalar: El nuevo dominio requiere decisión antes de la primera llamada.

También es importante controlar la retroalimentación: descargar un paquete, enviar contenido, crear una transacción y publicar un comentario son efectos diferentes.

Los secretos no pertenecen a prompt

Una credencial insertada en contexto puede reaparecer en una transcripción, llamada de herramienta, error o artefacto. El modelo no necesita saber el secreto para utilizar un capability.

Preferir:

• corredor o bóveda que intercambia identidad por un token corto;
• alcance mínimo y entorno explícito;
• inyección sólo en el proceso autorizado;
• registros con valor enmascarado;
• revocación observable;
• prueba negativa que acredite el acceso denegado fuera de la tarea.

El resultado esperado no es “el agente prometió no presentarse”. Es que "la arquitectura no entregó el valor al contexto y el efecto fuera de grant falló".

Seguridad de tareas en la práctica

Considere un agente encargado de corregir documentación pública:

1. recibe una emisión pública y un worktree exclusivo;
2. lee sólo el repositorio y las fuentes incluidos en la lista permitida;
3. no recibe secretos de implementación;
4. puede editar archivos de alcance y ejecutar validadores locales;
5. puede abrir PR, pero no aprobarlo ni publicar release;
6. CI utiliza una identidad separada para verificar;
7. la implementación utiliza otra identidad, después de la fusión;
8. todos los grants de la sesión caducan al cerrarse.

Separar identidades reduce la autoridad circular. También hace que los incidentes sean más localizables: un fracaso en la investigación, implementación, revisión o publicación deja evidencia en un plano diferente.

La prueba más importante es negativa.

La configuración declarada no es suficiente. Comprueba que:

• el agente no lee archivos fuera de workspace;
• falla la red hacia un destino no autorizado;
• el token de desarrollo no llega a producción;
• el revisor no escribe a asset;
• grant caducado deja de funcionar;
• una sesión no accede a la memoria ni a los datos de otra;
• Los registros identifican subject, el recurso y la decisión sin filtrar contenido confidencial.

Una arquitectura puede parecer limitada y aun así tener un bypass. La prueba negativa convierte la frontera en una propiedad observable.

Lo que este artículo prueba y lo que no prueba

Las fuentes elegibles sostienen que sandbox, red, identidad y autorización son controles separados y que el perfil exacto depende del entorno. No demuestran que una herramienta específica sea segura en ninguna configuración, ni que el aislamiento elimine prompt injection, error humano o riesgo de supply chain.

Este artículo propone un contrato de seguridad basado en tareas. El modelo de amenaza, las pruebas y el funcionamiento siguen siendo específicos de cada producto.

Conclusión

A un agente no se le debe dar “acceso al sistema”. Debe recibir una pequeña capacidad, en un entorno limitado, por un corto tiempo, vinculado a una identidad y evidencia.

Worktree organiza concurso. Sandbox reduce el alcance. Cesiones de identidad. Límites Capability. Policy decide. La seguridad aparece cuando todas estas capas coinciden en la misma tarea.

Lectura anterior: ¿Gráfico, bucle o híbrido?. Siguiente lectura sugerida: Gusto, responsabilidad y claridad..