wundervault

Servidor MCP para gerenciamento de segredos de conhecimento zero do Wundervault. Expõe segredos do cofre para agentes de IA através do Model Context Protocol — os segredos são descriptografados no lado do servidor e nunca retornados ao agente em texto simples.

GitHub
2
Experimente este MCPPatrocinado

Documentação

@wundervault/mcp-server

npm version MCP Registry License: AGPL-3.0 Follow @wundervault1

Um cofre de segredos com conhecimento zero para agentes de IA. Toda chave de API que você cola em um chat de agente ou em um arquivo .env acaba em janelas de contexto, transcrições e logs do provedor. A resposta do Wundervault: o agente nunca recebe o segredo. Ele pede trabalho — "execute este deploy com a chave injetada" — e um daemon local descriptografa o segredo, injeta-o no ambiente do subprocesso, zera o buffer e limpa a saída antes que o agente veja qualquer coisa.

Este repositório é o servidor MCP que expõe esse fluxo de trabalho a qualquer cliente Model Context Protocol — Claude Code, Cursor, Cline e outros.

Não confie na afirmação — teste você mesmo: a propriedade de conhecimento zero é verificável de forma independente no seu próprio limite de rede em cerca de 5 minutos (DevTools do navegador ou teste canário com mitmproxy). Guia + nossa própria transcrição de teste: wundervault.com/verify.

Como funciona

┌──────────────┐  MCP (stdio)  ┌───────────────────┐  ciphertext only  ┌───────────────────┐
│   AI agent   │──────────────▶│  wundervault-mcp  │◀─────────────────▶│  wundervault.com  │
│ (Claude, …)  │◀──────────────│  + local daemon   │                   │ stores encrypted  │
└──────────────┘ "burned" ack  │  decrypts HERE    │                   │ blobs, no keys    │
                               └─────────┬─────────┘                   └───────────────────┘
                                         │  secret → subprocess env
                                         │  (buffer zeroed after spawn)
                                         ▼
                               ┌───────────────────┐
                               │   your command    │ stdout/stderr scrubbed
                               │ (deploy, API, …)  │ before the agent sees it
                               └───────────────────┘

Os segredos são criptografados no lado do cliente (AES-256-GCM via Web Crypto) antes do upload. O serviço hospedado apenas armazena texto cifrado — ele não consegue derivar a chave, a frase-senha ou o texto simples.

Instalação

npm install -g @wundervault/mcp-server

Início rápido

{
  "mcpServers": {
    "wundervault": {
      "command": "wundervault-mcp",
      "env": {
        "WUNDERVAULT_AGENT_NAME": "<agent-name>"
      }
    }
  }
}

As chaves nunca são colocadas na configuração do MCP. O servidor nomeia seu agente e então solicita as credenciais desse agente ao daemon local wundervault-agent por meio de um socket unix. onboard.py registra o agente e inicia o daemon.

Nova conta? wundervault.com tem um fluxo de integração de agente de 90 segundos que gera essa configuração para você.

Plataformas suportadas

Linux é a plataforma verificada. macOS funciona para entrega de segredos; Windows não.

A entrega é exclusivamente POSIX por construção: a receita sudo canaliza via /bin/sh, e as receitas git / ssh-passphrase precisam de mkfifo e setsid. No Windows, esses mecanismos retornam um erro claro de "não suportado" em vez de falhar em algum lugar profundo.

O bloqueio de instância única tem duas implementações: um socket abstrato mantido pelo kernel no Linux e portas de loopback em outros lugares. Apenas a versão Linux é coberta por testes — veja HANDOFF-lock-on-non-linux.md para saber o que não é verificado no macOS e por quê. O CI executa ambas as plataformas; a suíte de bloqueio é executada no Linux.

Modelo de segurança

  • Conhecimento zero: A chave de criptografia vive apenas no processo do servidor MCP. O servidor Wundervault nunca a vê.
  • Queima após a leitura: Segredos em texto simples nunca são retornados ao agente chamador. Após a descriptografia, o agente recebe apenas "Secret retrieved and burned.".
  • Limpeza de execução: A saída padrão/erro do comando é limpa do texto simples antes de ser retornada; padrões de escape de shell ($(), crases, sh -c, eval) e redirecionamentos de arquivo de segredos são rejeitados antes da descriptografia.
  • Integridade de diretivas: Assinaturas de diretivas no lado do servidor (PBKDF2-HMAC-SHA256, 600 mil iterações) são verificadas antes que qualquer segredo seja liberado.
  • Seguro contra timing: A comparação HMAC usa crypto.timingSafeEqual.
  • Acesso em camadas: Camadas de acesso por entrada são aplicadas no lado do servidor; segredos de camada alta exigem aprovação humana antes que um agente possa usá-los.

Limitações honestas

  • A plataforma é open-core: este servidor MCP e a criptografia do navegador são AGPL-3.0 para que você possa auditar tudo o que toca seus segredos, mas o serviço hospedado em si não é código aberto.
  • Um daemon local deve ser executado ao lado do agente; configurações totalmente isoladas não se encaixam.
  • Por design, o agente nunca pode ler o valor de um segredo — se seu fluxo de trabalho precisar que o modelo raciocine sobre o segredo em si, esta é a forma errada.

Ferramentas

vault_entries_list

Lista todas as entradas do cofre disponíveis para este agente. Retorna IDs de entrada e nomes de segredos — sem valores.

Input: {}
Output: "Vault entries (N):\n  [entry_id]  secret_name  (tier: read)"

vault_entry_get

Recupera e descriptografa um segredo do cofre. Opcionalmente, executa um comando com ele.

Input:
  entry_id: string          # from vault_entries_list
  purpose: string           # audit log reason
  exec?: string             # optional shell command

Output: "Secret retrieved and burned." (plaintext NEVER returned)

Padrão de execução segura (exemplo com sudo):

sudo -S systemctl restart nginx <<< "$WUNDERVault_SECRET"

NÃO use echo $WUNDERVault_SECRET | sudo -S — isso expõe o segredo nos logs do processo.

vault_exec

Executa um comando de shell com um segredo do cofre injetado como variável de ambiente — localmente ou em um host remoto via SSH. O segredo é injetado no subprocesso e o buffer é zerado imediatamente após o spawn; padrões de escape são rejeitados antes da descriptografia.

Input:
  purpose: string           # audit log reason
  command: string           # full shell command (no escape patterns)
  entry_id?: string         # secret to inject (omit for SSH-key-only remote exec)
  working_dir?: string
  inject_as?: { env_key, pre_command?, post_command? }   # override entry's exec_config
  remote_host?: { host, user, ssh_key_entry_id? | ssh_key? }

Com remote_host.ssh_key_entry_id, a chave SSH é buscada no cofre e usada sem nunca ser gravada em disco.

vault_entry_inject_env

Grava um segredo do cofre diretamente em um arquivo de configuração (~/.npmrc, ~/.netrc, ~/.docker/config.json ou um .env do projeto) sem que o texto simples passe pelo agente.

Input:
  entry_id: string
  purpose: string
  file_path: string         # allowed config file paths only
  env_key: string           # variable name to set

vault_rsync

Sincroniza um diretório local para um host remoto usando rsync via SSH, com a chave SSH buscada no cofre (arquivo de chave temporário excluído imediatamente após a transferência).

vault_entry_forget

Descarta uma referência local. Sem efeito no servidor.

Input: { entry_id: string }
Output: "Reference [id] discarded from local context."

Credenciais

O servidor MCP não guarda chaves próprias e não recebe nenhuma na linha de comando. Na primeira chamada de ferramenta, ele as resolve assim:

  1. WUNDERVAULT_AGENT_NAME (obrigatório) nomeia qual agente registrado este processo é.
  2. O token do agente é lido de WUNDERVAULT_AGENT_TOKEN ou de ~/.wundervault/agents/<name>.token.
  3. Esse token é apresentado ao daemon local via ~/.wundervault/agents/<name>.sock, que retorna a chave da API, a chave de criptografia e a URL do cofre.

Se o daemon não estiver em execução, as chamadas de ferramenta falham com instruções em vez de recorrer a uma fonte mais fraca. Execute onboard.py para registrar um agente e iniciá-lo.

Opções de CLI

wundervault-mcp [options]

  --url <url>   API base URL override (default: supplied by the daemon)
  --help        Show help

Não há flags --api-key, --enc-key ou --credentials. Opções desconhecidas são rejeitadas.

Carteiras de agente (x402)

Um pagamento x402 é apenas uma assinatura, e uma chave de carteira é um segredo do cofre como qualquer outro. Armazene a chave na camada 2, faça o agente assinar o payload de pagamento via vault_exec, e a chave é injetada em um subprocesso de assinatura local — ela nunca entra no contexto do modelo, e cada uso precisa da aprovação do proprietário primeiro (a chamada negada do agente carrega um id de solicitação; a aprovação é limitada àquele agente + segredo, uma vez ou por uma janela de 15/60 minutos). Executamos isso de ponta a ponta na Base Sepolia — a execução verificada está documentada em wundervault.com/agent-wallets. Política específica de pagamento (limites de gasto, listas de beneficiários permitidos) ainda não foi construída: compatível, não produtizada.

Modo sandbox / demonstração

Defina WUNDERVAULT_MOCK=1 para executar o servidor sem um daemon wundervault-agent ou quaisquer credenciais. Nesse modo, toda chamada de ferramenta retorna uma resposta representativa claramente rotulada como [DEMO MODE] em vez de contatar o cofre — nenhum segredo real está envolvido. Isso existe para que você possa explorar a superfície das ferramentas sem uma conta, e para que scanners de diretório MCP e CI (por exemplo, Glama) possam iniciar o servidor, exercitar cada ferramenta e validar a compilação sem um cofre ativo. Está desativado por padrão e nunca é habilitado em produção.

"env": { "WUNDERVAULT_MOCK": "1" }   // demo/CI only — returns fake, labelled output

Compilando a partir do código-fonte

git clone https://github.com/wundervault/wundervault-mcp.git
cd wundervault-mcp
npm install
npm run build   # compiles TypeScript to dist/
npm test        # run the test suite

Mantenha-se atualizado

Lançamentos, notas de segurança e posts de produto saem no X como @wundervault1. Histórico completo de lançamentos: wundervault.com/changelog.

Licença

Licenciado sob a GNU Affero General Public License v3.0 ou posterior (AGPL-3.0-or-later). Veja LICENSE.

Wundervault é open-core: este servidor MCP e o cliente são código aberto; o serviço hospedado em wundervault.com é uma oferta comercial. Para consultas comerciais ou de hospedagem, entre em contato via wundervault.com/contact.