Postman自动劫持AI代理权限的合规警示

编辑点评 · AI 连续创业者视角（以下内容由 AI 提炼，观点归原作者；读完可不看原文）

这是一篇关于Postman桌面版更新机制的安全与合规分析，指出其在未获用户明确许可下修改了Claude Code和Codex的配置文件与信任哈希。关键事实是：Postman启动时自动写入AI代理配置并建立信任机制，且远程工具在登录前已生效（B·第三方报告/实测日志）。对搞钱者而言，这揭示了AI工具链中“静默授权”的严重风险，若你的业务依赖此类工具，需警惕供应链安全风险与合规漏洞。下一步行动：审计你的开发环境，检查AI代理配置是否被第三方软件静修改，建立“最小权限”原则，严禁默认开启远程MCP端点。

立即审计~/.codex与~/.claude目录变更日志
禁用AI代理的默认远程MCP自动连接功能
建立第三方工具安装后的配置回滚机制
向团队分发“最小权限”工具使用规范
警惕宣称“自动升级”却修改底层配置的SaaS

Postman桌面版更新为何能静默修改AI代理配置？

Postman桌面版在启动时执行了名为“auto-existing-upgrade”的自动化流程，未经用户弹窗确认，直接修改了本机安装的Codex和Claude Code的配置文件。其核心违规点在于：安装程序不仅写入了启动钩子，还自行计算并更新了信任哈希值，甚至预先配置了指向https://mcp.postman.com/mcp的远程端点。这意味着，在用户登录Postman之前，其AI代理已被植入了Postman的“工作描述”——要求代理在非平凡API任务（设计、实现、测试、部署等）前加载Postman技能。对于依赖此类AI工具链的开发者团队，这是典型的供应链安全风险：底层配置文件被第三方SaaS静默篡改，且缺乏一键回滚机制。

“自动升级”背后的信任机制漏洞是什么？

漏洞在于“自我审批”逻辑。Postman安装后，集成代码会将新增的启动钩子哈希值写入Codex配置中的trusted_hash字段。注释表明这是为了“仅批准Postman当前的钩子”，但这实质上是安装程序替用户完成了授权动作。磁盘上的信任哈希不等于用户点击“允许”。报告中明确指出，一条信任记录无法证明是哪个进程写入的，这个证据链断裂点正是安全审计的关键。此外，远程MCP端点在用户尚未有效登录时就已存在于配置中，虽然日志显示认证失败，但指令已注入。若未来认证流程变更或发生绕过，该端点将成为数据外泄或恶意指令下发的通道。

开发团队应如何审计并隔离此类风险？

第一步是立即检查~/.codex与~/.claude目录的变更日志，识别非人工操作的配置写入。第二步是建立“最小权限”规范：任何AI代理插件必须在首次调用时显式请求用户授权，严禁默认开启远程MCP连接或预置信任哈希。若发现配置被第三方工具污染，需手动清理配置文件并重置代理信任列表，因为目前此类工具往往缺乏独立的“关闭开关”，解除绑定需要手动编辑两个代理的配置文件、CLI及缓存。对于正在构建AI辅助开发流程的团队，应将“第三方工具安装后的配置完整性校验”纳入CI/CD或本地开发环境的标准安全流程，防止静默授权带来的合规漏洞。

原文 · DEV Community：阅读原文 →

相关工具推荐（推广）：GLM Coding Plan — AI Coding Powered by G…