Acesso Seguro do Agente Bitwarden: Compartilhando Credenciais do Vault com Agentes de IA de Codificação

Ashley Innocent

Ashley Innocent

15 maio 2026

Acesso Seguro do Agente Bitwarden: Compartilhando Credenciais do Vault com Agentes de IA de Codificação

Apidog para empresas

Implantação local

SSO & RBAC

Conforme SOC 2

Explorar Apidog Enterprise

Se você usa Claude Code, Codex ou Cursor com qualquer coisa que toque uma API real, você tem um problema: o agente precisa de credenciais e seu gerenciador de senhas quer mantê-las bloqueadas. As soluções alternativas usuais são ruins. Cole uma chave de API em um chat e ela ficará para sempre na janela de contexto de um modelo. Coloque segredos em um arquivo .env e a ferramenta bash do agente irá feliz cat eles e enviá-los para algum lugar. A maioria das equipes simplesmente baixa seus padrões.

O novo projeto de código aberto do Bitwarden, Agent Access, é a primeira tentativa séria de corrigir isso. É um protocolo de compartilhamento de credenciais, um CLI (aac), e um SDK em Rust + Python que constrói um túnel criptografado entre seu gerenciador de senhas e um processo remoto: um agente, um runner de CI, um script. O agente obtém os segredos de que precisa, com escopo para um único domínio ou item de cofre, sem nunca ver seu cofre.

Este guia aborda o que o Agent Access oferece, como instalá-lo, como usar aac connect e aac run, como ele se encaixa nos fluxos de trabalho de Claude Code, Codex e Cursor, e onde ele se posiciona em relação aos padrões de higiene de credenciais abordados em Como Proteger Credenciais de API de Agentes de IA.

O que é o Agent Access (um parágrafo)

Agent Access é um protocolo aberto e uma implementação de referência construída pelo Bitwarden, mas projetada para que qualquer gerenciador de senhas possa adotá-la. O CLI (aac) cria um túnel criptografado de ponta a ponta usando o Noise protocol. Um "provedor" escuta por solicitações de conexão; um "consumidor" (seu agente, seu script, seu trabalho de CI) se conecta ao provedor e solicita credenciais por domínio ou por ID de item do cofre. O provedor decide o que enviar de volta. O consumidor nunca vê o cofre completo. O provedor nunca vê o que o consumidor faz com as credenciais. Trilhas de auditoria ficam em ambos os lados.

Atualmente está em pré-visualização inicial. O README do projeto adverte que "APIs e protocolos estão sujeitos a alterações" e "não recomendamos inserir credenciais sensíveis diretamente em LLMs ou agentes de IA." O padrão que o Bitwarden recomenda é o foco de metade deste guia: injeção de ambiente via aac run, que insere segredos em um processo sem expô-los à janela de contexto do agente.

Por que isso importa em 2026

Agentes de codificação de IA superaram as sandboxes. Claude Code, Codex, Cursor e os demais agora leem seu repositório, executam seus testes, acessam suas APIs, implantam seu código. Cada um desses passos deseja credenciais. O incidente de chaves de API expostas do Postman mostrou o quão mal a higiene de credenciais se escala quando apenas humanos são descuidados; humanos mais agentes é pior.

A resposta certa não é "confiar mais no agente"; é "dar menos ao agente". O Agent Access faz isso no nível do protocolo: credenciais com escopo, criptografadas em trânsito, buscadas em tempo de execução, desaparecem quando o processo termina. Comparado à prática atual (Ferramentas de Gerenciamento de Chaves de API cobre o restante do cenário) o Agent Access é a primeira coisa construída especificamente para o caso de agentes.

Instalar

Escolha sua plataforma.

macOS (Apple Silicon)

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-aarch64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

macOS (Intel)

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Linux (x86_64)

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-linux-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Windows (x86_64)

Baixe aac-windows-x86_64.zip da página da última versão e extraia para qualquer diretório em seu PATH.

Verifique a instalação com aac --help. Se o CLI do Bitwarden (bw) também estiver em seu PATH, aac o usará como o provedor de credenciais padrão; caso contrário, passe --provider example para usar o provedor de demonstração integrado enquanto você experimenta.

Início rápido: parear e buscar uma credencial

Dois comandos. Execute aac listen na máquina que contém seu cofre, tipicamente seu laptop:

aac listen

O listener imprime um token de emparelhamento. No lado do consumidor (a máquina remota, o runner de CI, ou apenas outro shell no mesmo host enquanto você testa), emparelhe e busque em uma única chamada:

aac connect --token <token-de-emparelhamento> --domain github.com --output json

Você receberá algo como:

{
  "credential": {
    "notes": null,
    "password": "alligator5",
    "totp": null,
    "uri": "https://github.com",
    "username": "example"
  },
  "domain": "github.com",
  "success": true
}

Esse formato JSON é o contrato estável do protocolo. Seu script pode analisá-lo como preferir. Para buscar por ID de item do cofre em vez de domínio:

aac connect --id <id-do-item-do-cofre> --output json

--id e --domain são mutuamente exclusivos; escolha um. Códigos TOTP fluem através da mesma carga útil quando o item do cofre tem um configurado.

A funcionalidade matadora: aac run para injeção de ambiente

aac connect é bom quando seu script sabe como lidar com JSON. O padrão maior é aac run: ele busca uma credencial e executa seu processo filho com os segredos injetados como variáveis de ambiente. Nunca para a saída padrão, nunca para o disco, nunca visível para o que iniciou aac.

Injetar campos específicos:

aac run --domain example.com --env DB_PASSWORD=password --env DB_USER=username -- psql

Injetar todos os campos com um prefixo AAC_:

aac run --domain example.com --env-all -- deploy.sh

Combinar padrões com substituições:

aac run --domain example.com --env-all --env CUSTOM_PW=password -- deploy.sh

Os campos disponíveis são username, password, totp, uri, notes, domain e credential_id.

Este é o padrão que o Bitwarden recomenda ativamente para uso com agentes de IA: você aponta o Claude Code ou Codex para um script que chama aac run, e o segredo nunca aparece na transcrição do agente. O modelo vê o comando aac run --domain api.stripe.com --env-all -- ./deploy.sh, não a senha. Se o agente mais tarde perguntar "qual é o valor de $STRIPE_API_KEY?", a resposta é "não consigo ver", porque estava restrito ao subprocesso deploy.sh.

Este é o mesmo princípio de isolamento abordado em Como Proteger Credenciais de API de Agentes de IA, concretizado com uma ferramenta real.

SDKs para Python e Rust

Se uma invocação de CLI não for suficiente (por exemplo, se você estiver incorporando o Agent Access em sua própria aplicação), há bindings de primeira classe.

Python

from agent_access import RemoteClient

client = RemoteClient("python-remote")
client.connect(token="ABC-DEF-GHI")
cred = client.request_credential("example.com")
print(cred.username, cred.password)
client.close()

O módulo Python é suportado por PyO3, então o trabalho pesado permanece em Rust e você obtém a mesma implementação do protocolo Noise por baixo dos panos.

Rust

O SDK do Rust expõe a mesma interface RemoteClient como uma biblioteca de primeira classe. Implementações de referência estão em examples/rust-remote/ no repositório. Use-o quando estiver escrevendo o consumidor diretamente em Rust. Comum em ferramentas CLI, runners de build e qualquer serviço que deseje distribuição de binários compilados.

Para equipes de aplicativos que já entregam ferramentas de API, o padrão SDK se encaixa perfeitamente ao lado de integrações com HashiCorp Vault ou Azure Key Vault. O Agent Access não é um substituto para esses no nível empresarial, mas é uma solução melhor para os casos de uso de laptop de desenvolvedor e runner de CI.

Integrando com agentes de codificação de IA

Claude Code

Conecte aac run ao script que o Claude Code chama. Exemplo para uma tarefa de implantação:

# deploy.sh
#!/usr/bin/env bash
aac run --domain prod.example.com --env-all -- ./run-deploy.sh

Adicione este script ao seu projeto, aponte seu fluxo de trabalho do Claude Code para ele, e o agente chamará ./deploy.sh sem credenciais no prompt. A integração de Claude Code GitHub Actions estende o mesmo padrão para o CI: instale o aac no runner, emparelhe-o com um provedor de cofre Bitwarden rodando em um plano de controle, e suas GitHub Actions herdarão as credenciais com escopo no momento da execução do trabalho.

OpenAI Codex

O mesmo padrão funciona para a CLI do Codex. A camada de chamada de ferramenta do Codex exibe comandos para o modelo; o script que o modelo chama acessa aac run e os segredos permanecem fora do contexto do modelo. A recente postagem Codex do seu telefone aborda a superfície mais ampla do Codex; este é o ângulo de credenciais que se combina com ele.

Cursor

Para os comandos de terminal e fluxos de trabalho do Composer do Cursor, os mesmos scripts encapsulados em aac run funcionam sem modificação. A força do Cursor é a edição local, então o listener geralmente é executado na mesma máquina.

OpenClaw (habilidade do ecossistema Anthropic)

O Agent Access vem com uma habilidade OpenClaw oficial pronta para uso (um SKILL.md está no repositório). Para equipes que usam habilidades do tipo OpenClaw, esta é a integração mais aprimorada hoje: a habilidade conhece o formato do protocolo, busca as credenciais e as entrega a qualquer ferramenta downstream que a habilidade exponha. O guia de chaves de API do OpenClaw cobre a história mais ampla de gerenciamento de credenciais para esse ecossistema.

Modelo de segurança em palavras simples

Três afirmações que valem a pena verificar:

  1. Criptografia de ponta a ponta via Noise. O tráfego entre consumidor e provedor é criptografado com o Noise protocol framework, a mesma família de handshake que WireGuard e Signal usam. A camada de transporte não é o elo mais fraco.
  2. Credenciais com escopo. O consumidor só obtém o que pediu (um domínio ou um ID de item do cofre). Ele não pode enumerar o cofre.
  3. Nenhum segredo no disco do consumidor por padrão. aac run passa segredos através de variáveis de ambiente para um processo filho; nada é gravado em um arquivo, nada aparece na saída padrão, nada vai para o histórico do shell.

O que o Agent Access não protege contra:

Um padrão comum: o agente chama a API, o Apidog a testa

Aqui está o ciclo que a maioria das equipes adotará:

  1. O agente escreve o código. Claude Code, Codex ou Cursor abre um PR tocando em um endpoint.
  2. O CI executa os testes. Seu test runner chama aac run para buscar a chave da API, executa a suíte de testes contra uma implantação de staging.
  3. O Apidog verifica o contrato. O Apidog executa o teste de contrato OpenAPI como uma etapa separada do CI, também via aac run, também sem o agente ver a chave.

O resultado: o agente envia o código, o contrato se mantém, o segredo nunca sai do cofre. O playbook mais amplo sobre como testar alterações impulsionadas por IA está em Como testar agentes de IA que chamam suas APIs.

Limitações e avisos

Perguntas comuns

O Agent Access é gratuito?

Sim. O CLI, os SDKs e o protocolo são de código aberto sob a organização GitHub do Bitwarden. Você ainda paga pelo Bitwarden se o estiver usando como seu cofre.

Funciona com outros gerenciadores de senhas além do Bitwarden?

O protocolo é projetado para ser neutro em relação ao fornecedor. A implementação de referência vem com suporte ao Bitwarden e um provedor de exemplo; espera-se que outros fornecedores lancem seus próprios provedores com o tempo.

Posso usá-lo sem um gerenciador de senhas?

Para testes, sim; passe --provider example para usar o provedor de demonstração integrado. Para produção, você precisa de um provedor real (Bitwarden hoje, outros no roteiro).

O processo do consumidor precisa de acesso à rede?

O consumidor precisa de acesso à rede para alcançar o listener do provedor. Configurações apenas locais funcionam se o listener e o consumidor estiverem no mesmo host.

Qual a diferença para um arquivo .env?

Um arquivo .env fica no disco, é verificado em repositórios acidentalmente e é legível por qualquer coisa que o agente possa executar. aac run mantém o segredo apenas na memória do processo, com escopo para o subprocesso, e ele desaparece quando o processo é encerrado.

Ele substitui o HashiCorp Vault ou o AWS Secrets Manager?

Não. Cofres empresariais ainda são a ferramenta certa para segredos de serviço para serviço em escala. O Agent Access preenche a lacuna do laptop de desenvolvedor e do runner de CI, onde um cofre empresarial completo é um exagero.

A Anthropic, OpenAI ou outros fornecedores de agentes integrarão isso diretamente?

Não anunciado. O modelo de integração atual é "envolva seus scripts em aac run." O suporte direto de primeira classe dos fornecedores de agentes é o próximo passo natural, mas ainda não foi lançado.

Onde posso reportar bugs ou contribuir?

O repositório do GitHub. Problemas, PRs e discussões de protocolo acontecem lá.

Experimente agora

Instale aac, execute aac listen em seu laptop, execute aac connect --provider example --domain test.com --output json de outro terminal. Confirme que o JSON é retornado. Este é o menor loop de ponta a ponta. A partir daí, substitua o provedor de exemplo por bw, encapsule um script real em aac run, e pare de colar chaves de API em seus agentes de IA.

Combine o Agent Access com o Apidog para a parte de teste de API do fluxo de trabalho, e você terá uma separação limpa: o cofre guarda o segredo, o Apidog testa o contrato, o agente envia o código, e nenhuma credencial sai de sua máquina em texto puro.

button

Pratique o design de API no Apidog

Descubra uma forma mais fácil de construir e usar APIs