Agent Sandboxing

Limitar consecuencias de las acciones

Agent Sandboxing restringe técnicamente el contexto de ejecución para limitar recursos y efectos disponibles a acciones dirigidas por modelos. Busca reducir las consecuencias de errores o decisiones inducidas maliciosamente. No define qué objetivo debe perseguir el agente ni demuestra que una acción sea correcta. La frontera relevante es qué puede alcanzar y afectar realmente la ejecución bajo una configuración concreta.

La necesidad surge porque un modelo puede seleccionar una acción equivocada, interpretar mal una instrucción o utilizar contenido no confiable. Una herramienta puede ejecutar código del repositorio o interactuar con sistemas externos. Esperar buen comportamiento ayuda a expresar intención, pero no sustituye controles fuera de la inferencia. Un sandbox puede impedir ciertos efectos aun cuando el sistema intente producirlos.

El objetivo conecta con blast-radius: qué alcance tiene un fallo. Aquí se estudia el mecanismo aplicado a agentes, sin redefinir ese concepto de reliability. Un entorno restringido puede reducir alcance y conservar riesgos relevantes. No existe una etiqueta de sandbox que garantice protección completa frente a código malicioso, filtración o abuso de herramientas en cualquier contexto.

Qué frontera se está protegiendo

Antes de afirmar aislamiento hay que identificar recursos protegidos, acciones del ejecutor y canales que cruzan la frontera. Puede tratarse de archivos del host, procesos, red, identidades, secretos o servicios alcanzables. Un mismo sistema puede imponer controles fuertes sobre escritura local y permitir tráfico externo amplio. Describirlo solo como «aislado» oculta esa asimetría.

El agent-execution-environment ubica recursos y condiciones de trabajo. Sandboxing agrega restricciones sobre ese entorno o sobre algunas operaciones. Puede aplicarse a un ejecutor de comandos mientras el agent-harness conserva coordinación y decisiones confiables fuera de él. También existen arquitecturas integradas; la ubicación física no determina por sí sola qué componente se considera confiable.

La guía de sandbox agents de OpenAI separa conceptualmente harness y compute en una realización posible. Esa separación ayuda a preguntar qué código puede leer credenciales o alterar políticas. No se importa como arquitectura obligatoria ni significa que toda aplicación necesite provisionar un entorno propio para invocar una herramienta.

Permisos, aprobación e instrucciones

agent-permissions-and-approval-boundaries trata autorización: qué recursos y acciones están permitidos y cuándo hace falta una decisión adicional. Un sandbox trata restricción técnica de ejecución. Una implementación puede usar el mismo mecanismo para aplicar partes de ambas responsabilidades, pero sus preguntas siguen siendo distintas. Autorizar una consulta no implica permitir cualquier conexión de red que el proceso podría realizar.

Approval es una decisión anterior a un paso; no construye aislamiento por sí misma. Una acción aprobada puede continuar dentro del sandbox vigente. Si la aprobación habilita una ejecución con otros privilegios o fuera de esa frontera, cambian sus consecuencias posibles. El alcance de esa transición necesita ser visible; no corresponde asumir que cualquier aprobación elimina ni conserva siempre las mismas restricciones.

Una instrucción como «no accedas a secretos» no es un sandbox. Puede orientar al modelo, pero no impide una lectura que el proceso tenga disponible. La restricción debe aplicarse mediante controles independientes de la obediencia a ese texto. Del mismo modo, que el modelo prometa trabajar solo en un directorio no demuestra que los procesos iniciados estén limitados a ese directorio.

Container y VM son mecanismos

Un container puede contribuir a separar procesos, recursos y vistas del filesystem. Sus garantías dependen de configuración, privilegios, montajes, acceso a interfaces del host y controles de red. Compartir un kernel introduce supuestos diferentes de otra frontera de virtualización. Container no es sinónimo universal de sandbox seguro, y el aislamiento de una dimensión no demuestra el de todas las demás.

Una VM puede ofrecer otra frontera de aislamiento, pero también necesita configuración y control de los recursos compartidos. Un filesystem montado, una credencial o una API accesible puede abrir efectos más allá de la máquina invitada. Elegir container o VM no responde por sí solo qué autoridad tiene una operación. Aquí son ejemplos de implementación, no recomendaciones universales ni tecnologías a configurar.

La documentación de Gemini CLI sobre sandboxing utiliza el término para distintos métodos según plataforma. El concepto portable conserva restricciones y garantías; no adopta una backend technology como definición. Tampoco se copia una comparación comercial de «más seguro»: la utilidad de una frontera depende de amenazas, recursos y canales reales del sistema.

Workspace isolation y worktrees

Un checkout o worktree separado organiza archivos y estado de control de versiones. Facilita trabajar sin mezclar cambios, pero puede compartir usuario del sistema, procesos, filesystem externo, red y credenciales con otras tareas. Una rama Git separa referencias del repositorio; no limita lo que una shell puede hacer fuera de él.

Por eso workspace isolation no equivale a security sandboxing. En Commerce, un worktree para investigar Payments UI puede conservar acceso a la misma credencial de cloud de la sesión principal. Que sus cambios se revisen en un diff separado no impide usar esa identidad. La organización del trabajo y la reducción de autoridad pueden complementarse, sin que una sustituya a la otra.

Es posible combinar workspace separado y controles de ejecución. Lo importante es reconocer qué aporta cada uno y qué deja abierto. Un directorio temporal no se vuelve un sandbox por su nombre, y un entorno remoto no queda protegido por estar lejos de la estación del usuario. Una ejecución local puede tener límites efectivos mientras otra cloud conserva acceso demasiado amplio.

Filesystem y lectura sensible

Las restricciones pueden delimitar lectura y escritura, directorios permitidos, montajes o recursos del host. Es necesario distinguir los archivos de trabajo de rutas que contienen políticas, credenciales u otros proyectos. Una escritura restringida puede coexistir con lectura amplia; los resultados de herramientas pueden trasladar esa información a otros componentes del sistema.

Read-only reduce ciertos efectos de mutación, pero no elimina riesgo. Leer una clave, un dataset privado o código confidencial puede exponerlo en una respuesta o petición posterior. El riesgo depende también de las salidas permitidas y del tratamiento de datos. Un snapshot limpio después de la tarea no prueba que no se haya producido una lectura o transmisión sensible.

El alcance de escritura también importa para las reglas del propio sistema. Si el ejecutor puede modificar el componente que lo autoriza o archivos que futuras ejecuciones interpretan como política, aparece una vía para alterar límites. La decisión debe examinar qué controles están fuera del alcance del trabajo no confiable, sin convertir esta explicación en una guía de implementación del sistema operativo.

Red, procesos y recursos

La red puede restringirse mediante destinos permitidos, egress control, proxies u otros mecanismos. Un destino permitido no garantiza que todo contenido enviado allí sea inocuo. También importa qué procesos están cubiertos y si existen rutas alternativas. La documentación del sandboxed Bash tool de Claude Code explicita límites de cobertura; sus garantías deben leerse en ese alcance, no como afirmación sobre todas las herramientas del producto.

El aislamiento de procesos y los límites de recursos pueden reducir interferencia, consumo y acceso a capacidades del host. Restricciones sobre llamadas al sistema, duración o cómputo son dimensiones posibles; no constituyen un conjunto obligatorio para todo agente. Un proceso permitido puede seguir ejecutando lógica incorrecta dentro de sus límites, y otro puede fallar por una restricción legítima.

Controlar un mecanismo tampoco equivale a controlar todas sus extensiones. Una herramienta remota, un servidor externo o una operación delegada puede ejecutarse en otra frontera. La documentación del firewall de Copilot ilustra por qué la cobertura debe identificarse por proceso y entorno. No se presupone que configurar un control cubra automáticamente cada integración.

Secretos e identidad

Un secreto no debería quedar accesible simplemente porque el agente lo solicita. Es posible mediar autenticación fuera del código ejecutado y exponer una operación limitada en lugar de la credencial completa. Cuando una clave se entrega al entorno, cambia quién puede leerla: el almacenamiento previo en un gestor de secretos no conserva por sí solo su aislamiento durante la ejecución.

La guía de seguridad de entornos de OpenAI distingue credenciales del control de aplicación y acceso del ejecutor. Aquí interesa el principio: disponibilidad para un tool, exposición al proceso y contenido enviado al modelo son decisiones diferentes. Una herramienta puede realizar una consulta autenticada y devolver el resultado sin imprimir el secreto en su salida.

Las identidades externas deben tener alcance adecuado incluso si el compute está aislado. Una credencial efímera limita duración, pero durante su vigencia puede permitir operaciones amplias. No basta que el proceso no escape al host si puede borrar recursos a través de una API autorizada. La seguridad requiere considerar autoridad y canales además de la frontera local.

Efectos externos y ciclo de vida

En Commerce, una investigación puede tener filesystem restringido y una API de pagos disponible. Si la identidad permite mutar cobros, el proceso puede causar un efecto externo sin romper el sandbox local. Autorización del servicio, límites del tool y aprobación del paso son controles adicionales. La protección de una máquina no implica protección automática de todas las dependencias que esa máquina alcanza.

Detener o eliminar un entorno efímero puede descartar archivos y procesos locales. No revierte un correo enviado, un despliegue publicado ni una mutación remota. También puede haber datos que salieron antes del cierre. La duración del entorno y la reversibilidad de sus efectos deben examinarse separadamente; un entorno que vivió pocos segundos puede producir consecuencias duraderas.

Estas distinciones cambian cómo se evalúa una tarea aparentemente segura. Ejecutar tests puede invocar scripts no confiables; abrir un archivo puede exponer información; llamar una API puede tener efectos. No significa que toda acción deba bloquearse o aprobarse manualmente. Significa que el diseño debe considerar sus recursos y canales reales sin deducir seguridad de una etiqueta como «temporal» o «solo local».

Prompt injection, tool abuse y defensa en capas

Prompt injection puede influir decisiones del modelo mediante instrucciones no autorizadas en entradas, repositorios o resultados de herramientas. Un sandbox puede limitar algunas consecuencias de esas decisiones; no impide por sí mismo que el modelo interprete contenido malicioso como guía. Distinguir manipulación de inferencia y restricción de ejecución evita prometer que el aislamiento resuelve toda AI Security.

Tool Abuse describe uso indebido de capacidades. Una acción puede ser abusiva y técnicamente posible dentro del sandbox; otra puede ser bloqueada por los recursos que necesita. Confused Deputy señala problemas de autoridad utilizada en nombre de quien no debería poseerla. Se mencionan estas relaciones de amenazas sin desarrollar sus futuros canonicals ni convertirlas en sinónimos de escape del sandbox.

Instrucciones, checks de guardrails, permisos, aprobación, sandbox, autorización de tools/APIs y verificación pueden contribuir a defensa en capas. Ninguno garantiza por sí solo seguridad. No se prescribe una pila obligatoria ni una aprobación para cada paso: las capas se eligen por necesidades y garantías. Una regla perfecta de filesystem tampoco verifica que la respuesta final sea correcta o que el cambio satisfaga el requisito comercial.

Límites y relaciones en el Atlas

Una configuración incorrecta, montajes privilegiados, fuga de credenciales, caminos de red no cubiertos o fallos de aislamiento pueden ampliar consecuencias. Un sandbox también puede impedir operaciones legítimas y dificultar reproducir un problema. Conocer esa limitación permite acotar el trabajo o reportar evidencia faltante; no justifica abandonar la frontera silenciosamente para obtener un resultado aparentemente exitoso.

Este canonical conserva el mecanismo de restricción aplicado a agentes. Environment ubica recursos; Harness sostiene ejecución; Permissions/Approval delimita autoridad y decisiones adicionales. agents conserva la definición del sistema. Las mismas preguntas aplican a un agente de browser, soporte o análisis: qué puede observar, qué puede afectar y qué consecuencias quedan fuera de la frontera protegida.

Fuentes

Fuentes primarias consultadas el 2026-10-25. Definición, comparaciones y Commerce son síntesis editorial del Atlas; no se atribuye una garantía universal a container, VM ni sandbox de producto.

• OpenAI: Sandbox agents, separación posible de control y compute.
• Google: Sandboxing in Gemini CLI, métodos de implementación sujetos a plataforma.
• Claude Code: Sandboxed Bash tool, alcance y limitaciones documentadas de controles.
• GitHub: Copilot firewall, cobertura y límites por proceso/entorno.
• OpenAI: Sandbox security, separación de credenciales y acceso mediado.