为什么选 Sigil
一个问题
AI 时代，"凭据"被推到了一个非常尴尬的位置。
你想让 Claude / Cursor / Cline 帮你查一下生产数据库的慢查询、推一段代码到 GitHub、给客户邮箱发个对账单——它都能干，只要你把 Token / 密码 / 私钥贴进对话框。
但只要贴进去：
- 它进了 AI 的上下文窗口
- 大多数情况下，它进了 AI 厂商的日志
- 多窗口同步时，它跟着对话记录漂了
- 截图 / 屏幕分享时，它在画面里裸奔
- 你后悔了——但 Token 已经"在那里"了
这是一个本不该有的妥协：要么放弃 AI 协同，要么放弃凭据安全。
Sigil 的答案
把"AI 协同"和"凭据安全"重新拆开。
| 中间发生了什么 | |
|---|---|
| 1. 你录入凭据 | Sigil 用 AES-256-GCM 加密后落 OS 密钥环 |
| 2. AI 通过 MCP 协议请求"我要查数据库" | Sigil 解密凭据 → 在本机执行 → 用脱敏规则处理结果 |
3. AI 拿到的是脱敏后的结果 + [REDACTED:xxx] 占位 | AI 从未见过明文 Token |
| 4. 整次调用记入审计日志 | timestamp / caller / capability / 是否经临时授权 |
凭据进了金库就没再出来过——出来的是"能力的执行结果"。
和同类产品的差别
和 1Password / Bitwarden 比
1Password 们解决的是**"人记不住密码"**的问题。它们的核心场景是：你登录某个网站时，浏览器扩展替你填上去。
Sigil 解决的是**"AI 在帮人干活时该如何安全地拿密钥"**的问题。
它们正交、不冲突——但当你的工作流里 AI 占的比重越来越大，Sigil 解决的问题会越来越突出。
和"直接贴 Token 给 AI"比
| 维度 | 直接贴 | Sigil |
|---|---|---|
| AI 知道明文吗 | 必然 | 永远不 |
| 多窗口同步 | Token 跟着漂 | 不动 |
| 回头要轮换 | 找历史对话清除 | 在 Sigil 里换一下，下次自动用新的 |
| 想限时给同事 | 没办法 | 4 档 TTL 临时授权 |
| 出事了想追溯 | 翻日志/对话 | 直接查审计 |
和云端凭据托管比
不少团队用 HashiCorp Vault / AWS Secrets Manager 这类企业方案。它们在企业里很合适，但：
- 个人开发者用不起
- 多了一层"信任云端"的假设
- AI 协同场景不是它们的核心设计目标
Sigil 是本地优先：所有数据落在本机，没有"我把密码托管给谁了"这一步。
设计原则
1. 本地优先
凭据元数据 → 本机 SQLite 凭据明文 → AES-256-GCM 加密后落 OS 密钥环 审计日志 → 本机 SQLite
没有云端、没有服务器、没有"忘了密码找回"——这是 trade-off，换来的是"我清楚知道我的密钥在哪、被谁碰过"。
2. 协议化交付
MCP（Model Context Protocol）是 Anthropic 推出的开放协议。Sigil 直接做 MCP Server，意味着任何兼容 MCP 的客户端都能接入：
Claude Code、Cursor、Cline、Zed、Continue……以及未来任何兼容方。
3. 双向拦截
- PreToolUse Hook：AI 要调用工具前，Sigil 注入凭据
- PostToolUse Hook：工具结果回给 AI 前，Sigil 用正则 + 模式匹配脱敏
两道闸门都在 AI 进程之外。AI 不知道闸门存在，也碰不到。
4. 留痕，不留密
审计日志记录"谁在什么时候用了什么能力"——但 Token 值本身永远不入审计，只留 hash。
合规需要的是"可追溯"，不是"明文留底"。
不适合谁
- 你完全不需要 AI 帮忙——直接 1Password 够了
- 你的凭据在云端（GitHub Actions secrets / AWS IAM）就够了，本机不存什么敏感东西
- 你需要严格的企业级 RBAC + 多人审批工作流——Sigil 目前是单用户工具
下一步
- 想动手试试：5 分钟快速上手 →
- 想看具体怎么和 Claude Code 串起来：接入 Claude Code →
- 想了解安全模型细节：安全总览 →