Credenciais e a fronteira de transmissão

Uma sessão de programação agêntica precisa de credenciais — uma chave da Anthropic para falar com o Claude, um token do GitHub para fazer push, chaves da AWS para implementar. Além disso, executa código arbitrário, instala pacotes arbitrários e segue instruções de ficheiros que não escreveu. Entregar os seus segredos reais a um ambiente destes é a forma como as chaves acabam na caixa de entrada de um ladrão.

O Bromure Agentic Coding resolve esta tensão com a fronteira de transmissão: o agente dentro da VM só alguma vez vê tokens de substituição falsos. As suas credenciais reais residem encriptadas no anfitrião macOS e são substituídas na transmissão por um proxy MITM do lado do anfitrião no último momento possível — depois de o pedido ter saído da VM, e apenas quando se destina ao anfitrião a que a credencial pertence. Nenhum ficheiro, variável de ambiente ou processo dentro da VM contém alguma vez uma chave de API real, token OAuth, segredo da AWS ou chave privada SSH.

Este capítulo explica o mecanismo de ponta a ponta e, em seguida, percorre cada tipo de credencial suportado e o seu ciclo de vida, o sistema de aprovação por utilização, o detetor de compromisso e como verificar a fronteira você mesmo.

Nota: Este capítulo aborda os conceitos e o comportamento em tempo de execução. Para uma referência campo a campo do painel de definições, consulte Definições → Credenciais.

A fronteira de transmissão em resumo

Três princípios definem o modelo:

1. Falsificações na VM. Cada credencial que configura é substituída dentro da VM por uma falsificação que preserva a estrutura. As falsificações mantêm a forma que os validadores esperam — uma falsificação da Anthropic começa por sk-ant-api03-brm-, uma falsificação do GitHub é ghp_ mais 36 caracteres — para que ferramentas como o claude, o gh e o doctl as aceitem sem reclamar.
2. Reais apenas na transmissão. Cada pedido HTTPS que a VM faz é encaminhado por túnel para o proxy do anfitrião, que o desencripta, troca a falsificação pelo valor real e reencripta a montante. A troca é limitada ao anfitrião de destino para o qual a credencial foi cunhada.
3. Falha fechada. Se algo contornar o proxy, o pedido transporta apenas uma falsificação e a autenticação a montante falha. Não existe nenhum caminho no qual um segredo real vaze por acidente.

As falsificações são determinísticas: cada uma é derivada do valor real mais um salt de 32 bytes por instalação através de HKDF-SHA256. A mesma chave real mapeia sempre para a mesma falsificação no seu Mac, pelo que os clientes que identificam a sua chave por impressão digital (o Claude Code coloca em cache um hash da chave, por exemplo) nunca veem a credencial "rodar" entre sessões.

Não existe um interruptor de ligar/desligar para a fronteira. O proxy é a única via de saída da VM; a troca é simplesmente como as credenciais funcionam nesta aplicação.

Como funciona a troca de ponta a ponta

A viagem de ida e volta completa de um pedido autenticado:

1. Arranque da sessão — o plano de tokens. Quando uma VM de espaço de trabalho arranca, a aplicação constrói um plano de tokens por espaço de trabalho que emparelha cada credencial real com a sua falsificação derivada. As falsificações são escritas na VM: variáveis de ambiente (ANTHROPIC_API_KEY, GH_TOKEN, LINEAR_API_KEY, …) e ficheiros de configuração (~/.git-credentials, ~/.docker/config.json, ~/.kube/config, ~/.aws/config, ~/.config/doctl/config.yaml, configurações MCP). Os valores reais são carregados no mapa de troca em memória do proxy, cada um associado ao anfitrião de destino a que pertence.
2. O pedido sai da VM. O tráfego HTTPS do convidado é encaminhado por túnel através de um socket virtio (vsock porta 8443) para o proxy do anfitrião. A VM não tem outra rota para a rede.
3. Terminação TLS. O proxy apresenta um certificado folha forjado por anfitrião — o nome de anfitrião de destino como CN e SAN, uma chave EC por anfitrião — assinado pela Bromure Agentic Coding Root CA. Como o certificado público dessa CA foi instalado no arquivo de confiança da VM no arranque, os clientes TLS do convidado aceitam a ligação, e o proxy pode ler o pedido em texto simples.
4. A troca. O proxy procura cada token falso que aparece no pedido (cabeçalhos e, para tipos de credencial que optaram por isso, o corpo) e, se o anfitrião de destino corresponder ao âmbito da credencial, substitui-o pelo valor real.
5. Reencriptação a montante. O pedido reescrito é reemitido para o destino real através do URLSession da Apple, ou seja, a própria pilha TLS do macOS, que valida o certificado genuíno do servidor a montante. A resposta é transmitida de volta através do túnel para o convidado.

Se o destino não corresponder ao âmbito de uma falsificação, a falsificação sai inalterada (e falha a autenticação a montante) — ou, quando a incompatibilidade parece exfiltração, o pedido é bloqueado de imediato (consulte O detetor de compromisso abaixo).

A Bromure Agentic Coding Root CA

A CA é por instalação e reside em ~/Library/Application Support/BromureAC/ca/ (cert.pem mais um key.pem em modo 0600). O seu assunto é "Bromure Agentic Coding Root CA", organização "Bromure". Propriedades que vale a pena conhecer:

• A validade da CA é de 10 anos. Os certificados folha forjados por anfitrião são válidos por 1 ano e retroativos em 24 horas, pelo que um convidado cujo relógio se desviou durante suspensão/retoma continua a aceitá-los. As folhas são colocadas em cache por anfitrião durante o tempo de vida do processo da aplicação.
• O certificado público é instalado no arquivo de confiança de cada VM no arranque (entregue através da meta share e aplicado com update-ca-certificates). Nunca sai da sua máquina e não é confiável por nada exceto pelas suas VMs.
• Para rodar a CA, saia da aplicação e elimine o diretório ca/. Uma nova CA é cunhada no arranque seguinte e cada VM adota o novo certificado público no seu arranque seguinte. A rotação não invalida mais nada — os segredos do espaço de trabalho e os metadados de profile.json permanecem intactos.

Delimitação por anfitrião

Cada entrada de troca está associada a um âmbito de anfitrião. A correspondência é exata-ou-subdomínio e insensível a maiúsculas/minúsculas, nunca por subcadeia: uma credencial com âmbito openai.com corresponde a api.openai.com mas não a openai.com.evil.example — um anfitrião com aparência semelhante não consegue enganar o proxy para que decore o seu pedido com uma chave real. As regras de token manual podem usar deliberadamente um filtro de anfitrião em branco, o que significa "injetar em qualquer anfitrião"; essa é uma escolha explícita que faz por entrada (consulte Chaves de API genéricas).

Falha fechada por construção

O design nunca depende de o proxy ser inevitável para o sigilo — depende de os segredos não estarem lá:

• Um pedido que de alguma forma salta o proxy transporta um token falso; a API a montante rejeita-o.
• Os pedidos da AWS assinados dentro da VM são assinados com uma chave secreta falsa; se chegassem diretamente à AWS falhariam com InvalidSignatureException (consulte AWS abaixo).
• Os bytes da chave privada SSH nunca estão de todo na VM; apenas as assinaturas atravessam a fronteira.

Gerir credenciais no editor de espaços de trabalho

As credenciais são configuradas por espaço de trabalho. Abra o editor do espaço de trabalho (Editar espaço de trabalho) e selecione Credenciais na barra lateral.

O painel abre com Identidade Git (um nome e email escritos em ~/.gitconfig na VM; deixe ambos em branco para manter os valores predefinidos do git — os marcadores de posição são apenas exemplos, não credenciais), seguido de uma lista apenas das credenciais que configurou, agrupadas sob cabeçalhos de categoria (Agentes, Git, Cloud, Bases de dados, SSH, Outros). Dois botões situam-se no fundo: Adicionar credencial abre um seletor dos tipos de credencial — token Git, chave SSH, credenciais AWS, token DigitalOcean, chave de API do Linear, Kubernetes, registo de contentores, base de dados e outra chave de API — e Importar ficheiro env… importa em massa a partir de um .env ou de um ~/.bashrc. A chave do próprio agente principal reside no painel Agentes, descrito a seguir. Clique em Guardar; o arranque da sessão seguinte escreve as falsificações na VM e carrega os reais no proxy.

O portão de aprovação por credencial (Perguntar antes de usar) e a política de escrita de cada serviço são definidos no painel Salvaguardas, não aqui — o painel Credenciais já não transporta esses controlos. Consulte Definições → Credenciais para a referência campo a campo.

Seis fornecedores são tratados automaticamente — a Anthropic, a OpenAI, o GitHub, o GitLab, a DigitalOcean e o Kubernetes não precisam de regras de token manual; as suas secções dedicadas cobrem-nos. Tudo o resto passa por Outras chaves de API.

Importar a partir de um ficheiro env. Importar ficheiro env… lê um ficheiro .env existente — ou um ~/.bashrc — e transforma as suas variáveis em credenciais. O analisador processa KEY=VALUE e export KEY=VALUE, remove aspas circundantes e comentários finais, e ignora deliberadamente qualquer coisa que precisaria de avaliação pela shell (interpolação $VAR ou substituição $(…)), pelo que é seguro apontá-lo a um .bashrc real. Uma folha de revisão mostra então as variáveis com valores mascarados: nomes reconhecidos (ANTHROPIC_API_KEY, OPENAI_API_KEY, XAI_API_KEY, GH_TOKEN/GITHUB_TOKEN, GITLAB_TOKEN, AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN, DIGITALOCEAN_ACCESS_TOKEN, LINEAR_API_KEY) mapeiam automaticamente para o seu tipo de credencial, enquanto os nomes não reconhecidos podem ser importados como tokens manuais genéricos com um âmbito de anfitrião separado por vírgulas que você fornece. As entradas já configuradas são sinalizadas e deixadas desmarcadas, para que uma reimportação nunca sobrescreva um segredo silenciosamente.

Tipos de credenciais

Chaves de API do agente principal (Anthropic, OpenAI, xAI)

A chave do agente principal do espaço de trabalho é definida no painel Agentes, onde cada cartão de agente oferece um seletor de modo de autenticação.

Escolha Token de API e cole a chave no campo (Chave de API da Anthropic para o Claude Code, Chave de API da OpenAI para o Codex, a chave da xAI para o Grok Build). Ciclo de vida:

• Na VM: exportada como ANTHROPIC_API_KEY / OPENAI_API_KEY / XAI_API_KEY, contendo a falsificação com a forma do fornecedor (sk-ant-api03-brm-…, sk-brm-…, xai-brm-…).
• Na transmissão: trocada pela chave real nos pedidos aos anfitriões do fornecedor (anthropic.com, openai.com, x.ai respetivamente).
• Aprovação: para condicionar a primeira utilização de cada sessão, ative Perguntar antes de usar para a chave do agente no painel Salvaguardas (consulte Aprovação por utilização). Está desativado por predefinição.

Os outros modos de autenticação no seletor — Subscrição (início de sessão interativo), Bedrock (AWS) e Modelo local — são abordados abaixo e em Modelos locais. A partir da CLI, a mesma escolha é --auth token|subscription|bedrock|local em bromure-cli workspaces create (e token|subscription|bedrock em bromure-cli vm run para espaços de trabalho instantâneos).

Subscrições do Claude, Codex e Grok

Se tiver uma subscrição do Claude, ChatGPT (Codex) ou Grok em vez de uma chave de API, o agente normalmente autentica-se por início de sessão OAuth interativo — um fluxo de navegador que uma VM em sandbox não consegue (e não deve) completar com tokens reais. O Bromure Agentic Coding suporta subscrições com dois mecanismos. Ambos terminam no mesmo lugar: os tokens OAuth reais residem apenas no anfitrião, e o convidado corre com uma chave fictícia.

Registar com o Claude / ChatGPT / Grok (recomendado)

Defina o modo de autenticação do agente para Subscrição (início de sessão interativo) e clique em Registar…. O que acontece:

1. A aplicação verifica que o proxy está em execução (o registo é recusado caso contrário) e mostra uma folha explicativa intitulada Registar com o Claude (ou ChatGPT / Grok). Clique em Continuar.
2. Uma VM de registo descartável arranca — temporária, isolada, sem montagens de pastas de espaço de trabalho e sem mapa de troca de credenciais. Dentro dela, corre o comando de início de sessão real (claude login, codex login, ou o equivalente do Grok).
3. O navegador predefinido do seu Mac abre a página de início de sessão do fornecedor. Inicie sessão como habitualmente. Tem cerca de 4 minutos antes de o fluxo expirar.
4. Os tokens OAuth resultantes são capturados no anfitrião, encriptados e armazenados; a VM descartável é destruída.
5. Se iniciou o registo a partir de um editor de espaço de trabalho, a aplicação pergunta Partilhar com todos os espaços de trabalho? — escolha Todos os espaços de trabalho para armazenar a subscrição como a predefinição partilhada, ou Apenas este espaço de trabalho. O registo iniciado a partir das Preferências da aplicação armazena sempre a predefinição partilhada sem perguntar.

A partir daí, o convidado de cada sessão corre em modo de chave de API com uma credencial fictícia determinística — um ANTHROPIC_API_KEY falso para o Claude, um ~/.codex/auth.json semeado contendo um JWT fictício com expiração num futuro distante para o Codex (para que o cliente nunca tente atualizá-lo ele próprio), um ~/.grok/auth.json de marcador de posição para o Grok. O proxy reconhece o valor fictício e injeta um token de acesso Authorization: Bearer ativo (além do cabeçalho OAuth beta, para o Claude) na transmissão.

A custódia e a atualização dos tokens são inteiramente do lado do anfitrião. O anfitrião atualiza os tokens cerca de 5 minutos antes da expiração face ao endpoint de tokens do fornecedor (platform.claude.com/v1/oauth/token para o Claude, auth.openai.com/oauth/token para o Codex, auth.x.ai/oauth2/token para o Grok), pelo que uma atualização serve cada VM em execução e o convidado nunca detém um token de atualização. Um registo recém-capturado é armazenado deliberadamente com uma expiração já passada, forçando uma atualização na primeira utilização — provando que o caminho de atualização funciona antes de depender dele.

Os controlos junto ao seletor de modo de autenticação completam o ciclo de vida: Registar novamente… repete a captura (por exemplo, depois de revogar sessões a montante), e Esquecer elimina a subscrição armazenada do anfitrião.

A troca de token na sessão

Em alternativa, se o agente iniciar sessão ele próprio dentro da VM (você executa claude login na sessão), o proxy repara num token OAuth de subscrição real a sair para o fornecedor e oferece-se para tomar a sua custódia. Aparece uma folha — Trocar o token de subscrição do Claude? (ou Codex) — explicando que o token real pode permanecer neste Mac enquanto uma falsificação o substitui no ficheiro de credenciais da VM. Tanto o token de acesso como o de atualização são trocados em conjunto. As suas opções:

O estado por espaço de trabalho por detrás deste pedido é visível no editor como Troca de token de subscrição do Claude / Troca de token de subscrição do Codex (não definido por predefinição; "aceite" ou "recusado" depois de escolher). O canal de troca anfitrião-para-VM é deliberadamente unidirecional: o anfitrião só pode escrever falsificações na VM, e a VM só pode enviar reais para o anfitrião — não existe nenhum RPC pelo qual a VM possa pedir um token real de volta. O agente na VM recusa-se adicionalmente a escrever qualquer credencial que não transporte o prefixo de falsificação brm-, pelo que mesmo um anfitrião com mau comportamento não consegue corromper o ficheiro de credenciais do convidado com um valor real.

Nota: O Codex permanece em modo de subscrição dentro do convidado (o seu modo de chave de API tem como alvo um backend diferente), e os tokens do Grok viajam através do ficheiro ~/.grok/auth.json em vez de um agente vsock. Estes são detalhes de implementação; o modelo de custódia é idêntico.

AWS

A AWS recebe o tratamento mais profundo de qualquer fornecedor, porque os pedidos da AWS não são autenticados por um token bearer — são assinados (SigV4). Abra Credenciais → AWS no editor de espaços de trabalho; um controlo segmentado escolhe entre Chaves estáticas e SSO / Identity Center.

Chaves estáticas e o reassinador do anfitrião

Cole o seu ID da chave de acesso e a Chave de acesso secreta (mais um Token de sessão STS opcional e uma Região predefinida). O ciclo de vida:

• Na VM: ~/.aws/config aponta para um auxiliar credential_process que fornece — através da vsock porta 8445 — o ID real da chave de acesso emparelhado com uma Chave de acesso secreta falsa de 40 caracteres, omitindo o token de sessão. Cada SDK da AWS, a CLI aws, o terraform e o boto3 adotam isto nativamente; não é necessária configuração específica de ferramenta.
• O que o convidado faz: assina os seus pedidos com o segredo falso, produzindo uma assinatura SigV4 sintaticamente válida mas criptograficamente condenada.
• Na transmissão: o reassinador AWS do anfitrião deteta pedidos destinados a *.amazonaws.com e *.amazonaws.com.cn (GovCloud, ISO, regionais e anfitriões S3 de estilo bucket incluídos), remove a assinatura do convidado, injeta o X-Amz-Security-Token real quando existe um token de sessão, e reassina com o segredo real antes de o pedido sair do seu Mac. Cada reassinatura bem-sucedida emite um evento de auditoria credential.aws_sign com uma chave de acesso mascarada, visível em Rastreio.

Isto é falha-fechada no sentido mais forte: a chave secreta real nunca existe na VM sob qualquer forma, e um pedido que contorne o proxy é rejeitado pela AWS com InvalidSignatureException.

Três estilos de pedido não são suportados e devolvem um erro claro ao convidado em vez de uma falha silenciosa: carregamentos S3 em streaming por blocos (STREAMING-AWS4-HMAC-SHA256-PAYLOAD, respondidos com 501), assinatura assimétrica SigV4A e URLs de query-string pré-assinados (que incorporam a assinatura onde o reassinador não a consegue substituir).

SSO / IAM Identity Center

Se a sua organização usa o IAM Identity Center, selecione SSO / Identity Center em vez de colar chaves de longa duração:

1. Clique em Conceder acesso a ~/.aws e aprove o pedido de acesso à pasta (uma concessão com âmbito de segurança; a pasta é lida no anfitrião e nunca montada na VM).
2. Escolha o seu perfil no seletor Perfil SSO. A aplicação descobre secções [profile …] em ~/.aws/config que transportam sso_start_url, sso_account_id e sso_role_name, resolvendo referências [sso-session …]; o ID da conta e a função são mostrados apenas para leitura.
3. No arranque da sessão, o anfitrião resolve as credenciais de função temporárias a partir da cache de tokens SSO (~/.aws/sso/cache). Se o token em cache tiver expirado, o seu navegador abre para aws sso login — executado no anfitrião, a partir de /usr/local/bin/aws.

As chaves temporárias resolvidas alimentam o mesmo reassinador que as chaves estáticas; a VM continua a nunca ver um segredo. As credenciais atualizam-se automaticamente no anfitrião cerca de 5 minutos antes de expirarem.

Bedrock

Bedrock (AWS) no seletor de modo de autenticação do agente executa o Claude Code contra o AWS Bedrock usando quaisquer credenciais AWS que o espaço de trabalho tenha configurado (estáticas ou SSO) — é um modo de autenticação da ferramenta principal, não uma credencial separada. Defina o modo de autenticação, configure Credenciais → AWS, e opcionalmente defina um ID de modelo Bedrock no espaço de trabalho. A assinatura passa pelo mesmo caminho de reassinatura, uma vez que os endpoints do Bedrock são anfitriões *.amazonaws.com.

Tokens Git HTTPS (GitHub, GitLab, Bitbucket, auto-hospedados)

Os tokens de acesso pessoal para git-sobre-HTTPS residem em Tokens do GitHub / Tokens do GitLab / Tokens do Bitbucket (coletivamente, tokens HTTPS). Cada entrada recebe um anfitrião, um nome de utilizador e o token; instâncias auto-hospedadas de GitLab ou Gitea funcionam definindo o campo de anfitrião. Ciclo de vida:

• Na VM: uma falsificação é escrita em ~/.git-credentials e na configuração do gh/glab; GH_TOKEN e GITLAB_TOKEN são exportados para que as CLIs se autentiquem automaticamente. As formas das falsificações correspondem aos validadores de cada fornecedor (ghp_ + 36 para o GitHub, glpat- + 20 para o GitLab, brm_… caso contrário), pelo que as verificações de prefixo e comprimento no gh e no glab passam.
• Na transmissão: trocada pelo token real nos pedidos ao anfitrião git dessa entrada.
• Aprovação: cada entrada obtém a sua própria linha Perguntar antes de usar no painel Salvaguardas.

Se só precisar de git push sobre SSH, pode não precisar de todo de um token HTTPS — consulte Chaves SSH abaixo.

Chaves de API genéricas (Outras chaves de API / Regras de token manual)

Para qualquer API que a aplicação não trate automaticamente, adicione uma entrada em Outras chaves de API (as regras de token manual, também apresentadas como Troca de token MITM). Clique em Adicionar token e forneça:

Dois casos-limite são deliberados:

• Nome da variável de ambiente vazio: nada é exportado; você copia a falsificação do banner de boas-vindas da sessão e coloca-a onde as suas ferramentas precisarem.
• Filtro de anfitrião em branco: o valor real é injetado em qualquer anfitrião, sem perguntar. Essa é uma escolha explícita sempre ativa — útil para APIs com muitos nomes de anfitrião regionais — mas significa que o âmbito da credencial já não a protege. Para condicionar um segredo sem âmbito, ative Perguntar antes de usar para ele no painel Salvaguardas (ou atribua-lhe afinal um filtro de anfitrião).

A Anthropic, a OpenAI, o GitHub, o GitLab, a DigitalOcean e o Kubernetes nunca precisam de entradas manuais aqui.

Referências de segredos 1Password (op://)

Em vez de colar um segredo real, o valor de uma Outra chave de API pode ser uma referência de segredo 1Password — op://vault/item/field, ou a forma com chavetas {{ op://vault/item/field }} que o op inject e os ficheiros .env.op usam. Apenas a referência é alguma vez armazenada em disco; o próprio segredo nunca é escrito em lado nenhum no anfitrião ou na VM. O editor reconhece a referência, mostra-a às claras (não é um segredo) e nota que se resolve através do 1Password.

Em cada arranque de espaço de trabalho, o Bromure resolve a referência do lado do anfitrião com a CLI do 1Password (op read), cunha uma falsificação a partir da cadeia de referência (para que a falsificação permaneça estável mesmo quando o segredo roda) e exporta apenas essa falsificação para a VM. O proxy MITM troca então a falsificação pelo valor resolvido na transmissão, exatamente como faz para um segredo colado — e volta a resolver a cada 2 minutos, pelo que rodar o item no 1Password entra em vigor dentro de alguns minutos sem reiniciar.

Isto precisa da CLI op instalada e com sessão iniciada — desbloqueio biométrico através da aplicação 1Password, ou op signin num terminal. Se o op não for encontrado, o editor mostra uma ligação Obter a CLI do 1Password e o espaço de trabalho apresenta instruções de instalação no arranque; se a resolução falhar (sem sessão iniciada, ou o item não existe), o Bromure apresenta o erro para que o possa corrigir e reiniciar o espaço de trabalho.

Importar um ficheiro .env ou .env.op (Importar de .env… no editor) reconhece valores op:// automaticamente — sob nomes reconhecidos como ANTHROPIC_API_KEY ou arbitrários como STRIPE_KEY — e armazena cada um como um token manual que contém a referência.

DigitalOcean

Cole um token de acesso pessoal em Credenciais → DigitalOcean (a ligação Abrir a página de tokens da DigitalOcean no seu navegador leva-o à geração de tokens). A falsificação (dop_v1_ + hex, 64 caracteres) é exportada como DIGITALOCEAN_ACCESS_TOKEN e escrita em ~/.config/doctl/config.yaml, pelo que doctl auth init é desnecessário. A troca cobre pedidos a digitalocean.com, mais uma segunda entrada para o blob de autenticação Basic em base64 usado por docker login / doctl registry login contra registry.digitalocean.com, pelo que os pushes e pulls de registo também se resolvem.

Linear

Cole uma chave de API pessoal em Credenciais → Linear (ligação: Abrir as definições de API do Linear no seu navegador; as chaves vêm de linear.app → Settings → API). A falsificação (lin_api_ + 40) é exportada como LINEAR_API_KEY, que o SDK do Linear, os servidores MCP e as ferramentas de CLI adotam automaticamente; a troca tem âmbito estritamente limitado a linear.app (GraphQL em api.linear.app e MCP em mcp.linear.app). Uma chave do Linear no espaço de trabalho é também o pré-requisito para os gatilhos de automatização de issues do Linear — consulte Automatização e CLI.

Tokens bearer de servidor MCP

Os servidores MCP de transporte HTTP configurados no painel MCP recebem o mesmo tratamento: o token bearer real permanece no anfitrião, uma falsificação brm-mcp_… é injetada na configuração MCP que o agente lê, e o proxy troca-a na transmissão, com âmbito no anfitrião do servidor. Apenas os servidores de transporte HTTP ativados com um token bearer não vazio recebem uma entrada de troca.

Uma cortesia extra: para anfitriões com uma entrada brm-mcp_, o proxy responde aos caminhos de descoberta OAuth/OIDC (endpoints .well-known de servidor de autorização, recurso protegido e configuração OpenID) com 404. O Claude Code trata então o servidor como pré-autenticado em vez de tentar o seu próprio fluxo OAuth — que de qualquer forma nunca poderia completar-se dentro da VM.

Registos de contentores (Docker Hub, GHCR e afins)

Credenciais → Registos de contentores gere a autenticação HTTP Basic para docker pull/push. Existem predefinições para o Docker Hub (docker.io), o GitHub Container Registry (ghcr.io) e o GitLab Container Registry (registry.gitlab.com); qualquer outro registo pode ser adicionado por anfitrião. Ciclo de vida:

• Na VM: ~/.docker/config.json contém um blob de autenticação falso — o base64 do seu nome de utilizador emparelhado com uma palavra-passe brm-docker-… derivada — para que o Docker acredite estar com sessão iniciada.
• Na transmissão: o proxy substitui o blob base64 real no anfitrião de registo correspondente. A dança de tokens da distribution-spec também é tratada: as entradas de troca são adicionadas para realms de autenticação conhecidos (o Docker Hub autentica-se contra auth.docker.io, o registo da DigitalOcean contra api.digitalocean.com).
• Importação: clique em Importar config.json… para extrair entradas de um ~/.docker/config.json existente no anfitrião. As entradas delegadas a credsStore/credHelpers são ignoradas — as suas palavras-passe residem no keychain do SO, não no ficheiro — e o resumo da importação relata quantas foram ignoradas e porquê.
• Aprovação: por registo, através de Perguntar antes de usar no painel Salvaguardas. Remover este registo elimina uma entrada.

Contextos Kubernetes

Credenciais → Kubernetes transforma contextos de kubeconfig em acesso ao cluster mediado por proxy. Clique em Importar kubeconfig para analisar um kubeconfig existente numa linha por contexto (o contexto atual primeiro, tipo de autenticação detetado automaticamente), ou Adicionar contexto para introduzir manualmente um URL de servidor, credenciais, namespace e CA do cluster. Em todos os casos, a VM recebe um ~/.kube/config sintético: o kubectl no convidado fala com o proxy (confiado através da CA do Bromure), nunca diretamente com o servidor de API.

Por tipo de autenticação:

• Os contextos de token bearer recebem um marcador de posição brm-k8s-… na VM, trocado pelo token real na transmissão.
• Os contextos de certificado de cliente recebem um certificado e chave autoassinados descartáveis na VM; o certificado e a chave reais são registados no anfitrião como um SecIdentity e usados para mTLS a montante.
• Os contextos de plugin exec nunca executam de todo o plugin na VM. O poller de plugin exec executa o comando no anfitrião a cada intervalo de atualização (predefinição 600 segundos, mínimo 60), analisa o JSON ExecCredential e alimenta o token fresco no mapa de troca. As atualizações preservam o estado de consentimento da entrada.

Se o kubeconfig fornecer a CA própria do cluster, ela é reencaminhada para que o proxy possa verificar o servidor de API a montante. Os campos de caminho de ficheiro num kubeconfig importado (CA, cert, chave) são lidos avidamente no momento da importação — alterações posteriores a esses ficheiros em disco não são adotadas. Cada contexto obtém a sua própria linha Perguntar antes de usar no painel Salvaguardas, onde uma política de escrita pode adicionalmente remover verbos destrutivos (kubectl delete, AWS Delete*/Terminate*, docker push, git push) do lado do anfitrião antes de um byte ser reencaminhado — uma camada separada da troca de credenciais.

Bases de dados HTTP (MongoDB, ClickHouse, Elasticsearch)

Credenciais → Bases de dados (as secções MongoDB / ClickHouse / Elasticsearch) cobre endpoints de base de dados que falam HTTPS — a Data API do Mongo, a interface HTTP do ClickHouse, o Elastic. Cada endpoint recebe um motor, anfitrião, segredo, nome de utilizador, tipo de autenticação e um ou mais nomes de variável de ambiente (separados por vírgulas) sob os quais a falsificação brm-db-… é exportada; referencie essas variáveis a partir do seu código ou cadeias de ligação.

As credenciais de base de dados são a única família em que a troca varre o corpo do pedido além dos cabeçalhos e parâmetros de consulta, porque os segredos de ligação viajam rotineiramente dentro de cargas úteis JSON ou SQL. O proxy corrige o Content-Length após uma troca no corpo; corpos multipart ou binários não relacionados de outro tráfego nunca são tocados (todas as outras trocas têm âmbito nos cabeçalhos). Os endpoints de autenticação Basic também têm o seu blob base64 de utilizador-e-segredo trocado. O Perguntar antes de usar por endpoint e a política de escrita são definidos no painel Salvaguardas.

Chaves SSH

O SSH é tratado sem qualquer token: o SSH_AUTH_SOCK da VM é suportado por uma ponte ssh-agent sobre vsock (porta 8444). O convidado pode listar identidades e solicitar assinaturas, mas os bytes da chave privada residem apenas no anfitrião e fisicamente não podem ser lidos ou extraídos de dentro da VM. Existem duas fontes de chave, ambas em Credenciais → Chaves SSH:

• A chave predefinida por espaço de trabalho. Um par de chaves ed25519 predefinido partilhado é gerado no arranque da aplicação (armazenado em default-ssh/ no Application Support) e copiado para o diretório do agente de cada novo espaço de trabalho. O painel mostra a chave pública do espaço de trabalho para que a possa colar no seu anfitrião git (para o GitHub: github.com/settings/keys). Também pode cunhar uma chave nova a partir da CLI com bromure-cli workspaces ssh-keygen <workspace-id|name>, que imprime a nova chave pública.
• Chaves importadas. Clique em Importar… / Importar ficheiro… em Chaves SSH importadas e aponte a aplicação a um ficheiro de chave privada existente — RSA, ed25519 e ECDSA são suportadas, chaves encriptadas incluídas. Uma chave encriptada pede a sua palavra-passe uma vez na importação; a palavra-passe é armazenada no Keychain do macOS (serviço io.bromure.agentic-coding.ssh-key-passphrases) e fornecida via SSH_ASKPASS no arranque, nunca registada. A assinatura de chaves importadas flui através de um processo ssh-agent privado que a aplicação gera para si própria (ssh-agent -D num socket sob o diretório temporário) — separado de qualquer outra coisa no seu sistema.

Por chave importada, ativar Perguntar antes de usar no painel Salvaguardas faz com que cada pedido de assinatura na VM peça consentimento. Cada assinatura — chave predefinida ou importada — emite um evento de auditoria credential.ssh_sign que transporta a impressão digital SHA256 da chave e se se tratou de uma chave gerida ou importada.

Nota: O seu ssh-agent de início de sessão do macOS (o do launchd) é deliberadamente nunca exposto à VM. Apenas as chaves por espaço de trabalho e as chaves que importou explicitamente são alcançáveis a partir de uma sessão.

Aprovação por utilização e durações de concessão

Qualquer credencial neste capítulo pode ser sinalizada com Perguntar antes de usar — uma caixa de verificação por credencial no painel Salvaguardas (rotulada Exigir aprovação para usar no próprio controlo), desativada por predefinição, descrita na interface como: "Apresenta um diálogo de confirmação na primeira vez que esta credencial é usada numa sessão."

Quando uma credencial condicionada é usada pela primeira vez numa sessão, o proxy retém o pedido e mostra um diálogo de consentimento intitulado Permitir que "nome do espaço de trabalho" use a credencial? (com o nome do seu espaço de trabalho e a etiqueta da credencial preenchidos), oferecendo quatro botões:

Comportamento que vale a pena conhecer:

• Coalescência. Pedidos concorrentes que precisam da mesma credencial colapsam num único diálogo — um agente falador que dispara doze chamadas de API paralelas produz um único pedido, e as doze seguem a sua decisão.
• A recusa vence. Uma recusa ativa faz curto-circuito antes de qualquer permissão mais antiga ser consultada.
• Efémero por design. As concessões e recusas são retidas apenas em memória e são revogadas no desmantelamento da sessão. "Resto da sessão" nunca sobrevive ao fecho de uma janela, e nada é persistido entre execuções da aplicação.
• Sessões sem interface. Numa sessão SSH ou sem interface, o pedido aparece no tmux do espaço de trabalho em vez de como um alerta GUI — consulte Acesso remoto.

Para a AWS, o portão aplica-se a cada chamada de assinatura do lado do anfitrião; para as chaves SSH, aos pedidos de assinatura; para tudo o resto, à primeira troca na transmissão da sessão.

Dica: O portão de consentimento é por credencial, não por anfitrião. Se quiser que um token manual sem âmbito permaneça sob controlo, a aprovação é o mecanismo concebido para isso.

A janela de Aprovações de Credenciais

Janela → Aprovações de Credenciais… abre uma vista ao vivo de cada decisão de consentimento tomada durante a execução atual da aplicação: permissões limitadas no tempo (5 minutos / 1 hora / resto da sessão) e recusas lembradas. Cada linha mostra o nome do espaço de trabalho e o tempo restante, e oferece Revogar; Revogar tudo (⌘⌫) limpa tudo de uma vez. A lista atualiza-se automaticamente a cada 2 segundos e encolhe naturalmente à medida que as concessões expiram.

Como as decisões existem apenas em memória, a janela fica vazia depois de as concessões expirarem, depois de as sessões fecharem (concessões com âmbito de sessão) e depois de a aplicação sair. É um painel de controlo para o presente, não um registo de auditoria — para o histórico, use Rastreio.

O detetor de compromisso

As falsificações têm dupla função: além de substituírem segredos, são fios de disparo. Um token falso tem exatamente uma família de destino legítima — o âmbito de anfitrião para o qual foi cunhado. Não há razão honesta para que sk-ant-api03-brm-… apareça num pedido a pastebin.example. Por isso, o proxy analisa cada pedido de saída — cabeçalhos e corpo, através de um autómato de Aho-Corasick, suficientemente barato para correr sobre tudo — em busca de qualquer falsificação a caminho de fora do seu âmbito.

Quando encontra uma, trata o pedido como tentativa de exfiltração de credencial:

1. O pedido é bloqueado com HTTP 451. Nem um único byte é reencaminhado para o destino.
2. A VM é pausada de imediato.
3. Dispara um alerta: "O Bromure detetou uma tentativa de saída para vazar uma credencial de sessão para um anfitrião para o qual não foi cunhada. A VM foi pausada."

O espaço de trabalho é então marcado como comprometido — o navegador de espaços de trabalho mostra Comprometido — o arranque solicitará limpar o disco e a home — e o arranque seguinte requer remediação: "Para continuar, a imagem de disco da VM e a pasta home persistente têm de ser limpas. Os seus tokens, chaves ssh e definições do espaço de trabalho são preservados." Clique em Limpar e Iniciar para prosseguir. Preste atenção ao aviso que o acompanha: as pastas partilhadas NÃO são limpas, pelo que, se o compromisso veio através de um pacote ou ficheiro numa pasta partilhada, pode ainda lá estar — reveja essas pastas antes de retomar o trabalho.

Resposta recomendada a um alerta de compromisso: abra o Inspetor de Rastreios (⇧⌘I) ou execute bromure-cli trace leaks para ver o anfitrião e o pedido ofensivos, decida se uma dependência de projeto ou uma instrução por injeção de prompt foi responsável (consulte Injeção de prompt e Cadeia de fornecimento), depois limpe e reinicie.

Detalhes de âmbito:

• As falsificações sem âmbito estão isentas. Um token manual com um filtro de anfitrião em branco é "qualquer anfitrião" por design e não pode acionar o detetor; os marcadores de posição de subscrição fictícios são igualmente excluídos.
• Os irmãos de primeira parte são tolerados. A correspondência espelha a política de âmbito da troca, com uma relaxação: os anfitriões sob o mesmo domínio registado que o fornecedor da credencial (a infraestrutura do Claude ou do Codex sob anthropic.com, por exemplo) usam uma correspondência de família, pelo que um token legítimo de api.anthropic.com visto em mcp-tools.anthropic.com não é um alarme falso. Todo o resto é estrito.
• Os vazamentos com aparência real também são sinalizados. Independentemente dos fios de disparo falsos, o proxy sinaliza segredos não trocados, com aparência real no tráfego de saída — valores Bearer ou x-api-key com prefixos conhecidos (sk-ant-, ghp_, AKIA, …) ou tokens opacos de 20 caracteres ou mais. Estes aparecem como avisos de vazamento no Inspetor de Rastreios e em bromure-cli trace leaks; normalmente significam que um segredo real foi colado na VM à mão, o que a fronteira de transmissão existe para tornar desnecessário.

Não há nada para ativar — o detetor está sempre ligado.

Onde os segredos residem no anfitrião

Tudo o que é sensível é encriptado em repouso com AES-GCM sob uma chave-mestra de 256 bits por instalação — o cofre de segredos. A chave-mestra reside no Keychain de Proteção de Dados do macOS, com âmbito na identidade de assinatura da aplicação, com acessibilidade kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly e sincronização iCloud desativada. Nunca solicita, nunca sincroniza e nunca sai do Mac. Se o keychain estiver inalcançável (uma compilação não assinada ou não aprovisionada), a aplicação recorre a um ficheiro de chave em modo 0600 armazenado ao lado do texto cifrado — mais fraco, uma vez que a chave e o texto cifrado partilham então um disco, mas mantém a encriptação em repouso a funcionar; uma versão totalmente aprovisionada usa o keychain.

Consequências práticas:

• As cópias de segurança e as cópias são texto cifrado. Uma cópia de segurança do Time Machine ou uma pasta Application Support copiada contém apenas blobs encriptados; sem a entrada de keychain deste Mac não podem ser desencriptados (a menos que a chave de recurso em ficheiro estivesse em uso e fosse copiada juntamente).
• Limpar a entrada do keychain roda a chave. Os blobs encriptados existentes tornam-se ilegíveis e você reintroduz as suas credenciais. Os metadados não sensíveis em profile.json não são afetados.
• Nada é sincronizado para lado nenhum. Nenhuma credencial, arquivo de tokens ou material de chave é carregado, sincronizado ou copiado pela própria aplicação.

Localizações em disco, todas sob ~/Library/Application Support/BromureAC/ salvo indicação em contrário:

As leituras do lado do anfitrião para importações — ~/.aws/config, ~/.aws/sso/cache/*.json, ~/.docker/config.json, ficheiros kubeconfig — acontecem apenas no anfitrião; nenhum desses ficheiros é alguma vez montado numa VM. Os corpos de rastreio encriptados (consulte Rastreio) usam a mesma chave de cofre.

Verificar a fronteira você mesmo

A fronteira de transmissão é concebida para ser verificável, não aceite por fé. A partir de uma shell dentro de qualquer sessão:

1. O ambiente contém falsificações.

echo "$ANTHROPIC_API_KEY"
# sk-ant-api03-brm-…            ← a fake, not your key

env | grep -E 'TOKEN|KEY' 
# every value is brm_/ghp_/glpat_/dop_v1_/lin_api_-shaped placeholder

2. Os ficheiros de configuração contêm falsificações.

cat ~/.git-credentials          # fake tokens per git host
cat ~/.docker/config.json       # fake base64 auth blobs
grep -A2 credential_process ~/.aws/config   # helper, not a secret key

3. E, ainda assim, tudo funciona.

aws sts get-caller-identity     # succeeds — the host resigned the request
gh api user                     # succeeds — the fake was swapped on the wire

4. O TLS dentro da VM termina no proxy.

openssl s_client -connect api.anthropic.com:443 -brief 2>&1 | head
# issuer: the Bromure Agentic Coding Root CA — not a public CA

5. As chaves SSH estão ausentes, mas a assinatura funciona.

ssh-add -L                      # lists public keys served by the vsock agent
ls ~/.ssh/id_*                  # no private key files to find

6. No anfitrião, observe as trocas a acontecer. Ative o rastreio para o espaço de trabalho e depois:

bromure-cli trace summary        # per-request swap reports and leak warnings
bromure-cli trace leaks          # only the suspicious ones

ou abra o Inspetor de Rastreios (⇧⌘I), onde os pedidos trocados são anotados com Nunca enviado para a VM — trocado pelo proxy.

Se alguma vez encontrar uma credencial real dentro de uma VM, ela chegou lá de uma de duas formas: você (ou o agente, sob a sua direção) colou-a à mão, ou chegou através de uma pasta partilhada. A maquinaria de troca nunca escreve reais no convidado — e o detetor de compromisso trata os segredos com aparência real na transmissão como um vazamento precisamente porque não deviam existir lá.

Referência rápida

Portas vsock na fronteira convidado-anfitrião:

Comandos de CLI relacionados (referência completa em Automatização e CLI):