Salvaguardas

As salvaguardas controlam como as credenciais de uma máquina podem ser usadas (uma máquina é um espaço de trabalho, no editor de definições), como a máquina reage quando um agente bate numa parede ou se comporta de forma estranha, e com que rigor o seu tráfego é intercetado. As ligações que a sua VM pode abrir definem-se em Política de sandbox. Nas palavras do próprio painel: «As salvaguardas governam como são usadas as credenciais configuradas deste espaço de trabalho. Perguntar antes de usar faz surgir uma confirmação do lado do anfitrião na primeira vez que uma credencial é usada numa sessão. Uma política de escrita despoja ou bloqueia operações destrutivas na transmissão — aplicada no proxy, pelo que um agente comprometido não a consegue contornar. Só aparecem aqui as credenciais que configurou.»

O painel tem duas partes: uma linha por credencial, e depois Proteções — as definições comuns aos dois motores de sandbox. (As regras de ligações de saída que estavam aqui passaram para Política de sandbox na 5.4.) Tudo nele se aplica a uma máquina em execução assim que clica em Guardar — sem reinício. Os mecanismos mais fundos estão em Deteção de injeção de prompt e salvaguardas.

Linhas de credenciais

O painel lista todas as credenciais configuradas em Credenciais, na mesma ordem. Cada linha mostra o nome da credencial e os seus anfitriões, uma caixa Exigir aprovação para usar, e — onde o serviço a suporta — um seletor de política de escrita. Sem credenciais, o painel mostra Nenhuma credencial a guardar e aponta-lhe o painel Credenciais.

Exigir aprovação para usar (perguntar antes de usar)

Desligado por predefinição. Quando está ligado, na primeira vez que a credencial é usada numa sessão o proxy põe o pedido em pausa e pergunta, oferecendo Permitir por 5 minutos, Permitir por 1 hora, Permitir pelo resto da sessão, ou Não permitir. As concessões vivem em memória e acabam com a sessão; Janela › Aprovações de credenciais… lista as atuais. Ver Credenciais e a fronteira de transmissão.

Enquanto uma credencial tiver uma concessão ativa, a sua linha mostra o tempo que falta junto à caixa de verificação — uma contagem decrescente laranja (4m, depois 45s) para uma concessão temporizada, permitido nesta sessão para uma concessão até ao fim da sessão, e uma contagem decrescente vermelha negado (ou negado nesta sessão) enquanto uma recusa estiver em vigor. Clique com o botão direito na linha para Permitir por 5 minutos, Permitir por 1 hora ou Permitir pelo resto da sessão, para Negar por 5 minutos, Negar por 1 hora ou Negar pelo resto da sessão (recusado sem perguntar), ou Revogar — perguntar da próxima vez para limpar qualquer uma delas, de modo que a próxima utilização volte a perguntar. Uma permissão ou recusa temporizada conta a partir de agora, por isso uma concessão quase a expirar ganha 5 minutos novos. Estas ações aplicam-se de imediato à sessão em curso; não há nada a guardar. (A contagem decrescente aparece nas definições do próprio espaço de trabalho, no Mac que o executa, e não nas Preferências nem num cliente remoto.)

Nota: uma automatização que use uma credencial com aprovação ligada não pode correr completamente sem vigilância: para no diálogo até você responder no Mac. O editor de automatizações avisa disto.

Política de escrita

Um seletor de política de escrita aparece para:

• tokens de forjas git (GitHub, GitLab, Bitbucket)
• credenciais AWS
• tokens DigitalOcean
• registos de contentores
• contextos Kubernetes
• pontos finais de bases de dados (MongoDB, ClickHouse, Elasticsearch)

As máquinas novas usam Perguntar antes de escrever para todos os serviços (vindo do modelo Predefinições). As máquinas criadas antes de as salvaguardas existirem carregam em Desligado.

Nota: uma política de escrita é por serviço, não por credencial, como nota o painel: «duas credenciais para o mesmo serviço (p. ex. dois tokens do GitHub) partilham uma política.» Alterar qualquer das linhas altera as duas.

Como cada serviço é classificado

Os pontos finais de bases de dados são classificados por motor:

Um aviso laranja aparece quando uma política não tem a que se aplicar — um contexto Kubernetes sem kubeconfig, um ponto final de base de dados sem anfitrião.

Nota: para o ClickHouse, se não houver texto SQL visível no pedido, Apenas leitura bloqueia-o (não se pode provar que é uma leitura) enquanto Bloquear destrutivas o deixa passar.

O diálogo de escrita

Em Perguntar antes de escrever, uma escrita para em Permitir escrita em «âmbito» a partir do espaço de trabalho «nome»?, mostrando a operação palavra por palavra — a instrução SQL, ou MÉTODO /caminho. As escolhas:

• Permitir por 15 minutos (predefinição)
• Permitir uma vez — não cria concessão, pelo que a escrita seguinte volta a perguntar.
• Permitir pelo resto da sessão
• Não permitir — o agente recebe o mesmo erro que devolvem os modos de bloqueio. A recusa é lembrada por 60 segundos, para que um ciclo de repetição não pergunte a cada segundo.

As concessões são por máquina e por âmbito: um servidor de API Kubernetes, a AWS como um todo, um registo, cada forja, ou um anfitrião de base de dados. Escritas idênticas e simultâneas partilham um diálogo. Quando a máquina é usada sem vigilância por SSH ou pela CLI, as mesmas escolhas são perguntadas dentro do tmux da máquina; não responder significa recusar.

Não alertar sobre exfiltração de credenciais

Quando se vê uma credencial a seguir para um anfitrião a que não pertence, o Bromure bloqueia o pedido, põe a VM em pausa, e mostra um alerta de comprometimento com Desligar, Bloquear, Permitir e Guardar para investigação. Permitir passa a confiar nesse destino pelo resto da sessão. Ver Credenciais e a fronteira de transmissão.

Não alertar sobre exfiltração de credenciais desliga esse alerta nesta máquina. A fuga continua a ser bloqueada e continua a ser registada na Linha do tempo de segurança, como «bloqueado — tentativa de exfiltração (alertas desligados, VM não posta em pausa)» — só a interrupção desaparece. Aplica-se ao vivo, sem reinício. Predefinição: desligado.

Proteções

A secção Proteções reúne as definições que se aplicam a uma máquina seja qual for o motor de sandbox que usa. Cada uma aplica-se de imediato a uma máquina em execução.

Avisar o agente quando a política o bloqueia

Tell the agent when policy blocks it — «o agente pergunta-lhe em vez de tentar de novo ou de procurar outro caminho». Quando o firewall, a política OpenShell, a sandbox do convidado ou uma salvaguarda recusa algo que um agente tentou, o agente fica a saber o que foi bloqueado e porquê, e que lhe deve perguntar a si em vez de tentar de novo ou contornar. Sem isto, um agente vê apenas uma ligação falhada ou «permission denied» e pode continuar a tentar. O Claude Code lê a nota logo a seguir ao comando que bateu no bloqueio. O Codex, o Grok, o Kimi e o Oh My Pi recebem-na escrita no fim do seu turno. Enquanto não escolher, está ligado sempre que a máquina usa uma política OpenShell. Veja Avisar o agente.

Vigilante dos agentes

Agent watchdog — «assinala uma sessão que se comporta de forma suspeita; Quarantine também lhe corta a rede e a põe em pausa». O vigilante observa a sessão como um todo, de fora da VM:

• rajadas de pedidos bloqueados;
• credenciais que não pertencem ali;
• sinais de adulteração;
• destinos novos depois de a sessão estabilizar;
• volume de saída muito acima da linha de base da própria sessão (contado no switch de rede, independentemente do proxy).

Quando o alerta não pode ser mostrado neste Mac (um Mac sem ecrã, ou uma máquina espelhada por um cliente remoto), a pergunta vai para o cliente remoto, e sem resposta em três minutos conta como Keep quarantined.

Permitir só as credenciais que o Bromure injeta (modo estrito)

Only allow credentials Bromure injects (strict mode) — «bloqueia qualquer credencial que o Bromure não tenha posto lá ele próprio». Com o modo estrito ligado, um pedido que leve uma credencial que o Bromure não injetou é bloqueado e dispara o alerta de comprometimento; isso cobre uma chave que o agente encontrou num ficheiro, copiou de um registo ou trouxe consigo. Permitir no alerta aprova essa credencial para a sessão. Os tokens que um site emite dentro da VM (um cookie de sessão depois de iniciar sessão, por exemplo) podem continuar a voltar a esse site.

O modo estrito força a interceção transparente e ignora a lista de não-interceção. O tráfego TCP cru não pode ser inspecionado. Cada credencial que a máquina configura precisa primeiro de um filtro de anfitrião; o painel indica as que não o têm. Desligado por predefinição; a sua organização pode exigi-lo.

Desativar a interceção transparente

Por predefinição, o comutador virtual desvia as ligações HTTP e HTTPS da VM (portas 80 e 443) para o proxy do Bromure ao nível da rede, de modo que o proxy as veja mesmo quando um programa ignora as definições de proxy.

Ligar Desativar a interceção transparente faz parar apenas esse desvio forçado. Os programas que abrem ligações cruas, e as aplicações que fixam certificados, passam então a alcançar a rede — e o certificado verdadeiro do servidor — diretamente. O próprio proxy fica ligado: HTTP_PROXY / HTTPS_PROXY continuam definidos, pelo que as ferramentas que sabem usar um proxy (apt, git, pip, curl, node…) e as chamadas de API dos próprios agentes continuam a passar pelo Bromure e mantêm a substituição de credenciais, o rastreio e as salvaguardas. Aplica-se ao vivo, sem reinício. Indisponível enquanto o modo estrito estiver ligado.

Use-o para uma máquina cujo cliente se parte sob interceção. Enquanto estiver ligado, o tráfego dos programas que contornam as definições de proxy não é visto pelas regras web do firewall nem pelas políticas de escrita.

Permitir desvio inseguro por pedido (X-bromure-insecure)

Uma saída de emergência mais estreita, para servidores com certificado autoassinado ou de uma CA privada. Quando um pedido a um anfitrião desses falha a validação de certificado, o agente pode repeti-lo com o cabeçalho X-bromure-insecure: yes, e o Bromure deixa de validar o certificado desse servidor nesse pedido. A interceção, o rastreio e a guarda contra fugas ficam ligados, e o Bromure não põe nenhuma credencial verdadeira num pedido desses — só saem os substitutos da VM. Todo o uso é registado na Linha do tempo de segurança.

Ligado por predefinição: só atua quando a VM envia explicitamente o cabeçalho. Desligue-o para recusar o cabeçalho de imediato.

O que o agente vê quando uma chamada é bloqueada

Uma chamada bloqueada devolve um erro comum no formato próprio do serviço — um Status do Kubernetes, uma AccessDeniedException da AWS, um DENIED de registo — cuja mensagem acaba em «blocked by Bromure Guardrails». O agente vê uma falha limpa que pode relatar, não uma ligação pendurada. (Os bloqueios de cadeia de fornecimento usam HTTP 451 em vez disso, pelo que os dois se distinguem com facilidade — ver Cadeia de fornecimento.)

Limitações

• Um force-push parece um push normal na transmissão, pelo que Bloquear destrutivas não o impede; Apenas leitura e Perguntar antes de escrever já filtram os pushes. As eliminações pela API REST da forja são apanhadas.
• As políticas de Kubernetes e de registos só cobrem anfitriões vindos dos kubeconfigs e dos registos desta máquina; uma política de base de dados precisa do anfitrião do ponto final.
• Os outros anfitriões regem-se pelas regras de anfitrião, porta e método da Política de sandbox, não por uma classificação ao nível do serviço.

Referência de definições

Capítulos relacionados

• Credenciais — as credenciais que estas linhas governam.
• Política de sandbox — as regras de saída da máquina ou a sua política OpenShell.
• Deteção de injeção de prompt e salvaguardas — a aplicação em profundidade.
• Visão geral e linha do tempo de segurança — cada bloqueio e cada permissão, por máquina.
• Referência de Definições — todos os painéis num relance.