Política de sandbox, sandbox do convidado e sentinela do kernel

Cada máquina já corre atrás da fronteira de transmissão: o agente só detém credenciais substitutas, e tudo o que envia atravessa o proxy e o switch virtual do Bromure no Mac (veja Credenciais e a fronteira de transmissão). A política de sandbox decide o que mais uma máquina pode fazer — para onde a sua VM se pode ligar e, se quiser, o que os seus agentes podem tocar dentro da VM. Uma máquina (um espaço de trabalho, no editor de definições) escolhe um de dois motores de sandbox em Definições › Política de sandbox:

As máquinas novas começam no firewall do Bromure. Os dois motores são aplicados no Mac, fora do alcance do agente, e cada decisão é uma linha da Linha do tempo de segurança.

Cinco proteções funcionam sob qualquer dos motores e estão em Salvaguardas › Proteções:

• avisar o agente quando a política o bloqueia;
• o vigilante dos agentes;
• o modo estrito de credenciais;
• a interceção transparente;
• o desvio inseguro por pedido.

O firewall do Bromure

O firewall é uma lista de regras sobre cada ligação que a VM abre: anfitrião, IP/CIDR, protocolo, porta e, para o tráfego web, o método HTTP. As regras são comparadas de cima para baixo, a primeira correspondência ganha, e podem ser desligadas ou ligadas por um tempo limitado. É verificado no switch virtual (pelo endereço de destino e pelo nome que a VM resolveu) e de novo no proxy (pelo nome de servidor TLS e, para as regras web, pelo método). As portas 80 e 443 da VM são desviadas para o proxy, pelo que nada lá dentro se pode furtar. A sintaxe das regras e o editor estão documentados em Política de sandbox › Firewall do Bromure.

Políticas OpenShell

O NVIDIA OpenShell é um formato aberto para pôr agentes de IA em sandbox: uma única política YAML que diz que endpoints um agente pode alcançar, como os seus pedidos são inspecionados, que ficheiros pode tocar e que programas o podem fazer. O Bromure executa políticas OpenShell nativamente. Pode trazer uma política escrita para o OpenShell, ou partir da política inicial do Bromure, e obter as mesmas decisões. O avaliador do Bromure foi comparado com o do próprio OpenShell em mais de 125 000 casos diferenciais, sem nenhuma discrepância.

Escolher OpenShell + Sentry nas definições de uma máquina carrega a política predefinida da sua organização, ou a política inicial (GitHub, npm e PyPI só de leitura, os espelhos de pacotes do Ubuntu), e liga a sentinela do kernel. A partir daí, tudo é recusado a menos que uma regra network_policies o permita.

Onde a política é aplicada

Alguns destinos são recusados diga a política o que disser:

• endereços de loopback, link-local e de metadados da cloud;
• as portas do plano de controlo do Kubernetes (2379, 2380, 6443, 10250, 10255).

As gamas privadas (10/8, 172.16/12, 192.168/16, 100.64/10) só são alcançáveis através de um nome de anfitrião exato ou de allowed_ips. As regras de rede aplicam-se de imediato a uma máquina em execução. As definições do sistema de ficheiros, dos processos e da sentinela entram em vigor no próximo arranque da VM.

Um pedido recusado recebe um HTTP 403 com o corpo policy_denied próprio do OpenShell, para que as ferramentas e os agentes que entendem o OpenShell reajam da mesma forma.

Regras que o Bromure acrescenta automaticamente

Uma máquina continua a ter de alcançar os fornecedores de modelos dos seus agentes, os anfitriões a que as suas credenciais se destinam, os seus clusters Kubernetes, a AWS e os seus modelos locais. Tal como as regras de fornecedor do OpenShell, o Bromure acrescenta regras _provider_… para isso. São listadas em Rules Bromure adds automatically no cartão Governance, e deixadas de fora de uma política exportada.

Credenciais sob OpenShell

A proteção de credenciais do Bromure não muda: a VM detém substitutos, e o valor real é trocado na transmissão, só para os anfitriões da própria credencial. Duas adições, no painel Credenciais de uma máquina OpenShell:

• Perfis de fornecedor OpenShell — importe um perfil (openshell profile export), escreva os seus valores, e cada um passa a ser uma credencial da máquina ligada aos anfitriões e caminhos do perfil, com os endpoints do perfil acrescentados como regra.
• Use OpenShell credential placeholders — o agente vê openshell:resolve:env:NAME em vez dos tokens parecidos com os reais do Bromure, como veria sob o OpenShell.

Os campos de credenciais da própria política (credential_binding, credential_signing e semelhantes) são ignorados com um aviso: o Bromure liga cada credencial aos seus anfitriões e assina ele próprio os pedidos AWS.

Diferenças em relação ao OpenShell

O Bromure segue a semântica do OpenShell, com algumas diferenças deliberadas:

• Sem filesystem_policy, sem sandbox do sistema de ficheiros. Uma política sem essa secção deixa os ficheiros da VM sem confinamento; o OpenShell confinaria o agente à sua pasta de trabalho.
• binaries precisa de Enforce binaries. Sem isso, binaries é apenas indicativo, e o editor avisa: o agente tem root na VM, por isso a identidade de um processo não é de confiança.
• Middlewares. Só o middleware integrado openshell/regex em modo redact corre. Um middleware externo é deixado passar ou bloqueado conforme o seu fail_open / fail_closed.
• Perfis de fornecedor. As credenciais que fazem refresh ou usam um token_grant são usadas como valores estáticos.
• Seccomp. O filtro é ajustado para que o controlo de tarefas funcione nos terminais da VM.

A sandbox do convidado

A política de rede limita para onde a VM se pode ligar. A sandbox do convidado limita o que os agentes podem fazer lá dentro. Vem de três partes da política:

Cada parte só se aplica se estiver presente. Uma política sem secção filesystem_policy nem process não confina nada na VM. Uma secção process liga por si só o Enforce binaries.

O Bromure acrescenta os poucos caminhos de que a sua própria canalização precisa, só de leitura a menos que tenham de ser escritos, e lista-os no cartão Sandbox (Added for Bromure: …):

• os sockets dos terminais;
• a partilha meta;
• /proc;
• a configuração DNS;
• as pastas de instalação dos agentes que vivem fora de /usr (o Grok em /opt/grok, o runtime do Oh My Pi em /opt/bun).

Nunca são fundidos nas suas próprias listas.

Falhar fechado

A sandbox nunca recua em silêncio para uma execução sem confinamento:

• Se a sandbox estrita não se aplicar por completo, nenhuma sessão arranca, as regras de binários recusam tudo, e o cartão Sandbox di-lo a vermelho. Reiniciar a VM tenta de novo.
• Os comandos que o Bromure corre na máquina por si — terminais, vm exec, operações de ficheiros, git, o planeador — esperam que a sandbox esteja de pé (90 segundos para um comando simples). Se não ficar de pé, o comando falha com sandbox unavailable: ….
• As chamadas git que o próprio Bromure faz na máquina correm sempre confinadas, já que um repositório pode apontar o git para um programa à sua escolha.

Pacotes sem root

Um agente confinado não tem root, por isso as instalações para todo o sistema não podem funcionar. Dois interruptores do cartão Sandbox, ambos ligados por predefinição, mantêm as instalações a funcionar:

• Packages in the home folder — o pip install vai para ~/.local (o npm já instala globalmente em ~/.npm-global). Os próprios processos do Bromure na VM ignoram os pacotes da pasta pessoal, pelo que o agente não consegue plantar código neles.

• System packages on request — quando o agente corre apt-get install (com ou sem sudo), o pedido espera por si em vez de falhar. O agente vê:

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

  Abra o separador Proposals da gaveta Sandbox e escolha Install ou Reject. Os pacotes aprovados são instalados pelo supervisor root da VM a partir dos espelhos do Ubuntu, só pelo nome exato: sem opções, caminhos de ficheiros, ficheiros .deb, nem nomes que o apt leria como um padrão ou uma remoção. Um pedido rejeitado diz ao agente para não tentar de novo. Cada pedido e o seu desfecho é uma linha Guest sandbox na Linha do tempo de segurança.

A sentinela do kernel

A sentinela do kernel é um pequeno módulo do kernel Linux que relata, de dentro do kernel da VM, o que lá acontece. Relata ao Mac por um canal privado que o agente não consegue silenciar matando um processo:

• os lançamentos de programas;
• as ligações, com a cadeia de processos por trás de cada uma;
• as mudanças de privilégios;
• os carregamentos de módulos e de BPF;
• tudo o que a sandbox do convidado recusou.

Depois de arrancar, o kernel é trancado para que nem o root na VM consiga carregar código para interferir.

É a sentinela que torna isto possível:

• Linhagem de rede — que prompt, que chamada de ferramenta e que processo fizeram cada ligação.
• As recusas da sandbox na Linha do tempo e no separador Files da gaveta Sandbox.
• Deteção de adulteração — uma falha no fluxo numerado da sentinela, uma sonda desarmada, uma religação forjada, o carregamento de um módulo não assinado ou um bloqueio rebaixado é assinalado a vermelho como tampering suspected, e alimenta o vigilante dos agentes.
• A identidade dos binários para o Enforce binaries.

Tem dois modos, no cartão Kernel sentry:

A sua organização pode exigir um modo mínimo. A máquina corre então com o mais estrito dos dois.

Módulos a pedido

Um módulo do kernel só carrega no kernel exato para que foi compilado, e uma máquina pode passar para um novo kernel Ubuntu com apt upgrade a qualquer momento. Por isso, os módulos não vêm na aplicação. O Bromure compila-os todos os dias para cada kernel Ubuntu e publica-os em dl.bromure.io. O catálogo e cada módulo são assinados, e o Bromure verifica a assinatura, a soma de verificação, e que o catálogo não é mais antigo do que um que já tenha.

• Ao arrancar, o Bromure obtém os módulos para os kernels que se sabe que as suas máquinas correm, e prepara-os antes de cada arranque.
• Quando uma VM arranca um kernel que o Bromure ainda não viu, a VM pede, e o Bromure obtém o módulo e entrega-o em segundos.
• Quando ainda não existe módulo para esse kernel, a VM é avisada de imediato, e o cartão mostra Couldn't start: no module published for kernel yet. Tente de novo um dia depois, ou arranque com o kernel anterior.

Os módulos transferidos ficam guardados em ~/Library/Application Support/BromureAC/sentry-modules/.

A gaveta Sandbox

A janela de cada máquina tem um botão com um escudo na barra de ferramentas («Sandbox: what it blocked, ready to allow»). Abre a gaveta Sandbox sobre o palco. Também pode premir ⌃⌘N, ou escolher Visualizar › Toggle Sandbox Drawer. Um distintivo vermelho no botão conta os destinos bloqueados desde a última vez que olhou. A gaveta mostra o que a sandbox da máquina recusou nas últimas duas horas, pronto a permitir:

As regras que acrescenta a partir da gaveta são guardadas na máquina e aplicam-se de imediato. São verificadas contra o limite da sua organização como qualquer outra edição. Sandbox Policy… em baixo abre as definições da máquina.

O conselheiro de políticas

Um agente que bate numa parede costuma saber exatamente do que precisava. Sob OpenShell, pode pedi-lo: quando um pedido é bloqueado, o agente pode propor a http://policy.local, a API do conselheiro do OpenShell, a regra mais estreita que o permitiria, e esperar pela sua decisão. O 403 que recebeu explica-lhe como. Escolhe quanto ele pode fazer em Política de sandbox › Policy advisor › Agent proposals:

Os agentes só podem propor regras rest ou websocket, e nunca tls: skip. Uma regra aprovada é acrescentada à política, aplica-se ao vivo e fica guardada no histórico de revisões da política. Cada proposta e cada decisão é uma linha Firewall na Linha do tempo de segurança.

Avisar o agente: orientação pela política

Um agente que só vê «connection refused» ou «permission denied» tende a tentar de novo, e depois a procurar outro caminho. Visto de fora, parece um agente a descontrolar-se. Com Tell the agent when policy blocks it (em Salvaguardas › Proteções, ligado por predefinição nas máquinas OpenShell), o agente fica a saber na sua conversa o que foi bloqueado e porquê, por exemplo:

[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.

• O Claude Code recebe a nota logo a seguir ao comando que bateu no bloqueio, a meio do turno.
• O Codex, o Grok, o Kimi e o Oh My Pi recebem-na escrita quando o seu turno termina.
• A nota vai para o agente cujo processo fez a ligação ou o acesso a ficheiro bloqueado, graças às cadeias de processos da sentinela do kernel.
• Quando o Bromure não consegue saber qual foi o agente, um bloqueio de rede vai para todos os agentes da máquina, e um bloqueio de ficheiro só para um agente único.
• O mesmo bloqueio só é comunicado uma vez em cada cinco minutos, e um agente recebe no máximo cinco notas por minuto. O tráfego de fundo do próprio agente, e os anfitriões de telemetria comuns, nunca são comunicados.

Os valores da nota que vieram da VM (um anfitrião, um caminho) são citados como dados, pelo que um programa não pode usar um bloqueio para pôr palavras na boca do agente.

O vigilante dos agentes

O vigilante olha para uma sessão como um todo, de fora da VM:

• rajadas de bloqueios;
• credenciais que não pertencem ali;
• sinais de adulteração da sentinela;
• uma sandbox que falhou;
• injeção de prompt;
• destinos novos depois de a sessão estabilizar;
• volume de saída muito acima da sua linha de base.

Passado um limiar dentro de um minuto, regista uma constatação (Alert), ou corta a rede da VM, põe-na em pausa e pergunta-lhe o que fazer (Quarantine). Veja Salvaguardas › Vigilante dos agentes. Está desligado por predefinição; sem ele, os alarmes de adulteração continuam registados na Linha do tempo de segurança e nos registos OCSF.

O limite da organização

Uma organização pode definir um limite: o máximo que a política OpenShell de qualquer máquina pode permitir. Vem do bromure.io num Mac inscrito (atualizado a cada dez minutos, e guardado em cache para uso offline), ou de um ficheiro neste Mac (Política de sandbox › Governance › Organization boundary). Cada gravação que altera uma política é verificada contra ele, a partir das definições, da gaveta Sandbox, do conselheiro de políticas ou da API. O Bromure usa o openshell-prover da NVIDIA quando está instalado, caso contrário a sua própria verificação.

• No editor, aparece um veredicto verde ou vermelho enquanto escreve («within boundary», ou «exceeds boundary: …» com um exemplo do que permitiria), e Salvar espera até a política caber.
• Noutros sítios, uma gravação fora do limite é recusada com «outside the organization boundary — …».
• Uma política gravada antes que já não cabe falha fechada: só as regras que o próprio Bromure acrescenta continuam alcançáveis.

Pelo mesmo canal, uma organização também pode:

• definir a política predefinida das novas máquinas OpenShell;
• exigir o Enforce binaries ou as credenciais estritas;
• definir um modo mínimo para a sentinela do kernel;
• limitar o modo do conselheiro de políticas;
• pedir que o raciocínio dos agentes seja carregado com a linhagem de rede.

Veja Empresa.

Cada gravação que altera uma política também fica guardada no seu Revision history, com a origem da alteração; Restaurar recupera qualquer versão.

Capítulos relacionados

• Definições › Política de sandbox — cada campo do painel.
• Definições › Salvaguardas — as proteções comuns aos dois motores.
• Visão geral e linha do tempo de segurança — o que os motores decidiram, e a linhagem de rede.
• Credenciais e a fronteira de transmissão — porque é que o agente nunca detém um segredo verdadeiro.