vaultshell
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MASTER_KEY | Yes | Master key for the encrypted-file backend. Must be 64 hex characters (32 bytes). Can be generated with `openssl rand -hex 32`. | |
| VAULTSHELL_HOME | No | Overrides the data directory. Default is ~/.vaultshell. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| shell_execA | Execute a one-shot shell command with secrets injected per matching rule. Output is redacted: injected secret values never appear in the response. Dangerous commands (env, printenv, export -p, /proc/*/environ, ...) are hard-blocked. There is no free-form env parameter; secrets are only injected by reference via rules. |
| secret_listA | List registered secret names with metadata (backend ref, resolvable). Never returns values. |
| secret_setB | Store a secret value into the configured backend. The value is persisted, never echoed back, and the name is registered in rules.yaml (ref only). |
| secret_deleteB | Delete a secret from the backend and unregister it from rules.yaml. |
| secret_probeB | Check whether a secret ref can be resolved. Returns only {ok, masked}; masked never contains value fragments unless defaults.maskTail > 0. |
| rule_listA | List injection rules with static warnings (e.g. rules matching every directory → potential unintended full injection). |
| audit_queryB | Query recent audit entries (newest last). Entries contain names and redacted commands only, never values. |
| shell_session_openA | Open a persistent shell session (PTY when node-pty is available, plain child_process otherwise — the response's |
| shell_session_sendA | Send a command to a persistent session. Output (merged stdout/stderr) is redacted before returning. Dangerous commands are blocked per security.dangerousCommands. Returns {output, exitCode}. |
| shell_session_closeB | Close a session: kill the process; injected secrets die with it. |
| shell_session_listA | List live sessions (metadata only: id, cwd, injected names, pty, ttl, timestamps). |
| shell_session_revokeA | Immediately kill a session and rebuild a fresh one WITHOUT any injected secrets. Use when a session may have been compromised. Returns the new sessionId. |
| rule_validateA | Statically validate rules.yaml and return findings: unknown secret refs, unreachable rules (shadowed by earlier ones), inject-everywhere rules (high severity), requireConfirm capability notes, union mergeStrategy risk notes. |
| shell_proxy_startA | Start a credential-injecting reverse proxy on 127.0.0.1 (random port) for a |
| shell_proxy_stopC | Stop a running credential proxy. |
| shell_proxy_listA | List running credential proxies (metadata only: id, port, upstreamHost, secret NAME, expiry, request count). Never includes values. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools target distinct resources and operations, covering secret lifecycle, shell execution, persistent sessions, proxy management, rules, and audit. The only slight overlap is between secret_probe and secret_list, since both can report secret resolvability, but their descriptions clarify the intended use.
All tool names use snake_case with clear domain prefixes such as secret_, shell_, shell_session_, shell_proxy_, rule_, and audit_. The verb_noun structure is consistent throughout, with no mixed conventions or vague naming.
The server has 16 tools across five coherent subdomains, slightly above the typical 3-15 range but still well-scoped. Each tool appears to earn its place, with no obvious redundant operations.
Core secret, shell, session, proxy, and audit workflows are well covered, including session revocation and proxy lifecycle. Rule management is read-only via list and validate, with no create/update/delete tools, which is a minor gap likely handled through the underlying rules.yaml file.