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.

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 salvaguardas abrangem os serviços listados acima. O tráfego HTTPS arbitrário para outros anfitriões não é classificado — para transferências de pacotes, ver Cadeia de fornecimento, e para o tráfego de IA do agente, ver Injeção de prompt.