Política de sandbox, sandbox del invitado y centinela del kernel

Cada máquina ya funciona tras el límite de red: el agente solo tiene credenciales sustitutas, y todo lo que envía cruza el proxy y el conmutador virtual de Bromure en el Mac (consulta Credenciales y el límite de red). La política de sandbox decide qué más puede hacer una máquina — adónde puede conectarse su VM y, si quieres, qué pueden tocar sus agentes dentro de la VM. Una máquina (un espacio de trabajo, en el editor de ajustes) elige uno de dos motores de sandbox en Ajustes › Política de sandbox:

Las máquinas nuevas empiezan con el cortafuegos de Bromure. Los dos motores se aplican en el Mac, fuera del alcance del agente, y cada decisión es una fila de la Cronología de seguridad.

Cinco protecciones funcionan con cualquiera de los dos motores y están en Salvaguardas › Protecciones:

• avisar al agente cuando la política lo bloquea;
• el vigilante de agentes;
• el modo estricto de credenciales;
• la interceptación transparente;
• el bypass inseguro por petición.

El cortafuegos de Bromure

El cortafuegos es una lista de reglas sobre cada conexión que abre la VM: host, IP/CIDR, protocolo, puerto y, para el tráfico web, el método HTTP. Las reglas se comparan de arriba abajo, gana la primera coincidencia, y se pueden desactivar o activar durante un tiempo limitado. Se comprueba en el conmutador virtual (por dirección de destino y por el nombre que resolvió la VM) y de nuevo en el proxy (por nombre de servidor TLS y, en las reglas web, por método). Los puertos 80 y 443 de la VM se desvían al proxy, así que nada dentro puede escaparse. La sintaxis de las reglas y el editor están documentados en Política de sandbox › Cortafuegos de Bromure.

Políticas de OpenShell

NVIDIA OpenShell es un formato abierto para meter agentes de IA en una sandbox: una sola política YAML que dice a qué endpoints puede llegar un agente, cómo se inspeccionan sus peticiones, qué archivos puede tocar y qué programas pueden hacerlo. Bromure ejecuta políticas de OpenShell de forma nativa. Puedes traer una política escrita para OpenShell, o partir de la política inicial de Bromure, y obtener las mismas decisiones. El evaluador de Bromure se comparó con el del propio OpenShell en más de 125 000 casos diferenciales, sin ninguna discrepancia.

Elegir OpenShell + Sentry en los ajustes de una máquina carga la política por omisión de tu organización, o la política inicial (GitHub, npm y PyPI de solo lectura, los espejos de paquetes de Ubuntu), y activa el centinela del kernel. A partir de ahí, todo se deniega salvo que una regla network_policies lo permita.

Dónde se aplica la política

Algunos destinos se deniegan diga lo que diga la política:

• las direcciones de loopback, de enlace local y de metadatos de la nube;
• los puertos del plano de control de Kubernetes (2379, 2380, 6443, 10250, 10255).

Los rangos privados (10/8, 172.16/12, 192.168/16, 100.64/10) solo son alcanzables mediante un nombre de host exacto o allowed_ips. Las reglas de red se aplican al instante a una máquina en marcha. Los ajustes del sistema de archivos, de procesos y del centinela surten efecto en el siguiente arranque de la VM.

Una petición rechazada recibe un HTTP 403 con el cuerpo policy_denied propio de OpenShell, así que las herramientas y agentes que entienden OpenShell reaccionan igual.

Reglas que Bromure añade automáticamente

Una máquina sigue teniendo que llegar a los proveedores de modelos de sus agentes, a los hosts a los que van destinadas sus credenciales, a sus clústeres de Kubernetes, a AWS y a sus modelos locales. Como las reglas de proveedor de OpenShell, Bromure añade reglas _provider_… para ello. Aparecen en Rules Bromure adds automatically en la tarjeta Governance, y se dejan fuera de una política exportada.

Credenciales bajo OpenShell

La protección de credenciales de Bromure no cambia: la VM tiene sustitutos, y el valor real se cambia en el cable, solo para los hosts propios de la credencial. Dos añadidos, en el panel Credenciales de una máquina OpenShell:

• Perfiles de proveedor de OpenShell — importa un perfil (openshell profile export), escribe sus valores, y cada uno se convierte en una credencial de la máquina ligada a los hosts y rutas del perfil, con los endpoints del perfil añadidos como regla.
• Use OpenShell credential placeholders — el agente ve openshell:resolve:env:NAME en lugar de los tokens de aspecto real de Bromure, como lo vería bajo OpenShell.

Los campos de credenciales propios de la política (credential_binding, credential_signing y similares) se ignoran con una advertencia: Bromure liga cada credencial a sus hosts y firma él mismo las peticiones de AWS.

Diferencias con OpenShell

Bromure sigue la semántica de OpenShell, con algunas diferencias deliberadas:

• Sin filesystem_policy, no hay sandbox del sistema de archivos. Una política sin esa sección deja los archivos de la VM sin confinar; OpenShell confinaría al agente a su carpeta de trabajo.
• binaries necesita Enforce binaries. Sin él, binaries es solo orientativo, y el editor lo advierte: el agente tiene root en la VM, así que la identidad de un proceso no es de fiar.
• Middlewares. Solo se ejecuta el middleware integrado openshell/regex en modo redact. Un middleware externo se deja pasar o se bloquea según su fail_open / fail_closed.
• Perfiles de proveedor. Las credenciales que hacen refresh o usan un token_grant se usan como valores estáticos.
• Seccomp. El filtro se ajusta para que el control de trabajos funcione en los terminales de la VM.

La sandbox del invitado

La política de red limita adónde puede conectarse la VM. La sandbox del invitado limita lo que los agentes pueden hacer dentro. Procede de tres partes de la política:

Cada parte solo se aplica si está presente. Una política sin sección filesystem_policy ni process no confina nada en la VM. Una sección process activa por sí sola Enforce binaries.

Bromure añade las pocas rutas que necesita su propia fontanería, de solo lectura salvo que deban escribirse, y las enumera en la tarjeta Sandbox (Added for Bromure: …):

• los sockets de los terminales;
• el recurso compartido meta;
• /proc;
• la configuración DNS;
• las carpetas de instalación de los agentes que viven fuera de /usr (Grok en /opt/grok, el runtime de Oh My Pi en /opt/bun).

Nunca se mezclan con tus propias listas.

Fallar cerrado

La sandbox nunca vuelve en silencio a una ejecución sin confinar:

• Si la sandbox estricta no se aplica por completo, no arranca ninguna sesión, las reglas de binarios lo rechazan todo, y la tarjeta Sandbox lo dice en rojo. Reiniciar la VM lo reintenta.
• Los comandos que Bromure ejecuta en la máquina por ti — terminales, vm exec, operaciones con archivos, git, el planificador — esperan a que la sandbox esté lista (90 segundos para un comando simple). Si no llega a estarlo, el comando falla con sandbox unavailable: ….
• Las llamadas a git que hace el propio Bromure en la máquina siempre se ejecutan confinadas, ya que un repositorio puede hacer que git apunte a un programa de su elección.

Paquetes sin root

Un agente confinado no tiene root, así que las instalaciones para todo el sistema no pueden funcionar. Dos conmutadores de la tarjeta Sandbox, ambos activados por omisión, mantienen las instalaciones funcionando:

• Packages in the home folder — pip install va a ~/.local (npm ya instala globalmente en ~/.npm-global). Los propios procesos de Bromure en la VM ignoran los paquetes de la carpeta personal, así que el agente no puede colarles código.

• System packages on request — cuando el agente ejecuta apt-get install (con o sin sudo), la petición te espera en lugar de fallar. El agente ve:

  bromure: this sandbox has no root. Asked the user to approve installing: libpq-dev
  bromure: waiting for their decision (Sandbox drawer › Proposals)…
  

  Abre la pestaña Proposals del cajón Sandbox y elige Install o Reject. El supervisor root de la VM instala los paquetes aprobados desde los espejos de Ubuntu, solo por su nombre exacto: ni opciones, ni rutas de archivos, ni archivos .deb, ni nombres que apt leería como un patrón o una eliminación. Una petición rechazada le dice al agente que no lo reintente. Cada petición y su resultado es una fila Guest sandbox en la Cronología de seguridad.

El centinela del kernel

El centinela del kernel es un pequeño módulo del kernel de Linux que informa, desde dentro del kernel de la VM, de lo que ocurre allí. Informa al Mac por un canal privado que el agente no puede silenciar matando un proceso:

• los lanzamientos de programas;
• las conexiones, con la cadena de procesos detrás de cada una;
• los cambios de privilegios;
• las cargas de módulos y de BPF;
• todo lo que la sandbox del invitado rechazó.

Una vez arrancado, el kernel se bloquea para que ni siquiera root en la VM pueda cargar código para interferir.

El centinela es lo que hace posible:

• Linaje de red — qué prompt, qué llamada a herramienta y qué proceso hicieron cada conexión.
• Los rechazos de la sandbox en la Cronología y en la pestaña Files del cajón Sandbox.
• Detección de manipulación — un hueco en el flujo numerado del centinela, una sonda desarmada, una reconexión falsificada, la carga de un módulo sin firmar o un bloqueo rebajado se marca en rojo como tampering suspected, y alimenta al vigilante de agentes.
• La identidad de los binarios para Enforce binaries.

Tiene dos modos, en la tarjeta Kernel sentry:

Tu organización puede exigir un modo mínimo. La máquina funciona entonces con el más estricto de los dos.

Módulos bajo demanda

Un módulo del kernel solo se carga en el kernel exacto para el que se compiló, y una máquina puede pasar a un kernel nuevo de Ubuntu con apt upgrade en cualquier momento. Por eso los módulos no vienen en la app. Bromure los compila cada día para cada kernel de Ubuntu y los publica en dl.bromure.io. El catálogo y cada módulo están firmados, y Bromure verifica la firma, la suma de comprobación, y que el catálogo no sea más antiguo que uno que ya tenga.

• Al iniciarse, Bromure descarga los módulos para los kernels que se sabe que usan tus máquinas, y los prepara antes de cada arranque.
• Cuando una VM arranca un kernel que Bromure no ha visto, la VM lo pide, y Bromure descarga el módulo y se lo entrega en segundos.
• Cuando todavía no existe un módulo para ese kernel, se avisa a la VM al instante, y la tarjeta muestra Couldn't start: no module published for kernel yet. Vuelve a intentarlo un día después, o arranca con el kernel anterior.

Los módulos descargados se guardan en ~/Library/Application Support/BromureAC/sentry-modules/.

El cajón Sandbox

La ventana de cada máquina tiene un botón con un escudo en su barra de herramientas ("Sandbox: what it blocked, ready to allow"). Abre el cajón Sandbox sobre el escenario. También puedes pulsar ⌃⌘N, o elegir Visualización › Toggle Sandbox Drawer. Una insignia roja en el botón cuenta los destinos bloqueados desde la última vez que miraste. El cajón muestra lo que la sandbox de la máquina rechazó en las dos últimas horas, listo para permitir:

Las reglas que añades desde el cajón se guardan en la máquina y se aplican al instante. Se comprueban contra el límite de tu organización como cualquier otra edición. Sandbox Policy… abajo abre los ajustes de la máquina.

El asesor de políticas

Un agente que choca contra un muro suele saber exactamente qué necesitaba. Bajo OpenShell, puede pedirlo: cuando se bloquea una petición, el agente puede proponer a http://policy.local, la API del asesor de OpenShell, la regla más estrecha que la permitiría, y esperar tu decisión. El 403 que recibió le explica cómo. Tú eliges cuánto puede hacer en Política de sandbox › Policy advisor › Agent proposals:

Los agentes solo pueden proponer reglas rest o websocket, y nunca tls: skip. Una regla aprobada se añade a la política, se aplica en caliente y se conserva en el historial de revisiones de la política. Cada propuesta y cada decisión es una fila Firewall en la Cronología de seguridad.

Avisar al agente: guía por la política

Un agente que solo ve "connection refused" o "permission denied" tiende a reintentar, y luego a buscar otro camino. Visto desde fuera, parece un agente que se descontrola. Con Tell the agent when policy blocks it (en Salvaguardas › Protecciones, activado por omisión en las máquinas OpenShell), el agente sabe en su conversación qué se bloqueó y por qué, por ejemplo:

[Bromure policy] This workspace's network policy blocked connecting to api.stripe.com:443 — no network policy allows api.stripe.com:443. … This is a deliberate restriction, not a fault: don't retry it or reach the same thing another way … If your task needs it, stop and tell the user what you need and why so they can decide.

• Claude Code recibe la nota justo después del comando que chocó con el bloqueo, en mitad del turno.
• Codex, Grok, Kimi y Oh My Pi la reciben tecleada en cuanto termina su turno.
• La nota va al agente cuyo proceso hizo la conexión o el acceso a archivo bloqueado, gracias a las cadenas de procesos del centinela del kernel.
• Cuando Bromure no puede saber qué agente fue, un bloqueo de red va a todos los agentes de la máquina, y un bloqueo de archivo solo a un agente único.
• Un mismo bloqueo solo se comunica una vez cada cinco minutos, y un agente recibe como mucho cinco notas por minuto. El tráfico de fondo propio de un agente, y los hosts de telemetría habituales, nunca se comunican.

Los valores de la nota que vienen de la VM (un host, una ruta) se citan como datos, así que un programa no puede usar un bloqueo para poner palabras en boca del agente.

El vigilante de agentes

El vigilante mira una sesión en su conjunto, desde fuera de la VM:

• ráfagas de bloqueos;
• credenciales que no corresponden;
• señales de manipulación del centinela;
• una sandbox que falló;
• inyección de prompts;
• destinos nuevos después de asentarse la sesión;
• un volumen saliente muy por encima de su línea base.

Pasado un umbral en un minuto, registra un hallazgo (Alert), o corta la red de la VM, la pausa y te pregunta qué hacer (Quarantine). Consulta Salvaguardas › Vigilante de agentes. Está desactivado por omisión; sin él, las alarmas de manipulación siguen registrándose en la Cronología de seguridad y en los registros OCSF.

El límite de la organización

Una organización puede fijar un límite: lo máximo que puede permitir la política de OpenShell de cualquier máquina. Viene de bromure.io en un Mac inscrito (se actualiza cada diez minutos y se guarda en caché para usarlo sin conexión), o de un archivo en este Mac (Política de sandbox › Governance › Organization boundary). Cada guardado que cambia una política se comprueba contra él, desde los ajustes, el cajón Sandbox, el asesor de políticas o la API. Bromure usa el openshell-prover de NVIDIA cuando está instalado y, si no, su propia comprobación.

• En el editor, aparece un veredicto verde o rojo mientras escribes ("within boundary", o "exceeds boundary: …" con un ejemplo de lo que permitiría), y Guardar espera a que la política encaje.
• En otros sitios, un guardado fuera del límite se rechaza con "outside the organization boundary — …".
• Una política guardada antes que ya no encaja falla cerrada: solo siguen alcanzables las reglas que añade el propio Bromure.

Por el mismo canal, una organización también puede:

• fijar la política por omisión de las nuevas máquinas OpenShell;
• exigir Enforce binaries o las credenciales estrictas;
• fijar un modo mínimo para el centinela del kernel;
• limitar el modo del asesor de políticas;
• pedir que el razonamiento de los agentes se suba con el linaje de red.

Consulta Empresa.

Cada guardado que cambia una política también se conserva en su Revision history, con el origen del cambio; Restaurar recupera cualquier versión.

Capítulos relacionados

• Ajustes › Política de sandbox — cada campo del panel.
• Ajustes › Salvaguardas — las protecciones comunes a los dos motores.
• Resumen y cronología de seguridad — lo que decidieron los motores, y el linaje de red.
• Credenciales y el límite de red — por qué el agente nunca tiene un secreto real.