核心用法
Wundervault 为 AI 代理提供零知识（zero-knowledge）加密密钥管理服务，通过 MCP 协议暴露 vault_entries_list、vault_exec、vault_entry_inject_env、vault_rsync 等工具。代理只能获取条目 ID 和名称，密钥明文始终由服务端解密并直接注入命令或文件，绝不返回给代理或出现在聊天记录中。
标准流程：先用 vault_entries_list 查询可用密钥，再调用 vault_exec 执行带密钥注入的 Shell 命令（如 npm publish、数据库查询），或通过 vault_entry_inject_env 将密钥写入 .env 文件。远程部署场景支持 vault_rsync 配合 SSH 密钥自动拉取与清理。
显著优点
1. 零知识架构：密钥端到端加密，服务端解密后直注命令/文件，代理始终不接触明文，杜绝聊天泄露风险。
2. 多级权限（Tier 1/2）：日常操作即时执行，高危操作（生产部署、发布）需用户在仪表盘手动启用 Tier 2，形成强制二次确认。
3. 多代理隔离：每个代理持独立 token 与作用域，审计日志分离，适合团队协作中敏感凭证的细粒度管控。
4. 防御性设计：
- 安装脚本自检 ed25519 签名，拒绝管道执行（
curl | sh被硬阻断）； vault_exec硬阻断 Shell 转义序列（$()、反引号、bash -c），防止密钥注入后的命令注入；- SSH 密钥仅暂写临时文件，rsync 后立即删除。
潜在缺点与局限性
- 托管依赖：需自托管 Wundervault 服务并维护其可用性，单点故障可能影响代理执行带密钥的操作。
- 功能开关复杂度：
vault_entry_inject_env默认禁用，需用户手动在仪表盘开启；Tier 2 亦需人工介入，可能打断自动化流水线。 - 文件权限风险：密钥写入
.env后，文件权限由用户自行管控，工具不自动设置严格权限，存在其他进程读取隐患。 - 生态局限：目前仅支持 Shell 命令注入与
.env写入，尚未覆盖 Kubernetes Secrets、云厂商 IAM 等更复杂的密钥分发场景。
适合人群
- 使用 AI 代理处理敏感工作流（代码发布、数据库操作、服务器部署）的个人开发者与小团队；
- 需多代理协作且要求凭证隔离的企业安全团队；
- 对"聊天中绝不泄露密钥"有硬性合规要求的金融、医疗、政务领域用户。
常规风险
| 风险点 | 说明 |
|--------|------|
代理 token 泄露 | 代理本地仅存作用域 token，非密钥本身，但 token 被盗仍可能被用于执行已授权操作。建议配合主机级防护。 |
| 恶意注入路径 | 启用 `vault_entry_inject_env` 后，代理可将密钥写入任意可达路径，需通过文件系统权限最小化缓解。 |
| 供应链攻击 | 安装脚本虽校验签名，但用户仍需从可信渠道获取初始安装包，首次下载过程存在中间人风险。 |
| 审计盲区 | 服务端审计日志详尽，但代理本地操作（如命令执行后的二次数据处理）不在 vault 审计范围内，需额外监控。 |