Keyholder MCP

Seu agente de IA usa a credencial. E nunca a vê.

O Keyholder MCP é um servidor MCP sobre o OpenBao. O agente escreve uma referência; o Keyholder coloca o valor real no comando só na hora de executar e devolve a saída com o valor mascarado. O acesso acaba sozinho.

Começar Baixar

O agente pede ao keyholder_run

curl -sS \
  -H "Authorization: Bearer {{vault://my-project/dev/API_TOKEN}}" \
  {{vault://my-project/dev/API_URL}}

A API recebe

Authorization: Bearer
tok-fake-not-a-real-secret

O agente lê de volta

api says: hello, caller with
header Authorization: Bearer
[hidden:vault://my-project/dev/API_TOKEN]

Uma execução gravada com um token falso, conferida a cada build do CI: veja o início rápido.

Por que não dar a chave ao agente

Agentes precisam de chaves de API, credenciais de nuvem e tokens para fazer trabalho real. Colada no chat, num .env ou num comando escrito pelo modelo, a credencial vai parar na conversa, em logs e em lugares que você vai esquecer. Os outros servidores MCP de OpenBao e Vault que encontramos têm uma tool que lê o segredo para o modelo. O Keyholder não tem nenhuma: o modelo só segura nomes.

Uma execução, do começo ao fim

1. Você guarda o segredo

   No OpenBao, um caminho por projeto. Pela interface web do OpenBao ou pela CLI bao, fora do chat.

2. Você emite uma sessão

   Um token embrulhado, de uso único, com TTL, entregue ao keyholder-mcp pelo ambiente dele.

3. O agente roda um comando

   Ele envia {{vault://…}}. O Keyholder resolve na execução, roda um comando permitido sem shell e mascara a saída.

4. O acesso acaba

   No fim do TTL toda chamada falha com uma mensagem clara. Você renova fora do chat; o agente não consegue.

Comparação

	Keyholder MCP	mcp-vault	openbao-mcp	vault-mcp-server
Cofre	OpenBao	OpenBao, embutido	OpenBao	HashiCorp Vault
O modelo recebe valores	Nunca	Sim, documentado	Tem tool de leitura	Sim, documentado
Valor injetado na execução	Sim	Não documentado	Não documentado	Não documentado
Saída mascarada	Sim	Não documentado	Não documentado	Não documentado
Credencial de nuvem por execução	AWS, GCP; revogada depois	Não documentado	Não documentado	Não documentado
Acesso temporário	Token embrulhado, TTL	Wrapping, CA de SSH, PKI	Não documentado	Não documentado
O que o agente faz	Roda comandos permitidos	39 tools: segredos, SSH, PKI, políticas	Operações do cofre	Mounts, KV, PKI

Pelo README de cada projeto em 2026-10-14. Eles administram o cofre pelo agente; o Keyholder só deixa o agente usá-lo. Detalhes e fontes: Comparação.

O que protege, e o que não

Protege

• Os valores ficam fora do chat, dos resultados das tools, dos erros e dos logs.
• Um token de sessão vazado morre com o TTL; um token embrulhado funciona uma vez.
• Só rodam os comandos que você nomeia, e nunca por um shell.
• Referências fora do escopo do projeto são recusadas.

Não protege

• O comando executado recebe o valor: ele precisa dele.
• Um valor codificado escapa: um interpretador liberado contorna o mascaramento, como mostra o tutorial de mascaramento.
• Um agente hostil rodando com o seu usuário do sistema.

A lista completa está no modelo de segurança.

Comece em cinco minutos

bao server -dev -dev-root-token-id=root-dev        # em memória, para experimentar
export BAO_ADDR=http://127.0.0.1:8200 BAO_TOKEN=root-dev
bao kv put -mount=secret my-project/dev API_TOKEN=seu-token-de-api
bao policy write my-project-read deploy/policy-project-read.hcl
bao token create -policy=my-project-read -ttl=8h -explicit-max-ttl=8h -wrap-ttl=5m -field=wrapping_token

Depois cadastre o keyholder-mcp no Claude Code, Cursor ou Codex com esse token embrulhado. Cada passo explicado: Começando. Cada comportamento, com saída real: Tutoriais.

Versão 0.4.0, licença MIT. Código, issues e releases no GitHub. CLIs de nuvem recebem uma credencial criada para cada execução: credenciais de nuvem. Para segredos reais, rode um cofre persistente. Próximos passos no roteiro: pedidos de acesso pelo agente, SSH.