Credenciais

O painel Credenciais é onde dá a um espaço de trabalho os segredos de que o seu agente precisa — tokens git, chaves SSH, credenciais de nuvem, palavras-passe de bases de dados — sem que nenhum desses segredos alguma vez entre na VM. Cada valor que escreve aqui é armazenado encriptado no seu Mac. Dentro da sandbox, o agente vê apenas um falso que preserva a estrutura (por exemplo brm_…); quando um pedido efetivamente sai do seu Mac, o proxy do lado do anfitrião troca o falso de volta pelo valor real, delimitado ao anfitrião de destino.

Esta página é a referência campo a campo do painel. O mecanismo por trás dela — a fronteira de transmissão, os falsos deterministas, a delimitação por anfitrião, o resigner AWS fail-closed e o detetor de comprometimento — está documentado na íntegra em Credenciais e a fronteira de transmissão. Leia esse capítulo para o modelo de segurança; leia esta página para preencher os campos. Os controlos de aprovação e de política de escrita por credencial residem agora no painel Salvaguardas, não aqui.

Nota: A captura de ecrã acima é anterior à remodelação e pode mostrar a pilha antiga de secções recolhíveis. O painel atual mostra apenas as credenciais que configurou, agrupadas sob cabeçalhos de categoria, mais os dois botões descritos abaixo.

O painel abre com Identidade Git fixada no topo, seguida de uma lista das credenciais que já configurou — nada mais. Cada credencial configurada é uma linha; as famílias vazias que antes ficavam recolhidas no painel desapareceram. Dois botões no fundo, Adicionar credencial e Importar ficheiro env…, são a forma de adicionar mais. Nada é aplicado até clicar em Guardar.

Identidade Git

Os dois campos no topo definem a identidade de autor git escrita em ~/.gitconfig dentro da VM:

• user.name — marcador de posição O Seu Nome.
• user.email — marcador de posição [email protected].

A legenda diz: Escrito em ~/.gitconfig na VM. Deixe ambos em branco para manter os valores predefinidos do git. Estes não são segredos e não são trocados — são configuração simples para que os commits que o agente faz sejam atribuídos corretamente. Deixar um campo em branco mantém intacta essa predefinição do git.

A lista de credenciais configuradas

Abaixo da Identidade Git, o painel lista apenas as credenciais que efetivamente produzem uma troca no arranque da sessão, agrupadas sob cabeçalhos de categoria:

Cada linha mostra um ícone, um título e o anfitrião ou anfitriões aos quais a credencial está delimitada (para um token git, user@host; para uma base de dados ou registo, o seu anfitrião; para a AWS, amazonaws.com; e assim por diante). Um menu ⋯ à direita — também acessível clicando na linha — oferece Editar… e Remover:

• Editar… reabre o editor dessa credencial para que possa alterar ou revelar os seus campos.
• Remover elimina a credencial do espaço de trabalho. (Não há outra forma de desfazer além de a voltar a adicionar; nada é removido do disco até Guardar.)

As linhas sob AGENTES são a única exceção: o seu menu diz Editar em Agentes… e não tem Remover, porque as chaves dos agentes pertencem ao painel Agentes. Ao escolhê-lo, o editor muda para esse painel.

Quando um espaço de trabalho não tem credenciais nenhumas, a lista é substituída por um estado vazio — Ainda sem credenciais — a lembrar-lhe que os valores reais ficam no seu Mac e a VM apenas alguma vez detém um falso.

Adicionar uma credencial

Clique em Adicionar credencial para abrir a folha de seleção. Ela lista todos os tipos de credencial que a aplicação consegue adicionar; cada entrada abre o editor desse tipo:

As chaves de API dos agentes estão deliberadamente fora deste seletor; uma nota no rodapé lembra-lhe que as chaves da Anthropic, OpenAI e xAI são configuradas no painel Agentes. Cada editor é uma folha com um botão Concluído; os campos de cada tipo são descritos nas secções abaixo.

Importar um ficheiro env

Clique em Importar ficheiro env… para extrair credenciais de um ficheiro .env existente — ou de um ~/.bashrc. O analisador lê atribuições simples KEY=VALUE e export KEY=VALUE, remove as aspas envolventes e os # comentários finais, e usa a última atribuição quando um nome se repete. Nunca executa uma shell: qualquer valor que precisaria de interpolação (uma referência $VAR ou uma substituição de comando $(…)) é ignorado em vez de importado erradamente, pelo que apontá-lo para um .bashrc real é seguro.

As variáveis do ficheiro são então mostradas numa folha de revisão intitulada Importar de <filename>, dividida em dois grupos. Todos os valores estão mascarados nesta folha.

As variáveis Reconhecidas são mapeadas automaticamente para o seu tipo de credencial:

Cada linha reconhecida tem uma caixa de seleção. Um token git pede adicionalmente um Nome de utilizador git (marcador de posição voce) para que a credencial fique completa. Se uma variável mapear para algo que o espaço de trabalho já tem configurado, a sua linha é sinalizada com Já configurada — marque para substituir. e deixada por marcar, para que uma reimportação nunca sobrescreva silenciosamente um segredo existente.

As variáveis Não reconhecidas podem ser importadas como tokens genéricos de Outra chave de API. Cada linha traz um campo Anfitrião(ões) — uma lista separada por vírgulas dos nomes de anfitrião nos quais o falso deve ser trocado (múltiplos anfitriões permitidos; em branco significa qualquer anfitrião). O nome da variável de ambiente é reutilizado tanto como nome do token como variável sob a qual o falso é exportado.

O botão diz Importar N credenciais e reflete apenas as linhas que deixou marcadas. A importação funde as seleções no painel; ainda tem de clicar em Guardar para as persistir.

Chaves SSH

O editor de Chave SSH gere as chaves com que o espaço de trabalho se pode autenticar por SSH. Os bytes da chave privada nunca entram na VM: a assinatura é servida através de uma ponte ssh-agent no processo, sobre vsock, para que o convidado possa pedir assinaturas mas nunca consiga ler a chave.

Há duas fontes de chaves:

• O par de chaves ed25519 próprio do espaço de trabalho. Os novos espaços de trabalho trazem um interruptor pré-marcado Gerar um par de chaves ed25519 (a menos que o modelo das suas preferências já forneça uma chave). Assim que existe uma chave, o editor mostra a sua chave pública com botões Copiar e Abrir página de chaves do GitHub (para colar em github.com/settings/keys) e um interruptor Regenerar.
• Chaves SSH importadas. Sob Chaves SSH importadas, clique em Importar… para abrir um seletor de ficheiros; uma folha pede então uma Etiqueta e, se a chave estiver encriptada, uma Frase-passe. As frases-passe são armazenadas no Keychain do macOS, e as chaves importadas são carregadas para o ssh-agent por espaço de trabalho a cada arranque de sessão. São suportadas chaves RSA, ed25519 e ecdsa.

Tokens git (GitHub, GitLab, Bitbucket)

O editor de Token git contém tokens de acesso pessoal para git sobre HTTPS, divididos em grupos GitHub, GitLab e Bitbucket. Como diz a sua legenda: os tokens de acesso pessoal são armazenados encriptados no anfitrião, e o proxy troca-os nos pedidos de saída para que a VM apenas alguma vez detenha o falso. O gh e o glab captam GH_TOKEN / GITLAB_TOKEN automaticamente.

Clique em Adicionar token num grupo para adicionar uma linha. Cada linha recebe um Anfitrião, um Nome de utilizador e um Token de acesso pessoal (com um botão de olho para revelar e uma ligação para a página de tokens desse forge). O falso é escrito em ~/.git-credentials e nas configurações das CLIs gh / glab dentro da VM. O campo de anfitrião permite-lhe apontar uma entrada para github.com, gitlab.com, ou uma instância GitLab/Gitea/Bitbucket alojada por si.

Linear

O editor de Chave de API Linear recebe uma única chave de API pessoal (marcador de posição com o formato lin_api_…, com uma ligação Abrir definições de API do Linear). É injetada na VM como LINEAR_API_KEY, que o SDK do Linear, os servidores MCP e as ferramentas de CLI captam automaticamente, e é trocada de falso para real apenas em pedidos para linear.app (incluindo api.linear.app e mcp.linear.app). Uma chave Linear no espaço de trabalho é também o pré-requisito para os acionadores de automatização agendada por issue do Linear.

Kubernetes

O editor de Kubernetes contém uma linha por contexto de cluster. O Bromure Agentic Coding constrói um ~/.kube/config sintético dentro da VM para que o kubectl fale com o proxy, nunca diretamente com o servidor de API; a identidade real fica no anfitrião.

Cada contexto tem um nome, um URL do servidor, um certificado CA opcional (PEM, usado para que o proxy possa verificar o servidor de API a montante), um Namespace, e um método de autenticação escolhido com um controlo segmentado:

• Bearer token — um token estático, trocado pelo valor real na fronteira de transmissão.
• Certificado de cliente — o certificado e a chave reais são registados no anfitrião para o TLS mútuo a montante; a VM recebe um certificado autoassinado descartável.
• Plugin exec — um Comando, Argumentos e um seletor de Atualização (1–60 minutos). O plugin corre no anfitrião a cada intervalo de atualização e o token fresco é alimentado no mapa de troca; o kubectl da VM nunca executa o plugin.

Um crachá em cada linha mostra de que tipo (token / cert / exec) se trata. Use Importar ficheiro… para analisar um kubeconfig existente numa linha por contexto, ou Adicionar contexto para adicionar um manualmente. A política de escrita por contexto correspondente é definida no painel Salvaguardas.

DigitalOcean

O editor de Token DigitalOcean recebe um único token de acesso pessoal (marcador de posição com o formato dop_v1_…, com uma ligação para a página de tokens do DigitalOcean). É injetado como DIGITALOCEAN_ACCESS_TOKEN e escrito em ~/.config/doctl/config.yaml, tornando doctl auth init desnecessário. O token é trocado de falso para real em pedidos para digitalocean.com, e uma segunda entrada de troca cobre a forma Basic-auth em base64 usada quando docker login ou doctl registry login se autentica contra registry.digitalocean.com.

AWS

O editor de Credenciais AWS configura credenciais para a CLI aws, os SDKs, o terraform e o modo de autenticação Bedrock do Claude Code. O segredo real nunca chega à VM — o anfitrião reassina os pedidos SigV4 com o material real, e um pedido que contorne o proxy recebe uma InvalidSignatureException da AWS. Um controlo segmentado de Método de autenticação seleciona entre:

• Chaves estáticas — ID da chave de acesso, Chave de acesso secreta, um Token de sessão opcional (apenas STS) e uma Região predefinida, mais uma ligação Abrir página de credenciais IAM.
• SSO / Identity Center — um seletor de pasta Conceder acesso a ~/.aws, e depois um seletor de Perfil SSO preenchido a partir dos perfis descobertos no seu ~/.aws/config (com um botão de atualização). As credenciais de função temporárias são resolvidas no anfitrião, acionando aws sso login no seu navegador quando o token em cache tiver expirado.

O tratamento completo da AWS — o auxiliar credential_process, o resigner e os seus limites — está em Credenciais e a fronteira de transmissão.

Registos de contentores

O editor de Registo de contentores contém a autenticação HTTP Basic por registo para docker pull / docker push. Como explica a legenda, a palavra-passe real nunca é escrita na VM — o bromure coloca um falso base64("<user>:<derived>") em ~/.docker/config.json, e o proxy substitui o valor real na fronteira de transmissão quando o pedido atinge o anfitrião de registo correspondente.

O menu Adicionar oferece predefinições — Docker Hub (docker.io), GitHub Container Registry (ghcr.io), GitLab Container Registry (registry.gitlab.com), Quay (quay.io) e Outro anfitrião… — mais Importar config.json…, que extrai entradas de um ~/.docker/config.json existente. A importação ignora as entradas credsStore / credHelpers (as suas palavras-passe residem no keychain do SO em vez do ficheiro) e reporta quantas foram ignoradas. Cada linha de registo recebe um Anfitrião, um Nome de utilizador e uma Palavra-passe ou token. A política de escrita de push/pull/delete correspondente é definida no painel Salvaguardas.

Bases de dados (MongoDB, ClickHouse, Elasticsearch)

O editor de Base de dados contém uma linha por endpoint HTTPS, agrupado por motor. O falso é exportado sob os nomes de variável de ambiente que listar e é trocado pelo valor real onde quer que apareça — cabeçalho, parâmetro de consulta ou corpo do pedido.

Cada linha de endpoint tem:

• Nome — nome de exibição opcional.
• Anfitrião — o nome de anfitrião puro; delimita tanto a troca como a salvaguarda do endpoint.
• Autenticação — um controlo segmentado: Nome de utilizador + palavra-passe, Chave de API ou Bearer token. O MongoDB usa por predefinição Chave de API; o ClickHouse e o Elasticsearch usam por predefinição Nome de utilizador + palavra-passe.
• Nome de utilizador — apenas para autenticação Basic.
• Segredo — com um botão de olho para revelar.
• Variável(eis) de ambiente — uma lista separada por vírgulas dos nomes sob os quais o falso deve ser exportado.

Os novos endpoints de base de dados assumem por predefinição a política de escrita por endpoint Perguntar antes de escrever, definida no painel Salvaguardas — a classificação específica de cada motor (quais ações Mongo, quais palavras-chave SQL, quais caminhos Elasticsearch contam como escritas) reside lá.

Outras chaves de API

O editor de Outra chave de API é a saída de emergência para qualquer serviço que o Bromure Agentic Coding não trate automaticamente. Cada entrada é uma regra de troca manual:

• Nome — uma etiqueta para a entrada.
• Segredo real — mascarado (marcador de posição com o formato sk_live_…).
• Variável de ambiente — o nome sob o qual o falso é exportado dentro da VM. Deixar isto em branco não exporta nada; teria então de copiar o falso a partir do banner de boas-vindas da sessão.
• Anfitrião de API (opcional) — o anfitrião ou anfitriões aos quais a troca está delimitada (exato-ou-subdomínio, separados por vírgulas). Em branco significa "injetar em qualquer anfitrião".

A VM vê um falso brm_… cunhado e o proxy troca-o de volta na fronteira de transmissão.

Aviso: Um Anfitrião de API em branco nunca é deliberadamente controlado pelo detetor de comprometimento — é uma escolha explícita de "injetar em qualquer anfitrião". Para manter um segredo não delimitado sob controlo, ou lhe dá um anfitrião ou ativa Perguntar antes de usar para ele no painel Salvaguardas.

As políticas de aprovação e de escrita residem em Salvaguardas

Já não há caixas de seleção Exigir aprovação para usar no painel Credenciais. O portão de consentimento por credencial — agora exposto como Perguntar antes de usar — e a política de escrita de cada serviço residem ambos no painel Salvaguardas, que lista uma linha por credencial configurada. Configure o segredo aqui; decida como o agente está autorizado a usá-lo lá.

Como o painel é armazenado

Tudo neste painel é um segredo, pelo que ao guardar é separado do profile.json em texto simples para o secrets.enc encriptado do espaço de trabalho (AES-GCM, com chave derivada do Keychain do macOS, permissões 600). Os fornecedores tratados automaticamente — Anthropic, OpenAI, GitHub, GitLab, DigitalOcean, Kubernetes — não precisam de qualquer entrada manual além do que configura aqui; a chave de API do próprio agente principal é definida no painel Agentes.

Referência de definições

As políticas de Perguntar antes de usar e de escrita por credencial são definidas no painel Salvaguardas.

Capítulos relacionados

• Credenciais e a fronteira de transmissão — o modelo de segurança completo por trás deste painel.
• Agentes — a chave de API do agente principal e os modos de autenticação por subscrição/Bedrock.
• Salvaguardas — aprovação por credencial e políticas de escrita por serviço para estes mesmos segredos.
• Referência de Definições — todos os painéis num relance.