Skip to main content
Glama
Sign In
vault-ask (Erseni Vault)

vault-ask (Erseni Vault)

by Erseni
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

secrets-component

Listed on mcpservers.org Vault Ask MCP server

Zero-knowledge, one-time secret sharing. End-to-end encrypted in the browser. The server only ever stores ciphertext. Supports both sending and requesting secrets without requiring any account.

Part of the Erseni open-source components.

Status: early development. API and on-disk format may change until the first tagged release.

Primary development happens in Erseni's internal monorepo. This repository is a public mirror, kept in sync via Jenkins after every successful production deploy. Issues and merge requests are welcome; see CONTRIBUTING.md.

Features

  • Send a secret: create a one-time link, recipient decrypts in the browser, secret self-destructs after viewing.

  • Request a secret: create an inbound link, send it to a third party (customer, colleague) who submits a secret without an account. You retrieve it once with your private key.

  • End-to-end encryption: AES-GCM 256 for sending, X25519 + ECIES for requesting. All crypto in the browser via the native Web Crypto API. The server never sees plaintext.

  • No accounts: neither sender nor receiver needs to sign up.

  • Auditable: deterministic build, source SHA embedded in every HTML response, SRI hashes on every script.

  • Secrets for AI agents: cli/ contains vault-ask, a CLI and MCP server that request a secret from a person and hand it to exactly one command or file, masked in every output and never shown to the agent, and that send a generated secret to a person as a one-time link.

Related MCP server: Vaulted MCP Server

Where it runs

The component runs as part of Erseni Vault, hosted in the EU. It is not a standalone application: it depends on Erseni's internal framework, and this repository cannot be installed or self-hosted on its own. The source is published so that the cryptography and the server behaviour can be audited.

vault-ask in cli/ is the exception: it is a standalone Node.js tool that talks to Erseni Vault.

Security model

  • Secret plaintext never leaves the sender's browser.

  • Encryption keys are transported in the URL fragment (#k=...), which browsers never send to servers.

  • Secrets are deleted on first retrieval (atomic DELETE ... RETURNING).

  • Expired secrets are purged every minute by a cron job.

  • No access logs, no IP retention, no backups of the secrets tables.

See docs/ARCHITECTURE.md and docs/THREAT-MODEL.md.

Verifying a running instance

Every page served by a secrets-component instance includes a <meta name="build-sha" content="..."> tag. Match that SHA against a tag in this repository to confirm the deployed code.

curl -s https://secrets.example.com/send | grep build-sha

License

AGPL-3.0-or-later. See LICENSE.

Security disclosure

See SECURITY.md.

Available Tools

3 tools
request_secretA

Use this whenever you need a password, token, API key or other secret from the user, for example "I will give you my database password" or "you need my API key for X". Never ask the user to type or paste a secret into the chat. Asks the user for one or more secrets and writes them into a .env file or a file, without the values ever passing through this conversation. First call without request_id: returns a link. Show it to the user, then call again with the returned request_id; that call waits for the answer and writes the file with permissions 600. The result only contains names and lengths, never a value.

Inputs: file, names, env_file, request_id, +1 more.

run_with_secretA

Use this whenever a single command needs a password, token, API key or other secret from the user, for example "connect to the database with my password" or "deploy with my API token". Never ask the user to type or paste a secret into the chat. Asks the user for one or more secrets and runs exactly one command with them as environment variables. The user sees the command before entering anything, and only this command can receive the values. First call without request_id: returns a link. Show it to the user, then call again with the returned request_id; that call waits for the answer, runs the command and returns its exit code and its output with every value masked.

Inputs: cwd, names, command, request_id, +1 more.

send_secretA

Use this whenever the user asks you to generate, create or send them a password, token, API key or other secret, for example "generate a password for my database", "generier mir ein Passwort" or "send me the key". Do not generate a secret any other way and never write one into the chat. Generates the value locally (32 letters and digits unless length or charset say otherwise) or takes it from from_file or from_env, encrypts it on this machine and returns only a one-time link that shows the value once in the browser. Give the user that link. With env_file, file or command the same value also goes to that destination (needs name except for file), so the system and the link hold the same value. The result contains the link, its expiry and the length, never the value.

Inputs: cwd, file, name, label, +7 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    Deploy Server
    Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

    TDQS

    A4.3/5.0

    Scored across 3 tools

    Disambiguation4/5

    The three tools split along a clear axis: request_secret pulls secrets inbound into a file, run_with_secret uses a secret to execute one command, and send_secret generates/returns a secret outbound. request_secret and run_with_secret share the same ask-the-user/link flow and could momentarily be confused, but their end outcomes (write a file vs. run a command) are clearly spelled out.

    Naming Consistency5/5

    All three follow a strict verb_secret pattern (request_secret, run_with_secret, send_secret). The verb meaning is consistent: the action describes what happens to the secret (request in, run with, send out).

    Tool Count4/5

    Three tools is on the lean side but each covers a genuinely distinct secret lifecycle stage (acquire, use, issue). The set feels deliberately minimal rather than padded, which suits a security-sensitive vault.

    Completeness4/5

    Inbound acquisition, command usage, and outbound distribution with multiple destinations (file, env_file, command) are all covered, giving a coherent lifecycle. Minor gaps: no explicit tool for listing, rotating, or revoking previously stored secrets, though these could be handled outside the surface.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Resources

    Related MCP Connectors

    Related MCP Servers

    • zKettle

      benderterminal
      A
      license
      Not graded
      quality
      B
      maintenance
      Self-hosted, zero-knowledge encrypted, self-destructing secrets for secure agent-to-agent coordination
      3
      AGPL 3.0

    • vault-mcp

      MHasnainJafri
      A
      license
      Not graded
      quality
      C
      maintenance
      Enables AI coding agents to securely inject API keys and secrets into environment files, configs, or commands without the agent ever seeing the secret values.
      7 npm
      MIT

    • hush

      lucasvidela94
      A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI coding agents to manage and use API keys and secrets without ever seeing their values, by checking availability, listing names, requesting missing values, and running commands with injected secrets and redacted output.
      52 npm
      MIT