Agent Safehouse – herramienta de sandboxing para agentes locales en macOS

• Herramienta que aísla a los agentes locales de IA mediante el sandbox nativo de macOS para evitar que modifiquen elementos fuera del sistema permitido
• Todos los agentes se ejecutan en entornos de sandbox independientes, por lo que no pueden acceder al directorio home del usuario ni a otros proyectos
• Aplica un modelo de acceso deny-first, permitiendo leer y escribir solo en los directorios autorizados explícitamente
• La instalación se completa con un único script de Bash, y puede ejecutarse de inmediato sin compilación ni dependencias adicionales
• Incluye generación de perfiles basada en LLM para automatizar la configuración de sandbox-exec con privilegios mínimos

---

Descripción general

• Agent Safehouse es un sistema de sandboxing exclusivo para macOS que protege el sistema para que los agentes de IA ejecutados localmente no dañen archivos del sistema
  • “Go full --yolo. We've got you.” “Move fast, break nothing”
  • Bloquea el riesgo de ejecución de comandos inesperados derivado de la naturaleza probabilística de los LLM
• Todos los agentes principales funcionan completamente dentro del sandbox y no afectan al sistema externo
• Adopta un modelo de acceso deny-first, que bloquea todo acceso por defecto y solo permite rutas autorizadas explícitamente
  • Ejemplo: ~/my-project tiene lectura/escritura permitida, mientras que ~/.ssh, ~/.aws, ~/other-repos tienen el acceso denegado

Instalación y ejecución

• La instalación se completa descargando un único script de shell
  • Se descarga el script con el comando curl, se guarda en ~/.local/bin/safehouse y luego se le otorgan permisos de ejecución
• Después, se ejecuta el agente deseado con el comando safehouse
  • Ejemplo: safehouse claude --dangerously-skip-permissions
• Safehouse otorga por defecto permisos de lectura/escritura al directorio de trabajo actual (git root) y acceso de solo lectura al directorio de la cadena de herramientas

Ejemplos de validación del sandbox

• El acceso a archivos sensibles queda bloqueado a nivel de kernel
  • Al ejecutar safehouse cat ~/.ssh/id_ed25519 aparece el error “Operation not permitted”
  • Otros directorios de proyecto (~/other-project) no son visibles
  • El directorio del proyecto actual sí puede accederse con normalidad

Automatización y generación de perfiles

• Al agregar funciones de shell, todos los agentes pueden ejecutarse por defecto dentro de Safehouse
  • Ejemplo: definiendo una función safe() en .zshrc o .bashrc, los comandos claude, codex, amp, gemini se ejecutan automáticamente dentro del sandbox
  • Para ejecutarlos sin sandbox, se invocan en la forma command claude
• Ofrece una función de generación de perfiles basada en LLM
  • Modelos como Claude, Codex y Gemini analizan las plantillas de Safehouse para generar perfiles de sandbox-exec con privilegios mínimos
  • Se guardan en la ruta ~/.config/sandbox-exec.profile con base en la información del directorio home y la cadena de herramientas
  • Incluyen permisos de acceso al directorio de trabajo actual y atajos de comando por agente

Seguridad e importancia práctica

• Protege para que los agentes locales basados en LLM no puedan borrar archivos ni modificar el sistema por error
• Aprovecha el control de acceso a nivel de kernel de macOS para ofrecer un entorno de ejecución seguro por defecto
• Al basarse en un único script, puede integrarse fácilmente en el flujo de trabajo de los desarrolladores

[GN⁺]

Comentarios en Hacker News

• No esperaba que el proyecto que hice se hiciera público tan rápido
  1️⃣ Prefiero los agentes que se ejecutan directamente en local. Me da más tranquilidad que corran en mi propia máquina, ajustada al detalle por mí, en lugar de en contenedores o servidores remotos
  2️⃣ Esto es básicamente un generador de políticas para sandbox-exec. No tiene dependencias ni virtualización. En cambio, dediqué mucho tiempo a encontrar los permisos mínimos que necesita cada agente para hacer cosas como actualizaciones automáticas, integración con Keychain, pegar imágenes, etc. La investigación relacionada está resumida en agent-safehouse.dev/docs/agent-investigations
  3️⃣ Ni siquiera hace falta usar todo el proyecto. Solo con Policy Builder ya puedes generar políticas de sandbox-exec para meterlas en tus dotfiles

  • Perdón por publicarlo antes de tiempo. Lo probé después de ver un comentario que habías dejado antes, y me pareció tan eficiente que valía la pena presentarlo en un post
    Ya había visto documentación de políticas de sandbox, pero era la primera vez que veía una app lista para usar de este tipo
    Eso sí, hubo algunas incomodidades: se bloquea el acceso a .gitconfig y .gitignore en el directorio home, y por las restricciones de acceso a procesos no puedo hacer que Claude ejecute comandos como lldb o pkill. Estaría bien tener un control de permisos más fino
  • Me pregunto si esto podría aplicarse a openclaw. Es cómodo hacerlo correr de una forma accesible desde la máquina local, pero al mismo tiempo eso hace que sea más difícil de controlar
  • Me intriga cuál es la diferencia práctica entre ejecución local y ejecución en contenedor
  • Oh, esto era justo lo que estaba buscando. Había intentado ajustar microsandbox, pero esto se siente mucho más realista
    Revisé por encima el sitio y los scripts, y no encontré ningún problema en particular. ¿Hay alguna precaución no documentada que deba tener en cuenta?
  • Irónicamente, me interesó este proyecto porque no confío en la IA, pero para instalarlo hay que descargar y ejecutar un archivo .sh desde un servidor cualquiera, lo cual da un poco de risa
    Me gustaría que lo distribuyeran como tarball. Así podría revisar el contenido yo mismo y verificar si fue generado automáticamente en CI, así que me daría más confianza

• Me alegra ver proyectos así, y creo que ahora mismo el sandboxing es el mayor desafío
  Los primeros usuarios van a correr agentes en local sin pensarlo demasiado, pero a largo plazo o en entornos empresariales eso jamás va a funcionar
  No basta con controlar red, archivos y permisos de ejecución; también hay que cubrir escenarios complejos como pruebas en navegador o creación de recursos en la nube
  Al final hace falta un enfoque práctico que integre seguridad, costos y control de permisos

  • Pero, ¿y si esto fuera un problema imposible de resolver en el fondo? Funcionalidad y seguridad siempre chocan, y al final la gente elige la primera
  • El sandboxing a nivel de archivos es lo básico; lo realmente difícil es el control de credenciales y red
    Yo uso un demonio local que emite JWTs de vida corta para que el agente no maneje claves directamente. Funciona bien para acceso a APIs, pero aun así, a nivel del sistema de archivos, todavía podría lanzar instancias EC2 infinitamente

• El problema es que resulta difícil comparar y evaluar distintos sandboxes
  Esto parece ser un wrapper de sandbox-exec, y últimamente están saliendo muchos wrappers de este tipo
  Lo que realmente hace falta es documentación para validar la confiabilidad y pruebas automatizadas. A la mayoría de los sandboxes les falta documentación
  Para confiar en ellos, hace falta documentación detallada y evidencia de que funcionan

  • Por eso lo hice en Bash: para evitar binarios opacos
    Los perfiles de sandbox-exec para cada agente están separados en la carpeta de perfiles de GitHub, así que se pueden revisar fácilmente
    También estoy haciendo pruebas E2E con agentes reales
    Incluso sin el wrapper de Safehouse, puedes generar directamente políticas de mínimo privilegio con Policy Builder
    Además, también ofrezco un archivo de instrucciones para que un LLM redacte perfiles de sandbox

• Esto es un script wrapper para sandbox-exec. Está bueno que tenga muchos presets bien armados
  El 90% de sandbox-exec consiste en definir bien el alcance, y el otro 90% en entenderlo
  Eso sí, estaría bueno poder hacer sandboxing con overlay o copy-on-write. Me basta con modificar un entorno temporal en vez de mi .bashrc

  • Usé Bash porque cuesta confiar en binarios hechos en Go o Rust
    Un overlay FS es complicado en macOS, pero lo resolví limitando a solo lectura todo lo que está fuera del CWD, para inducir que el trabajo se haga en carpetas temporales
  • Estoy creando un OSS llamado Amika. Es una herramienta para levantar rápidamente sandboxes locales o remotos, y se integra bien con Git
    También permite exponer puertos TCP/UDP y compartirlos con el equipo. Ver enlace de GitHub
  • Yo hice un proyecto llamado Treebeard. Combina sandbox-exec, worktree y sistema de archivos COW
    Permite acceder de forma segura a archivos ignorados por git. Enlace a Treebeard
  • Pero, ¿sandbox-exec no está ya deprecated?

• Dato curioso: sandbox-exec está oficialmente en estado deprecated desde macOS Sierra (2016)
  Aun así, se sigue usando de forma útil. El App Sandbox de Apple no encaja con este tipo de reglas personalizadas
  Ojalá Apple no lo elimine por completo

  • En realidad, parece que fue deprecated desde su origen. Casi no existe documentación del lenguaje de perfiles, y la mayor parte se entendió por ingeniería inversa

• También existe un proyecto llamado Sandvault. Combina sandbox-exec con un sistema de usuarios Unix
  A cada agente le da una cuenta de usuario separada y sin privilegios, y la interacción se hace vía sudo, SSH y directorios compartidos
  Enlace de GitHub de Sandvault

• Hice una app GUI para macOS que permite administrar visualmente sandbox-exec
  También incluye filtrado de red por dominio y detección de secretos
  multitui.com

• Comparten cómo usar el comando container de Apple para ejecutar Claude Code dentro de un contenedor de Apple
  Configuran el entorno en el orden container system start → container run → container exec, y luego instalan Node.js y Claude

  • ¡Gracias! No sabía hasta ahora que Homebrew también tiene apple/container

• Me pregunto por qué creen que es mejor correr agentes en local.
  Para la mayoría de la gente, la ejecución remota probablemente sea más eficiente, porque no hace falta mantenerlos siempre encendidos

  • La ventaja de correrlos en local es el control y la propiedad. Es parecido a por qué uno mismo corre Plex o un servidor web
    Además, así se evitan las suscripciones
  • Yo hice pixels para resolver este problema. Puede correr sobre TrueNAS SCALE o Incus
    Estoy reforzando la seguridad, pero ya es suficientemente adecuado para flujos de trabajo con IA
    Enlace de GitHub de pixels

• Me pregunto si “clunker” es una nueva jerga para “clanker”. Pregunta de parte del Roku de un amigo de un amigo
  Justo ahora estoy sufriendo con el problema del sandboxing, así que llega en el momento perfecto

  • Era un typo, ya lo corregí