安全总览
Sigil 的安全模型由四道闸门构成。任何一道闸门都不"自称完美"——它们各自防一类问题，组合起来才是完整防线。
四道闸门
┌──────────────────────────────────────────────────────────┐
│ 闸门 1：加密存储 │
│ OS 密钥环 + AES-256-GCM + 内存清零（zeroize） │
│ 防的是：磁盘文件被拷走 / SQLite 被盗 / 进程被 dump │
├──────────────────────────────────────────────────────────┤
│ 闸门 2：使用控制（Scope Policy） │
│ 凭据级别的白名单/黑名单 + 客户端 Bearer Token 范围 │
│ 防的是：AI 越权（"我能用这条凭据吗？"） │
├──────────────────────────────────────────────────────────┤
│ 闸门 3：拦截与脱敏（Hook） │
│ PreToolUse 注入凭据 / PostToolUse 脱敏输出 │
│ 防的是：明文流回 AI 上下文 │
├──────────────────────────────────────────────────────────┤
│ 闸门 4：审计留痕 │
│ 每次调用记录 timestamp / caller / capability / 是否经临授 │
│ 不防直接攻击；事后追溯 / 异常发现 │
└──────────────────────────────────────────────────────────┘每一道都有 能防 和 防不了 的部分。Sigil 不假装"四道闸门加起来 = 绝对安全"——它的承诺是"每道闸门都尽力做好，组合起来把攻击门槛大幅抬高"。
闸门 1：加密存储
详见 凭据加密体系 →。
能防：
- 攻击者拿到 SQLite 文件 → 拿不到明文（密文在 OS 密钥环）
- 攻击者拿到 OS 密钥环密文 → 拿不到明文（缺 AES 主密钥）
- 进程被 dump → 内存里只有 zeroize 包装的临时数据
防不了：
- 你自己的 Windows 账号被劫持（攻击者已经登录就拥有密钥环访问权）
- 操作系统级别的 keylogger（输入时被截走）
- 物理拷走运行中的内存（cold boot 攻击，极小概率）
闸门 2：使用控制
详见 凭据金库 → Scope Policy、MCP Server → 客户端授权。
能防：
- 某个客户端被改了或植入恶意 → 它只能看到 Sigil 暴露给它的工具
- 某条凭据本应只读，AI 想用它做写操作 → 直接被拒
- 临时授权超出原凭据范围 → 创建时就被拒
防不了：
- 你自己授权给了一个不该授权的客户端
- 你给的 Scope Policy 本身就太宽（"全部能力"对一个不信任的客户端）
闸门 3：拦截与脱敏
详见 脱敏与拦截 →。
能防：
- AI 把 Token 写进对话回复（PostToolUse Hook 拦截）
- AI 看到 HTTP 响应里包含的其他凭据（同上）
- 内置能力的错误信息里意外含明文
防不了：
- 100% 完美的脱敏（正则 + 模式匹配不可能覆盖所有形态）
- 客户端拿到结果之后自己再做什么（截图、转发、贴到聊天）
- AI 提示注入攻击（"忽略上面的脱敏规则"——但客户端那边可能不上当）
闸门 4：审计留痕
详见 审计日志 →。
能防：什么都不"防"——它是事后镜头。
能做：
- 怀疑某次操作的全过程回放
- 凭据轮换后确认旧 Token 不再被使用
- 合规报告的原始数据
闸门 3 之外：网络层防护
能力执行时 Sigil 会替 AI 发起真实的网络请求（GitHub API / LLM / Webhook / SSH / git）。这一层有一组独立的防护，专防"请求被劫持外发凭据"和"请求被诱导打内网"：
| 防护 | 防的是 |
|---|---|
| SSRF 守卫 | http_request / HTTP 模板解析目标真实 IP 后拒绝 loopback / 内网 / 链路本地 / 云元数据 169.254.169.254，并 DNS pin 防 rebinding |
| 禁重定向 | LLM / Webhook / GitHub 调用一律 redirect=none——防被劫持端点用 302 把 Authorization / x-api-key / 钉钉 sign 跟随外发到攻击者域，同时堵重定向二段跳 SSRF |
| git 协议白名单 | 工作区 git 强制 GIT_ALLOW_PROTOCOL=https:ssh，封死 ext::sh -c 这类"远端 URL 即本机命令"的 RCE |
| 路径 / ref / 名称校验 | GitHub owner/repo、git ref/分支/tag、变量/secret 名拼进 URL/命令前做字符集白名单校验，防 path / query / 选项注入 |
| MCP Origin 校验 | 对外 MCP server 校验 Origin 头，防恶意网页借 DNS rebinding 访问本机 127.0.0.1:8421 |
| 审计落库脱敏 | 审计 actual_command 落库前对明文 token 做占位替换，明文不进未加密的 SQLite 列 |
这些防护与四道闸门正交——闸门管"谁能用哪条凭据、明文别流回 AI"，网络层管"请求本身别被劫持或诱导"。
不在 Sigil 范围内的威胁
实事求是地说，下面这些 Sigil 无能为力：
| 威胁 | 应对方向 |
|---|---|
| 你的整个 Windows 账号被攻破 | 启用全盘加密 (BitLocker)、强密码、TPM |
| 屏幕被远程查看（远控 / 共享） | 控制远控权限、敏感操作期间断屏共享 |
| 客户端本身是恶意软件 | 只信任主流 MCP 客户端，不装来路不明的 |
| Prompt 注入让 AI 主动配合攻击者 | 客户端的二次确认机制 + Sigil 的 Scope Policy |
| 你自己手动复制 Token 到外部 | 不要这么干 → 用 Sigil 的 MCP 代理 |
Sigil 的边界是**"代理 + 拦截 + 审计"**。边界之外的事，需要其他工具或习惯配合。
设计原则
写在最后，但是是 Sigil 安全设计的基础：
1. Don't trust, verify
不信任客户端、不信任 AI、不信任脱敏正则的完美性——每个组件都假设其他可能失败，自己尽力做好那一份。
2. Defense in depth
四道闸门都不"自称完美"——但攻击者需要同时绕过多道才能造成实际伤害。
3. 安全默认
所有需要权衡安全 vs 便利的地方，默认偏向安全：
- 写类能力默认需要客户端确认
- 远程网关默认不启用
- Token 默认全部能力 → 实际推荐用户细化为白名单
- Scope Policy 是强制的，不是建议的
4. 用户在场
Sigil 不做"完全自动化"——很多关键操作都把用户拉回来确认。这会降低体验流畅度，但确保了在 AI 出乱子时人能拦住。
5. 诚实
不承诺"零泄漏"。不承诺"绝对安全"。承诺的是"每一道闸门都尽力做到当前可工程实现的最好水平"。