Cofre de chaves

Um agente que trabalha de verdade precisa de credenciais: clonar um repositório privado, conectar um MCP, entrar em um servidor e implantar. Até agora a única forma de entregá-las era colá-las no chat, e isso significa que o token viaja ao provedor de IA e fica no histórico.

O Cofre quebra esse acordo. Os segredos ficam criptografados dentro do projeto e o agente nunca trabalha com o valor, apenas com uma referência: «secreto:azure/pat/lord-denihol». O aplicativo troca essa referência pelo valor real ao iniciar o processo, já fora do alcance do modelo.

A promessa

A chave nunca é texto do chat, nem de um prompt, nem de uma saída de ferramenta.

Na prática são três garantias:

• O agente pede permissão, não o valor. Quando precisa de uma credencial, ele pergunta se você autoriza usar mantis/prod/contextcode; nunca recebe a cadeia.
• Nada do que volta de uma ferramenta o delata. O que um comando imprime, o que um arquivo lido ou um servidor MCP devolve passa por um filtro antes de chegar ao modelo: o valor é substituído pela referência. É isso que cobre os clássicos echo $TOKEN, env, cat .env e git remote -v com o token na URL.
• O valor só é expandido onde pode ser necessário. Comandos, servidores MCP marcados como de confiança e ssh/scp. Nunca ao escrever arquivos.

É uma garantia de arquitetura, não de disciplina: a descriptografia acontece no núcleo do aplicativo (Rust), e nem a interface nem o modelo veem o valor em momento algum.

O que não promete

• Não protege contra um atacante com controle da sua máquina. Um keylogger ou um rootkit leem o que você digitar, com cofre ou sem. Isso é assunto do sistema operacional.
• Não cobre imagens. O filtro trabalha sobre texto; se o agente controla o computador e tira capturas de tela, uma senha visível na tela aparece nelas. Não deixe chaves à vista enquanto o agente olha.
• Valores com menos de 8 caracteres não são cobertos. Mascarar «1234» quebraria qualquer texto. Ao guardar um assim, o aplicativo avisa.

Criar o cofre

O ícone do Cofre fica na barra lateral, ao lado de Skills e MCP. O cofre é por projeto: abra primeiro a pasta com a qual você trabalha.

1. Clique no ícone do Cofre.

   Se o projeto ainda não tem cofre, aparece a tela Criar o Cofre do projeto.

2. Escolha a senha mestra.

   Ela é digitada duas vezes em um campo seguro (pontos negros, fora do chat) e exige pelo menos 8 caracteres: essa chave criptografa todos os segredos do projeto.

3. Guarde-a no seu gerenciador de senhas.

   A senha mestra não pode ser recuperada. O aplicativo diz isso ao criar o cofre, e o único backup é a exportação de emergência.

4. Clique em Criar cofre.

   O cofre fica criado e aberto. O cabeçalho do painel mostra sempre se está Aberto ou Fechado, de qual fonte vem e se a senha mestra está em memória (mestra em memória).

Onde fica cada coisa

O quê	Onde	Vai para o repositório?
A chave derivada da senha mestra	Chaveiro do sistema (Credential Manager, Keychain, Secret Service), uma entrada por repositório	Não
Os valores criptografados	.context/secretos/equipo.enc (AES-256-GCM)	Sim, entra no commit
Os metadados	.context/secretos/equipo.enc.meta (texto claro: id, tipo, descrição, serviço, usuário, datas, força)	Sim

O .meta nunca leva valores. Ele serve para duas coisas: listar o painel sem abrir o cofre e manter os diffs do Git legíveis (dá para ver quem adicionou ou rotacionou um segredo, sem ver nada secreto).

A derivação da senha mestra (Argon2id) acontece uma vez por sessão e a chave derivada fica na memória; é apagada ao fechar o aplicativo. Se o chaveiro do sistema não estiver disponível, a senha mestra vive apenas nessa sessão e o painel avisa com «mestra em memória».

Nota

A entrada do chaveiro é por repositório, então uma mesma máquina pode ter dois cofres (duas empresas, dois clientes) sem que se atropelem.

Guardar um segredo

Com o cofre aberto, a barra do painel oferece Novo segredo, Novo servidor, Importar .env e Exportar.

Em Novo segredo você preenche o id em três partes — sistema (azure-devops, mantis…), ambiente (prod, pat…) e usuário — e o painel mostra o id resultante: azure-devops/pat/lord-denihol. Esse id é o nome com o qual o agente vai pedir autorização, então vale a pena que se entenda.

Os tipos são senha, token, chave SSH, OAuth, variável de ambiente e servidor.

O valor não é digitado em um campo comum: você clica em Escolher valor seguro… e abre o campo seguro, uma caixa própria do aplicativo com o valor oculto, sem autocompletar e sem passar pelo chat. O que você digita vai direto para o núcleo criptografado.

O selo de força

As senhas são avaliadas ao serem guardadas (inclusive a senha de um servidor). Não é um contador de caracteres: mede o quanto a chave é adivinhável — dicionários, nomes próprios, palavras da sua empresa ou do projeto, datas, sequências de teclado, substituições como @ por a — e o resultado aparece na lista:

Selo	O que significa
Muito fraca (vermelho)	Cai em minutos. Você pode guardar, mas o painel não disfarça.
Fraca (laranja)	Aguenta pouco. Troque quando puder.
Forte (verde)	Sem padrões reconhecíveis e com comprimento suficiente.
Sem avaliação	Tokens, chaves SSH e afins: aí não se mede força (quem os gera é o serviço, e o que importa é o formato e a validade).

O contexto conta: se o serviço é uma URL pública ou o usuário tem permissões altas (sa, administrator), o mínimo aceitável sobe e uma senha mediana gera aviso de rotação.

Um exemplo real: Ds910913@ parece decente — maiúscula, dígitos, símbolo — e sai laranja ou vermelha. São umas iniciais, uma data e um símbolo no fim: nove caracteres em um molde que os dicionários conhecem de cor. O aplicativo não proíbe você de guardá-la; ele diz a verdade sobre ela.

Entradas de tipo servidor

Guardar o IP de um lado e a senha do outro não serve a ninguém, então Novo servidor agrupa tudo o que é necessário para entrar:

1. Dados da conexão.

   Host / IP, Porta (22 por padrão) e Usuário. Não são segredos: ficam em texto claro no .meta, porque o agente precisa deles para montar o comando.

2. Autenticação.

   Senha, Chave SSH ou Agente do SO. A senha, a chave privada e a passphrase entram pelo campo seguro; a chave é colada em uma caixa que nunca a mostra por inteiro.

3. Guardar servidor.

4. Testar conexão.

   O aplicativo executa um ssh de verdade e informa apenas Conexão bem-sucedida ou Não foi possível conectar, com o motivo (autenticação recusada, host inalcançável, tempo esgotado). A chave privada passa por um arquivo temporário com permissões restritas que é apagado ao terminar.

Limite honesto com senha por SSH

No Windows não vem sshpass de fábrica. O teste com senha só funciona se você tiver plink ou sshpass instalado; caso contrário, o botão diz isso e recomenda usar chave SSH. O próprio formulário avisa antes de você tentar.

Se essa máquina já estava no painel de conexões remotas, não é preciso digitar nada duas vezes: no seletor de conexões, Guardar no Cofre abre este formulário com host, porta e usuário já preenchidos. Falta só o segredo, que entra pelo campo seguro.

Como o agente usa

O agente pode listar o cofre (ids e metadados, nunca valores) e pedir para usar um segredo. Quando pede, chega a você um cartão de Aprovação necessária com o id e o propósito que ele mesmo escreveu («para clonar o repositório da organização»), e três saídas:

• Permitir — vale para este uso.
• Permitir sempre — cria uma regra do projeto. Não autoriza o cofre inteiro: é lembrada por padrão de sistema (mantis/* a partir de mantis/prod/contextcode), expira em 30 dias e pode ser revogada no painel quando você quiser. O próprio cartão diz o que você vai conceder antes de clicar.
• Negar — o agente fica sem a credencial e precisa seguir sem ela.

Se você autoriza, o valor é descriptografado dentro do aplicativo e injetado no processo, não no texto. O agente escreve a referência no comando e o aplicativo a substitui ao lançá-lo:

git clone https://oauth2:«secreto:azure/pat/lord-denihol»@dev.azure.com/org/proj/_git/repo
ssh «secreto:servidor/prod/mi-server» ./deploy.sh

No segundo caso a referência se transforma em usuário@host e a senha ou a chave é injetada sozinha.

Onde é expandido e onde não

Lugar	Expande?
Argumentos e variáveis de ambiente de um comando	Sim
ssh, scp, sftp, rsync montados pelo aplicativo	Sim
Servidores MCP marcados como de confiança neste projeto	Sim, no ambiente deles
MCP de terceiros não marcados	Não
Escritas de arquivos (Write/Edit)	Nunca, nem em um .env

Essa última linha é deliberada: se o agente pudesse «passar» a chave para um arquivo do repositório, depois poderia lê-la ele mesmo e a promessa cairia.

A cobertura das saídas

Injetar por variável de ambiente não basta, porque o valor volta pela saída. Tudo o que um agente recebe de uma ferramenta — saída e erros do console, conteúdo de arquivos lidos, resultados de MCP — passa pelo filtro antes de chegar ao modelo:

O agente executa	O que o modelo lê
echo $TOKEN	«secreto:azure/pat/lord-denihol»
env	a linha do token, com a referência no lugar
cat .env	cada valor reconhecido, substituído
git remote -v	a URL com a referência onde ia o token

Também são cobertas as formas base64, URL-encoded e com escapes JSON do valor, porque os servidores as devolvem assim (Authorization: Basic …, https://usuario:senha@…, {"token":"…"}).

Dois detalhes importantes:

• O filtro só cobre os segredos em uso nesta sessão (os que você autorizou no turno ou os que uma regra ativa cobre), não o cofre inteiro todo o tempo.
• Valores com menos de 8 caracteres não são cobertos. Ao guardar um assim, o aplicativo avisa.

Enquanto houver segredos autorizados, o compositor mostra um indicador: «N segredos em uso neste turno», que abre o painel com um clique.

Quando o segredo aparece onde não deve

No chat, ao digitar

O compositor analisa o que você digita, antes de enviar. Reconhece tokens do Azure DevOps e do GitHub, chaves da OpenAI, da Anthropic e do Google, chaves da AWS, JWT, chaves privadas PEM e os clássicos password= / token:; e, além dos padrões, mede a entropia para pegar tokens que não se encaixam em nenhum molde. Hashes do Git, UUIDs e marcadores como Password=<password> não são sinalizados.

Se houver correspondência aparece uma faixa, que não bloqueia o envio:

Isto parece uma credencial. Será enviada ao provedor de IA e ficará no histórico.

• Guardar no cofre e enviar referência (a opção padrão): a credencial entra no cofre e o texto que viaja ao provedor leva a referência no lugar. Na sua própria mensagem você verá a versão censurada.
• Enviar mesmo assim: vai como está, por sua conta e risco.

O X apenas descarta o aviso para aquele texto.

Em um arquivo que você abre ou salva

Ao abrir um arquivo, o editor analisa as primeiras linhas e marca as que parecem levar segredos. Se houver, aparece uma faixa:

Este arquivo contém N possível(is) segredo(s).

Com Guardar no cofre eles passam para o cofre criptografado… e o arquivo não é tocado. O aplicativo confirma: «O arquivo NÃO foi modificado: referências «secreto:id» nunca são escritas em arquivos». Não é um esquecimento; é a regra de cima.

O mesmo aviso volta a ser oferecido ao salvar uma aba com segredos, uma vez por arquivo e sessão.

O painel, aba por aba

Segredos

A lista traz Id, Tipo, Força, Expira e Último uso, com filtros por sistema e por ambiente. Ao entrar em um deles:

• Mostrar — pede a senha mestra outra vez (Confirmar identidade) e mostra o valor, que se oculta sozinho após 30 segundos.
• Copiar — copia sem que o valor passe pela interface e avisa: «Copiado. A área de transferência será limpa sozinha em 30 segundos».
• Validar — devolve a força (0-4) com os motivos e, se o segredo passou por um chat em texto claro, diz sem rodeios: é considerado comprometido, rotacione-o o quanto antes.
• Excluir — remove do cofre criptografado, com confirmação; o agente deixa de poder usá-lo.
• Rotacionar — está lá, desativado, com a nota «Rotação guiada: em breve».

Permissões

Cada Permitir sempre concedido, com o seu padrão, o seu âmbito e a sua validade; as expiradas são marcadas como tal e não autorizam mais nada. Revogar deixa tudo como no começo: o agente voltará a pedir autorização a cada uso.

Log de auditoria

Uma tabela local com data, segredo, quem autorizou e propósito de cada uso, além das exclusões. Vive no banco de dados criptografado do aplicativo e nunca guarda valores: serve para saber o que foi usado e para quê, não para recuperar nada.

Importar um .env

Você cola o conteúdo do arquivo, o assistente reconhece os pares CHAVE=valor, lista-os e você desmarca os que não devem entrar. É o caminho rápido para um projeto que já levava suas chaves em texto claro.

Exportação de emergência

Gera um arquivo criptografado com o cofre inteiro, protegido por uma frase-senha própria (não é a senha mestra: pode ser outra). É o único backup se você perder a senha mestra, então guarde-o fora desta máquina. É escrito na pasta de dados do aplicativo, nunca dentro do repositório.

Em equipe

• Uma senha mestra por repositório, compartilhada pelo gerenciador de senhas da equipe. O Context Code não distribui senhas mestras nem as envia a lugar algum.
• Ao clonar um repositório que já traz equipo.enc, o painel detecta e pede a senha mestra; uma vez aberto, ela fica associada ao seu chaveiro e não é pedida a cada sessão.
• Cada pessoa usa o seu próprio usuário nos serviços. O usuário de serviço (ContextCode, ou o nome que você der) é para os agentes. É isso que faz o log de auditoria valer a leitura.
• O .meta em texto claro faz com que as mudanças do cofre sejam revisadas como qualquer outro diff: dá para ver que alguém adicionou mantis/prod/contextcode na terça, sem ver o valor.

Quando alguém sai da equipe

Hoje é manual: rotacionar a senha mestra, criptografar o cofre de novo e trocar uma a uma as credenciais que essa pessoa conhecia. O assistente que guia essa saída chega em breve.

O que vem

Três peças estão desenhadas, mas ainda não estão no aplicativo:

• Rotação guiada: abrir o guia do serviço (Azure DevOps, GitHub, Google, Mantis), digitar a chave nova no campo seguro e substituir a velha em um passo. O botão Rotacionar já está no detalhe, desativado.
• Importador do cofre manual: trazer de uma vez a planilha de chaves que a equipe mantinha à mão.
• Assistente de saída de membro: rotacionar a senha mestra e percorrer em série os segredos que precisam ser trocados.