wundervault

Servidor MCP para la gestión de secretos de conocimiento cero de Wundervault. Expone secretos del vault a agentes de IA a través del Protocolo de Contexto del Modelo — los secretos se descifran en el lado del servidor y nunca se devuelven al agente en texto plano.

GitHub
2
Prueba este MCPPatrocinado

Documentación

@wundervault/mcp-server

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

Una bóveda de secretos de conocimiento cero para agentes de IA. Cada clave de API que pegas en un chat de agente o en un archivo .env termina en ventanas de contexto, transcripciones y registros del proveedor. La respuesta de Wundervault: el agente nunca recibe el secreto. Pide trabajo — "ejecuta este despliegue con la clave inyectada" — y un demonio local descifra el secreto, lo inyecta en el entorno del subproceso, pone el búfer a cero y limpia la salida antes de que el agente vea algo.

Este repositorio es el servidor MCP que expone ese flujo de trabajo a cualquier cliente de Model Context Protocol — Claude Code, Cursor, Cline y otros.

No confíes en la afirmación — pruébala: la propiedad de conocimiento cero es verificable de forma independiente en tu propio límite de red en unos 5 minutos (DevTools del navegador o una prueba canaria con mitmproxy). Guía + nuestra propia transcripción de prueba: wundervault.com/verify.

Cómo 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
                               └───────────────────┘

Los secretos se cifran en el lado del cliente (AES-256-GCM mediante Web Crypto) antes de subirlos. El servicio alojado solo almacena texto cifrado — no puede derivar la clave, la frase de contraseña ni el texto plano.

Instalación

npm install -g @wundervault/mcp-server

Inicio rápido

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

Las claves nunca se colocan en la configuración de MCP. El servidor nombra a su agente y luego pide al demonio local wundervault-agent las credenciales de ese agente a través de un socket unix. onboard.py registra al agente e inicia el demonio.

¿Cuenta nueva? wundervault.com tiene un flujo de incorporación de agentes de 90 segundos que genera esta configuración por ti.

Plataformas compatibles

Linux es la plataforma verificada. macOS funciona para la entrega de secretos; Windows no.

La entrega es solo POSIX por diseño: la receta sudo canaliza a través de /bin/sh, y las recetas git / ssh-passphrase necesitan mkfifo y setsid. En Windows esos mecanismos devuelven un error claro de "no compatible" en lugar de fallar en algún lugar profundo.

El bloqueo de instancia única tiene dos implementaciones: un socket abstracto mantenido por el kernel en Linux y puertos de bucle local en otros lugares. Solo la de Linux está cubierta por pruebas — consulta HANDOFF-lock-on-non-linux.md para ver qué no está verificado en macOS y por qué. CI ejecuta ambas plataformas; la suite de bloqueo se ejecuta en Linux.

Modelo de seguridad

  • Conocimiento cero: La clave de cifrado vive solo en el proceso del servidor MCP. El servidor de Wundervault nunca la ve.
  • Quemar después de leer: Los secretos en texto plano nunca se devuelven al agente que llama. Después del descifrado, el agente recibe solo "Secret retrieved and burned.".
  • Limpieza de ejecución: La salida estándar y de error del comando se limpian del texto plano antes de devolverse; los patrones de escape de shell ($(), comillas invertidas, sh -c, eval) y las redirecciones de archivos de secretos se rechazan antes del descifrado.
  • Integridad de directivas: Las firmas de directivas del lado del servidor (PBKDF2-HMAC-SHA256, 600k iteraciones) se verifican antes de liberar cualquier secreto.
  • Seguro en tiempo: La comparación HMAC usa crypto.timingSafeEqual.
  • Acceso por niveles: Los niveles de acceso por entrada se aplican en el lado del servidor; los secretos de nivel alto requieren aprobación humana antes de que un agente pueda usarlos.

Limitaciones honestas

  • La plataforma es código abierto con núcleo abierto: este servidor MCP y el cifrado del navegador son AGPL-3.0 para que puedas auditar todo lo que toca tus secretos, pero el servicio alojado en sí no es de código abierto.
  • Un demonio local debe ejecutarse junto al agente; las configuraciones totalmente aisladas no encajan.
  • Por diseño, el agente nunca puede leer el valor de un secreto — si tu flujo de trabajo necesita que el modelo razone sobre el secreto en sí, esta no es la forma adecuada.

Herramientas

vault_entries_list

Lista todas las entradas de la bóveda disponibles para este agente. Devuelve IDs de entrada y nombres de secretos — sin valores.

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

vault_entry_get

Recupera y descifra un secreto de la bóveda. Opcionalmente ejecuta un comando con él.

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)

Patrón de ejecución segura (ejemplo con sudo):

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

NO uses echo $WUNDERVault_SECRET | sudo -S — eso expone el secreto en los registros del proceso.

vault_exec

Ejecuta un comando de shell con un secreto de la bóveda inyectado como variable de entorno — localmente o en un host remoto a través de SSH. El secreto se inyecta en el subproceso y el búfer se pone a cero inmediatamente después del lanzamiento; los patrones de escape se rechazan antes del descifrado.

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? }

Con remote_host.ssh_key_entry_id, la clave SSH se obtiene de la bóveda y se usa sin escribirse nunca en el disco.

vault_entry_inject_env

Escribe un secreto de la bóveda directamente en un archivo de configuración (~/.npmrc, ~/.netrc, ~/.docker/config.json o un .env de proyecto) sin que el texto plano pase por el 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 un directorio local a un host remoto usando rsync sobre SSH, con la clave SSH obtenida de la bóveda (el archivo de clave temporal se elimina inmediatamente después de la transferencia).

vault_entry_forget

Descarta una referencia local. Sin operación en el servidor.

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

Credenciales

El servidor MCP no tiene claves propias ni las recibe por línea de comandos. En la primera llamada a una herramienta las resuelve así:

  1. WUNDERVAULT_AGENT_NAME (obligatorio) nombra qué agente registrado es este proceso.
  2. El token del agente se lee de WUNDERVAULT_AGENT_TOKEN, o de ~/.wundervault/agents/<name>.token.
  3. Ese token se presenta al demonio local a través de ~/.wundervault/agents/<name>.sock, que devuelve la clave API, la clave de cifrado y la URL de la bóveda.

Si el demonio no está en ejecución, las llamadas a herramientas fallan con instrucciones en lugar de recurrir a una fuente más débil. Ejecuta onboard.py para registrar un agente e iniciarlo.

Opciones de CLI

wundervault-mcp [options]

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

No hay banderas --api-key, --enc-key ni --credentials. Las opciones desconocidas se rechazan.

Carteras de agentes (x402)

Un pago x402 es solo una firma, y una clave de cartera es un secreto de la bóveda como cualquier otro. Guarda la clave en el nivel 2, haz que el agente firme el payload del pago a través de vault_exec, y la clave se inyecta en un subproceso de firma local — nunca entra en el contexto del modelo, y cada uso necesita la aprobación del propietario primero (la llamada denegada del agente lleva un id de solicitud; la aprobación está limitada a ese agente + secreto, una vez o en una ventana de 15/60 minutos). Ejecutamos esto de extremo a extremo en Base Sepolia — la ejecución verificada está documentada en wundervault.com/agent-wallets. La política específica de pagos (límites de gasto, listas de beneficiarios permitidos) aún no está construida: compatible, no productizada.

Modo sandbox / demo

Establece WUNDERVAULT_MOCK=1 para ejecutar el servidor sin un demonio wundervault-agent ni credenciales. En este modo, cada llamada a una herramienta devuelve una respuesta representativa claramente etiquetada como [DEMO MODE] en lugar de contactar a la bóveda — ningún secreto real está involucrado. Esto existe para que puedas explorar la superficie de herramientas sin una cuenta, y para que los escáneres de directorios MCP y CI (por ejemplo, Glama) puedan iniciar el servidor, ejercitar cada herramienta y validar la compilación sin una bóveda en vivo. Está desactivado por defecto y nunca se habilita en producción.

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

Compilación desde el código fuente

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

Mantente actualizado

Lanzamientos, notas de seguridad y publicaciones de producto salen en X como @wundervault1. Historial completo de lanzamientos: wundervault.com/changelog.

Licencia

Licenciado bajo la GNU Affero General Public License v3.0 o posterior (AGPL-3.0-or-later). Consulta LICENSE.

Wundervault es código abierto con núcleo abierto: este servidor MCP y el cliente son de código abierto; el servicio alojado en wundervault.com es una oferta comercial. Para consultas comerciales o de alojamiento, contacta a través de wundervault.com/contact.