Salvaguardas

As salvaguardas são o controlo, do lado do anfitrião, do Bromure Agentic Coding sobre a forma como as credenciais de um espaço de trabalho podem ser usadas. Como o próprio painel indica: as salvaguardas regem a forma como as credenciais configuradas deste espaço de trabalho são usadas. Perguntar antes de usar faz aparecer uma confirmação do lado do anfitrião na primeira vez que uma credencial é usada numa sessão. Uma política de escrita remove ou bloqueia operações destrutivas na transmissão — imposta no proxy, de modo que um agente comprometido na VM não a consiga contornar. Só aparecem aqui as credenciais que configurou.

O painel mostra uma linha por credencial configurada, na mesma ordem em que o painel Credenciais as lista. Cada linha mostra o título e o(s) anfitrião(ões) da credencial e tem dois controlos:

• Uma caixa de verificação Perguntar antes de usar (rotulada Exigir aprovação para usar no próprio controlo) — a barreira de consentimento por credencial, transferida para aqui a partir do painel Credenciais.
• Um seletor de política de escrita integrado, mostrado apenas onde o serviço da credencial o suporte.

Se o espaço de trabalho não tiver credenciais, o painel mostra um estado vazio — Nenhuma credencial para proteger — remetendo-o de volta para o painel Credenciais. Os detalhes de imposição, os formatos de erro e os registos de auditoria são abordados na análise aprofundada de injeção de prompt e salvaguardas.

Perguntar antes de usar

Cada linha tem uma caixa de verificação Perguntar antes de usar, desligada por predefinição. Quando está ligada, na primeira vez que essa credencial é usada numa sessão o proxy pausa e faz aparecer um diálogo de consentimento que oferece autorizações limitadas no tempo — 5 minutos, 1 hora ou o resto da sessão — ou Não permitir. As autorizações existem apenas em memória e são apagadas quando a janela da sessão fecha, e todas as decisões ativas são listadas em Janela → Aprovações de Credenciais…. O modelo de consentimento, a fusão de pedidos concorrentes e a janela de aprovações são abordados em Credenciais e a fronteira de transmissão.

Esta caixa de verificação aplica-se a qualquer credencial, incluindo chaves de API simples, chaves SSH e tokens manuais — as linhas que não têm política de escrita mostram apenas este controlo.

Política de escrita

Onde o serviço de uma credencial consegue classificar o seu próprio tráfego, a linha mostra também um seletor de política de escrita. Aparece para:

• Forjas Git — tokens do GitHub, GitLab, Bitbucket.
• Credenciais da AWS.
• Tokens do DigitalOcean.
• Registos de contentores (Docker Hub, ghcr.io e outros).
• Contextos do Kubernetes.
• Endpoints de base de dados (MongoDB, ClickHouse, Elasticsearch).

Cada política de escrita oferece os mesmos quatro modos:

Os novos espaços de trabalho usam por predefinição Perguntar antes de escrever em todos os serviços que suportam uma política (através do modelo de preferências). Os espaços de trabalho criados antes de as salvaguardas existirem — ou perfis cujo JSON omite o campo — descodificam como Desligado.

Nota: A política de escrita é por serviço, não por credencial. Duas credenciais para o mesmo serviço — digamos dois tokens do GitHub — partilham uma política, pelo que alterar o seletor numa das linhas altera-o para ambas.

Nota: As salvaguardas classificam operações; não ocultam credenciais. A própria credencial continua a ser injetada e trocada pelo proxy conforme configurado em Credenciais. Combine uma política de escrita Só de leitura com a caixa de verificação Perguntar antes de usar da mesma linha para uma defesa em profundidade.

Como cada serviço classifica as chamadas

Os endpoints de base de dados classificam por motor:

Um aviso laranja integrado aparece quando uma política está definida mas não há nada a que ela se possa aplicar — sem kubeconfigs para um contexto do Kubernetes, sem anfitrião definido para um endpoint de base de dados — uma vez que a salvaguarda deixa então de ter anfitriões aos quais aplicar-se.

Nota: Para o ClickHouse, se não houver texto SQL visível no pedido, Só de leitura bloqueia o pedido (o Bromure não consegue provar que é uma leitura), enquanto Bloquear destrutivas deixa-o passar (erra no sentido permissivo).

O diálogo de consentimento (Perguntar antes de escrever)

No modo Perguntar antes de escrever, as leituras passam silenciosamente e cada escrita pausa para um diálogo do anfitrião com o título Allow write on "<scope>" from workspace "<name>"?. O corpo do diálogo mostra a operação exata, na íntegra — a instrução SQL literal para uma base de dados, ou METHOD /path para uma chamada REST — para que aprove o que vai efetivamente correr, e não um resumo. Os botões são:

• Permitir durante 15 minutos (o botão predefinido)
• Permitir uma vez — deliberadamente não cria nenhuma autorização, pelo que a escrita imediatamente seguinte volta a pedir. Útil para auditar um agente falador escrita a escrita.
• Permitir durante o resto da sessão
• Não permitir — o agente recebe o mesmo erro rígido que os modos de bloqueio produzem. A recusa é lembrada durante 60 segundos, para que um agente que tenta repetir a mesma escrita num ciclo não volte a pedir a cada segundo.

As autorizações têm âmbito por espaço de trabalho e por âmbito de protocolo: um anfitrião de API do Kubernetes, a AWS como um todo, um registo de contentores, cada forja git como um todo, ou um anfitrião de base de dados. Permitir escritas no ClickHouse num anfitrião não concede nada em mais lado nenhum. Escritas idênticas concorrentes fundem-se num único diálogo, e todas as decisões existem apenas em memória — as autorizações com âmbito de sessão são apagadas no encerramento da sessão.

Quando o espaço de trabalho é conduzido em modo headless por SSH ou pela CLI, as mesmas quatro escolhas são oferecidas como um pedido de texto dentro do tmux do espaço de trabalho; não responder significa negar.

Nota: As autorizações de escrita das salvaguardas não são listadas em nenhuma janela. A janela Aprovações de Credenciais (menu Janela → Aprovações de Credenciais…) mostra apenas as decisões de consentimento de credenciais — as autorizações de Perguntar antes de usar; uma autorização de política de escrita expira segundo o seu próprio relógio ou no encerramento da sessão.

A firewall de saída

Por baixo das linhas de credenciais, o painel alberga a firewall Ligações de saída do espaço de trabalho: uma tabela de regras ordenada que rege que ligações a VM pode sequer abrir — qualquer protocolo, qualquer destino, e não apenas os serviços que as salvaguardas classificam. As regras são avaliadas de cima para baixo, ganha a primeira correspondência, e um controlo segmentado Tráfego não correspondido escolhe a predefinição para tudo o que nenhuma regra corresponda: Permitir (a predefinição para novos espaços de trabalho) ou Negar, para uma postura fechada, de lista de permissões.

Cada regra tem cinco partes:

Uma área expansível no fundo mostra o mesmo conjunto de regras no seu formato pf canónico — uma regra por linha, terminando em default allow ou default deny — que é como as regras são armazenadas e o que a CLI e os perfis geridos transportam:

allow tcp api.github.com:443
allow web api.example.com GET,POST     # só estes verbos chegam ao site
deny  web api.internal PUT,DELETE      # bloquear estes verbos, permitir os restantes
deny  udp any:53
deny  any 10.0.0.0/8
default deny

A imposição é do lado do anfitrião e feita em camadas, pelo que um agente comprometido não a consegue contornar: o comutador de rede virtual aplica as regras a cada fluxo pelo IP de destino e pelo nome de anfitrião obtido por observação do DNS (todos os protocolos, incluindo TCP e UDP simples), e o proxy MITM aplica-as de novo pelo nome de servidor TLS e — no caso das regras web — pelo método HTTP individual. É a dimensão do método que permite a um espaço de trabalho ler uma API na qual não está autorizado a escrever: allow web api.example.com GET,POST dá ao agente consultas sem mutações, na transmissão, independentemente da ferramenta que dentro da VM faz o pedido.

As edições de regras aplicam-se imediatamente às sessões em execução — guardar o espaço de trabalho atualiza a política ativa sem reiniciar, incluindo para sessões headless. Cada veredicto é registado como uma linha Firewall na janela Cronologia de Segurança e, nas instalações inscritas, como um evento egress.firewall no fluxo da organização.

Nota: A inferência local está isenta por construção: uma regra allow para o endpoint de inferência no anfitrião (bromure.llm) é acrescentada à frente das suas regras, pelo que nem sequer default deny consegue cortar os agentes dos Modelos locais. Esse tráfego nunca sai do seu Mac.

Interceção transparente

A firewall seria meramente indicativa se a VM pudesse simplesmente ignorar o proxy, e por isso já não pode: o comutador virtual desvia de forma transparente os fluxos das portas 80 e 443 da VM para o proxy do anfitrião — sem necessidade de variáveis de ambiente, e sem nada que o convidado possa anular. O HTTP simples na porta 80 é intercetado e inspecionado da mesma forma que o HTTPS. Isto está ativo por predefinição em todos os espaços de trabalho.

A válvula de escape é o interruptor Desativar interceção transparente por baixo da tabela de regras. Ativá-lo impede o comutador de desviar as portas 80 e 443, pelo que as salvaguardas e as regras web da firewall só veem o tráfego que use de forma cooperativa as variáveis de ambiente de proxy — use-o apenas num espaço de trabalho que se avarie genuinamente sob interceção (por exemplo, uma fixação de certificados intensa não coberta pela lista de passagem incorporada), e trate a firewall como indicativa enquanto estiver ativo.

O que o agente vê quando uma chamada é bloqueada

As chamadas bloqueadas devolvem um corpo de erro ao estilo 403 adequado ao protocolo — um JSON Status do Kubernetes, um AccessDeniedException da AWS, uma carga útil DENIED de registo — cuja mensagem termina em "blocked by Bromure Guardrails". O agente vê uma falha de API limpa e comum que pode reportar, em vez de uma ligação suspensa. (Os bloqueios da cadeia de fornecimento usam HTTP 451 em vez disso, precisamente para que os dois sejam distinguíveis num relance — ver Cadeia de fornecimento.)

Limitações

• O push forçado do Git não pode ser distinguido de um push normal na transmissão, pelo que Bloquear destrutivas não o bloqueia — só Só de leitura e Perguntar antes de escrever controlam os pushes. As eliminações explícitas através das APIs REST da forja continuam a ser detetadas.
• As políticas de Kubernetes e de registo de contentores só se aplicam a anfitriões derivados dos kubeconfigs e dos registos configurados do espaço de trabalho; as políticas de base de dados precisam de que o anfitrião do endpoint esteja definido em Credenciais. Uma salvaguarda sem nada a que se aplicar não filtra nada (o painel avisa-o de forma integrada).
• As políticas de escrita abrangem os serviços listados acima; o tráfego para outros anfitriões é governado pelas regras de anfitrião, porta e método da firewall de saída, em vez de por classificação semântica. Para transferências de pacotes, ver Cadeia de fornecimento, e para o tráfego de IA do agente, ver Injeção de prompt.