Jitpass 为编码代理将 Mac 开发者密钥置于 Touch ID 保护之下

Why it matters

Coding agents can read the same local credential files as developers. Jitpass secures that endpoint without requiring teams to rebuild every command-line workflow.

Meni Tasa (@menitasa) 正在为散落在开发者 Mac 上的凭据构建一层安全保护： Jitpass，即 jit 的开发者，能发现明文秘密，将它们移动到本地加密保管库中，并且仅在经批准的进程需要时才释放每个值。

该项目针对一个长期存在的安全弱点发起攻势，随着编码代理获得对开发者文件和 shell 的广泛访问，这一弱点变得更难忽视。API 密钥和云凭据仍然保存在 .env 文件、shell 历史、AWS 配置、.npmrc 文件和 MCP 服务器设置中。任何在开发者账户下运行的程序通常都能读取它们。AI 代理也可能将这些值复制到抄本、日志或远程模型请求中。

Tasa 的解决方案是从文件中移除真实凭据，同时不破坏期望在该位置找到它的工具。Jitpass 用诱饵、遮蔽或挂钩替换被暴露的值，然后在 Touch ID 提示后将真实密钥注入被授权的进程。公共仓库 在 2026 年 8 月 15 日显示有活跃开发，GitHub 上列出了 587 次提交。

Tasa 在他的公开简介中描述自己为一名拥有十多年网络、IT 与安全经验的网络安全运营负责人。他还创立了 CyberBrief Project，这是一项涵盖攻击者技术和实用防御的教育项目。这种运营背景在 jit 的设计中有所体现：该工具围绕开发者实际留下凭据的杂乱场所构建，而不是假设每个秘密都已存在于集中管理的保管库中。

替换文件而不替换工作流

Jitpass 将清理分为三类主要操作。jit scan 在不修改文件或打印秘密值的情况下扫描用户主目录中暴露的凭据。jit migrate 将受支持的凭据移动到保管库并重写其原始位置。jit run -- <command> 在为单个进程提供选定值的同时，让其他软件仍然看到诱饵。

受支持的集合 包括 .env 文件、shell 导出与历史、AWS 和 Terraform 凭据、Kubernetes 配置、Docker 注册表登录、Google Cloud application-default 凭据、.npmrc、.netrc 以及 MCP 配置。Jitpass 还记录了针对命令行工具的封装器，包括 GitHub CLI、Stripe、Vercel、Claude、Codex、Gemini 和 Cursor Agent。

一些集成可以直接请求凭据。AWS 可以使用其 credential_process 机制，而 Docker 可以使用凭据助手。那些只知道如何读取文件的工具可以在 jit run 下运行，jit 会将所需值放入该进程的环境中。Jitpass 在本地审计日志中记录成功读取、被拒请求和解锁操作。

保管库本身保留在 Mac 上。根据 jit 的安全架构，每个秘密都作为单独加密的文件存储，使用单独的数据密钥，并由存放在 macOS 登录 Keychain 中的主密钥包装。Touch ID 或设备密码用于门控访问。Jitpass 表示保管库不进行同步，且产品不要求账户或遥测。

编码代理让端点问题更加尖锐

Jitpass 最及时的使用场景是以开发者自身权限运行的编码代理。操作系统将该代理视为另一个本地进程。如果该进程打开 .env，该文件通常会像为开发者的应用返回生产密钥一样返回密钥。

Jitpass 的代理设计 改变了静态可用内容。打开该文件的代理将收到一个诱饵。当代理调用被封装的命令（例如 gh 或 terraform）时，jit 可以在获得批准后将凭据提供给该特定命令。如果开发者明确授权一个会打印凭据的进程，真实值仍然可能进入代理的抄本——这是 jitpass 文档中记录的边界，而非声称能完全消除的边界。

长期运行的代理会产生另一个问题：当屏幕锁定后无人可用以响应生物识别提示。Jitpass 支持开发者预先批准的有时间限制的进程授权。诸如 jit grant --process claude --profile deploy --for 8h 之类的命令可以为来自特定终端会话的进程授权命名的秘密。每次使用都会在审计轨迹中可见，授权会到期或可被撤销。

这一端点聚焦使 jitpass 与成熟的秘密管理厂商的更大举措并列。1Password 在 2026 年 2 月扩展了对本地工具、CI 系统和 AI 辅助开发的运行时访问。其Developer Watchtower 可以识别明文 .env 凭据并将它们移动到 1Password Environments。该公司的 Credential Broker 于 6 月推出，并在 7 月进入公共预览，目标是针对诸如 GitHub Actions 之类系统的工作负载身份和限定凭据交付。

Jitpass 正在追求一个更窄的切入点。它从已经散落在某个开发者 Mac 上的凭据入手，试图保留导致暴露的命令和文件格式。其本地保管库和基于进程的提示减少了设置和管理面，而牺牲了大型产品所提供的共享控制、跨平台支持和组织范围的治理能力。

安全边界故意保持狭窄

Jitpass 并不声称能使被入侵的用户账户变得安全。其文档说明，在接收凭据后，一个进程可以对该秘密做任何它想做的事情。该实用工具也不管理另一个工具在下游创建的每个令牌，包括某些 AWS 角色和 SSO 缓存。

从 shell 历史中迁移凭据属于清理而非轮换。旧副本可能仍然存在于备份、仓库或打开的 shell 内存中。Jitpass 警告用户需要轮换这些凭据。如果包含秘密的文件以前被提交，Jitpass 也会在 Git 历史中保留旧值。

当前构建仅限于 Apple Silicon 的 macOS，仍被描述为开发中。Intel Mac 用户可以从源代码编译。尽管代码是公开可读的，jit 使用 PolyForm Perimeter License，而不是传统的宽松开源许可证。该仓库允许个人和公司内部使用，同时对其他商业用途保留更严格的控制权。

这种有限的范围也是产品最清晰的纪律。Tasa 将开发者笔记本视为其自身的秘密管理边界，并围绕本地文件、生物识别批准和请求访问的进程构建控制。AI 编码工具使该边界更加繁忙且更难检查。Jitpass 打赌，如果开发者在之后仍能继续输入相同命令，他们就会对该边界进行保护。