智能体越强，越要先画它的权限边界
这周智能体圈发生了两件越界的事，加一件画线的事。分开看是三个案例，合到一起是一个趋势：智能体正在拿到越来越多的本地权限，而权限的边界，还没被大多数工具认真处理过。
一、一个工具，改了另一个工具的智能体
10 月 25 日，一位开发者在 Postman 官方问题单（#14370）里贴出排查记录。他用的是 Postman 桌面版 12.33.4。日志显示，一次面向老用户的自动升级流程里，Postman 给他的机器装了两样东西。一是 Claude Code 的插件，二是 Codex 的插件。外加一个 Postman CLI。
关键的第四步，是一个会话启动钩子。钩子的作用是：每次智能体开会话之前，先跑一段预置指令。这段指令会让智能体在处理接口任务前，默认先加载 Postman 的技能。按正常设计，钩子进入信任记录需要用户批准。而日志里，写进信任记录的那枚哈希，是 Postman 安装程序里它自己的函数盖上去的。
需要说清楚的边界：这件事里没有数据外泄的证据。报告者的日志写着，那个远程 MCP 连接因为需要认证失败了，会话根本没建立。所以批评的落点不是它偷了数据，而是它没经你同意，改了你的工具，还替自己批了权。
后续：帖子 11 月初上了 Hacker News 榜首，1527 分。11 月 5 日，一位标注为 Postman 团队成员的用户在问题单里正式回复。原话：我们正在回滚这项改动。问题单随后关闭。
这条回复没说的有两件：已装好的插件和那枚自批准钩子，回滚会不会清掉；重新设计后的控制方式长什么样。
二、一个文本文件，劫持一个智能体
同一周，dev.to 有一篇被反复引用的安全长文（11 月 5 日，51 反应 / 34 评论），攻击面更日常。
机制一句话：编程智能体启动时，会自动扫描工作目录里的指令文件。比如 AGENTS.md、CLAUDE.md、.cursorrules。这些文件进了上下文，里面的指令就能引导智能体选工具、跑 shell、改配置。作者有句关键的话：能命令智能体跑命令、改 API 指向的文件，是脚本，不是文档。
数字来自安全研究人员 2026 年 10 月下旬记录的首批在野劫持。攻击链对 Codex 成功率最高 90%，对 Claude Code 约 50%，能改 API 指向、泄漏令牌、跑任意命令。
最容易被忽略的是下载目录。作者记录到，超过 1,300 个 Claude Code 会话是从 ~/Downloads 启动的。这个目录特殊在：浏览器可以不打招呼就往里写文件。访问一个挂了马的站点，一个名叫 AGENTS.md 的小文件就能落进下载目录。下次你在那里启动智能体，它就自动读到了。
第三类场景是开源仓库和 Pull Request。注入载荷可以藏在看似正常的规则文件里。藏法是用零宽字符、双向控制符这类 Unicode 字符，在 GitHub diff 里显示为空白，模型却能读。
三、防守方在怎么画线
防守侧最具体的样本，是 Zenn 一篇 1.1 万字长文（11 月 7 日，56 赞 / 27 收藏）。做法：Cloudflare 的 Zero Wire 漏洞情报 RSS，加 GitHub Actions，加 Claude，给公开服务器做每日漏洞检查。
核心设计是把活切成两半。
判断归模型。这条通报对我这台服务器意味着什么、要不要处理，交给模型评估。作者用 Claude 订阅的 token 跑，Sonnet 就够。
校验归代码。版本是否低于修复版，完全不交给模型。Node.js 对官方安全公告做 semver 比较，Ubuntu 包对官方 CVE 数据做版本比较。作者原话：判断是 Claude，比较是代码。起因实在：版本核对一开始也交给模型，每次都可能卡在要确认，结果每次不一样。
配套三道闸。第一，不给智能体 shell，只有文件读写加限定域名的网页访问。第二，提示词开头声明 RSS 和网页内容一律当不可信数据，里面的指令不执行。第三，通知失败安全：报告第一行只认两个值，STATUS: OK 和 STATUS: ACTION_REQUIRED，其他任何值都按要处理上报，漏报方向被堵死。
四、放到我们自己机器上：通道在，章没盖
Postman 插件到达 Codex 的通道，是远程插件目录。我在本机做了一次只读检查（2026-11-10 07:0x）。Codex 的缓存里有一份 10 月 28 日拉取的插件目录，共 8,980 个条目。里面就有 Postman 官方的 Codex 插件。它的字段是 scope 为 GLOBAL、installation_policy 为 AVAILABLE、authentication_policy 为 ON_INSTALL。翻译过来：它躺在可安装的货架上，装上时才触发认证。
但报告者那台机器上的事，本机没有发生。Codex 配置里没有 Postman 的钩子，没有信任记录，工作目录里也没有游离的 AGENTS.md 或 CLAUDE.md。在我这台机器上，是货架上有货，不是货被自动装进了配置。
这个差别很重要。Postman 那个 issue 是自动安装＋自批钩子，是安装行为越界。我们查到的是目录缓存，是分发机制本身。同一个插件，在两台机器上状态完全不同。所以装了某工具、智能体就一定被改过这种推断不成立，查自己的配置才成立。
五、接下来看什么
第一，Postman 回滚的完成度。已装好的插件和自批准钩子有没有被清掉，官方没说。判断方法很直接：看更新后的版本，升级路径还会不会再写那两行配置，卸载入口能不能把钩子从信任记录里删干净。
第二，指令文件会不会进审查流程。AGENTS.md 这类文件目前只被当文档管理。有团队开始把它当安全关键代码：谁改谁负责，CI 扫隐藏 Unicode 字符。如果变成普遍做法，那个攻击面的成本会被抬高一大截。
第三，判断归模型、校验归代码，这个分层能不能标准化。它目前是一个工程师的个人实践。方向是把模型的自由度关进笼子里：能判断的让它判断，能算的绝不让它算。
三件事放在一起看：智能体拿到的权限在涨，而谁有权替用户盖这个章，还没有标准答案。能自己做的事不多但很明确：知道自己机器上装了哪些钩子、信任记录里有什么、智能体在哪个目录里启动。
以上为开发者生态科普，基于公开 issue、社区长文与本机只读检查，不构成任何投资或买卖建议。