jitpass 把明文密钥藏到 Touch ID 后：旧工具如何继续读取凭证

jitpass 发布仍在开发中的 macOS 凭证工具 jit，它会扫描 .env、AWS 配置、Shell 导出、.npmrc 和 MCP 配置中的明文密钥，把真实值迁入本地加密保险库，再用兼容钩子让旧工具继续按原方式读取。

一句话结论：jit 的工程价值不是又造一个密码管理器，而是把“密钥必须存在”和“密钥必须长期明文躺在磁盘上”拆开，并在具体进程使用时重新获得用户授权。

传统开发环境里，凭证往往为了兼容工具而散落在文件中。任何以当前用户权限运行的安装脚本、编辑器插件或 AI Agent 都可能读取它们。jit migrate 会先生成迁移计划，经确认后把密钥放入保险库，并在原位置留下诱饵、Shell 钩子、AWS credential_process 或 PATH 包装器。迁移前的文件会加密备份，也可以撤销恢复。

日常使用有两道门。保险库首次解锁需要 Touch ID，活跃会话默认五分钟后重新锁定，最长不超过八小时；某个工具第一次请求具体凭证时，还会出现按工具授权提示。AWS、Docker 等支持凭证助手的工具可以直接请求，只有运行时读文件的程序则需要通过 jit run -- 注入。

AI Agent 的无人值守任务是更难的一环。项目提供有时限、可撤销并记录审计日志的进程授权，可以允许某个终端进程树在窗口期内使用指定凭证。便利也意味着信任范围扩大：该进程树中的子进程会继承授权，配置时必须把时间、凭证集合和父进程压到最小。

这不是终端被入侵后的万能保护。真实密钥最终仍会进入获准进程的内存，能控制该进程或其输出的攻击者仍可能取得数据。工具目前主要支持 Apple Silicon macOS，Intel Mac 需自行构建，项目也明确标注仍在开发。其 PolyForm Perimeter 许可允许个人和企业内部免费使用，但不是 OSI 定义的开源许可证。

关键事实

• 平台状态：主要支持 Apple Silicon macOS，仍在开发
• 保护对象：.env、云凭证、Shell 配置、包管理器令牌和 MCP 配置等
• 访问机制：本地加密保险库、Touch ID 解锁、按进程同意和审计日志
• 许可：PolyForm Perimeter 1.0.0，并非标准开源许可证

OC 判断

问题不在于开发者不知道明文密钥危险，而在于旧工具只会读文件。jit 选择在兼容层解决问题，这比要求整个工具链同时改造现实得多。但凭证注入只缩短暴露窗口，不能替代最小权限、短期令牌和密钥轮换。

为什么重要

• 对开发者：可以逐步减少磁盘明文密钥，而不必一次替换所有 CLI 和 SDK。
• 对 AI Agent 用户：凭证授权能够按进程、时间和范围审计，不再默认继承全部环境变量。
• 对安全团队：需要验证进程树授权、内存暴露和恢复备份是否符合自身威胁模型。

参考来源

• jitpass/jit