很多人已经记不清，自己的电脑上装过多少个 AI 编程工具。
编辑器里有插件，终端里有 Agent，项目目录藏着配置文件，背后还可能连着 MCP 服务。它们能读哪些文件、调用什么命令、拿到哪些密钥，往往散落在不同位置。Geiger 想用一次扫描把这些东西摊到桌面上。
这个方向很实用。反常之处也在这里：我们给 Agent 的权限越来越接近一名开发者，却还在用管理普通软件插件的方式管理它。
Geiger 给的是一张权限清单
按照项目在 Show HN 上的介绍，Geiger 会发现本机支持范围内的 AI Agent，并整理它们可能接触的资源。项目方还强调本地扫描和隐私保护。
它试图回答两个问题：
- 这台机器上有哪些 Agent？
- 按现有配置，它们可能碰到什么？
第二个问题更关键。Agent 的风险很少只来自模型本身，更多来自它手里的工具：文件读取、Shell 命令、代码仓库、浏览器、数据库，以及保存密钥的环境变量。
但标题里的“every AI agent”不能照单全收。扫描工具只能识别它写过规则的产品、版本和配置格式。自定义脚本、公司内部 Agent、改过路径的配置，以及运行时临时获得的权限，都可能落在清单之外。
| 手段 | 能回答什么 | 回答不了什么 |
|---|---|---|
| Geiger 这类扫描器 | 装了什么、配置声明了什么能力 | Agent 是否真的访问过资源 |
| 系统审计日志 | 哪个进程实际读写了什么 | 配置中尚未触发的潜在权限 |
| 容器或沙箱 | Agent 最多能碰到哪里 | 已有配置是否合理 |
| 企业权限策略 | 谁能授权、权限何时失效 | 未纳管的个人工具和脚本 |
所以，Geiger 更像 Agent 时代的资产盘点工具。它能帮助人发现问题，但不会替人阻止问题。
开发者最缺的，恰好就是这张清单
浏览器扩展安装时会列出权限，手机应用也会请求相机、通讯录和定位。AI Agent 反而经常跳过这一步。
原因并不复杂。Agent 的能力来自一串分散配置，而不是一个统一权限接口。编辑器负责一部分，操作系统负责一部分，MCP 服务和项目脚本再补一部分。用户看到的是“帮我改代码”，系统实际执行的可能是读取整个仓库、运行命令并连接外部服务。
这对两类人最直接。
个人开发者可以用 Geiger 做一次工具盘点。发现陌生 Agent、失效配置或权限过宽的服务后，现实动作不是“记住风险”，而是删除不用的配置、撤销令牌、缩小目录范围，并检查相关日志。
企业安全团队则不能把扫描结果直接当合规证据。它最多适合发现未登记工具，随后仍要核对软件来源、配置归属、凭据有效期和真实访问记录。否则一份绿色报告，很容易把“没扫描到”误读成“没有风险”。
这和早期的软件物料清单很像。SBOM 能告诉你软件里有哪些依赖，却不会自动修掉漏洞。名册有价值，执法是另一套系统。
Geiger 自己也要接受同样的审视
这里有个绕不开的问题：为了检查谁能读取本机配置，用户必须先允许 Geiger 读取这些配置。
如果通过 npx 直接运行，执行的还是从软件包仓库获取的第三方代码。方便是真的，供应链风险也是真的。尤其当扫描目标包含用户目录、Agent 配置和凭据线索时，安装前的核验不能省。
更稳妥的做法很具体：
- 核对项目仓库、包名和发布者，避免同名包。
- 固定明确版本，不直接追随最新发布。
- 阅读扫描范围和网络行为说明，确认结果是否离开本机。
- 先在测试环境运行，查看它请求读取哪些目录。
- 对输出做脱敏，不把路径、用户名和服务名称直接贴进公开工单。
- 扫描后撤销闲置令牌，并用系统日志核对高风险项目。
目前真正需要观察的，不是 Geiger 能否生成一份漂亮报告，而是它能否公开、持续地回答几件枯燥的事：支持哪些 Agent 和版本，检测规则如何更新，怎样处理误报与漏报，是否有独立安全审阅，以及发现越权配置后能否给出可执行的修复路径。
“工欲善其事，必先利其器。”但安全工具的锋利，不在于扫得快，而在于边界说得清。Geiger 抓住了一个真实缺口；它若想从新鲜工具变成可信基础设施，还得先把自己放进扫描清单。