AI 智能体安全的第一原则：你的 AI 智能体永远不应持有你的凭证。以下是强制执行这一原则的中间人模式——它已有38年历史。
AI 智能体是"混乱的代理人"。这是一个有着38年历史的安全模式，而解决方案同样古老：在智能体与其需要调用的 SaaS API 之间放置一个中间人——一个可信、可观测、确定性、可审计、不可伪造、范围受限、策略驱动、非 AI 的中间层——由它持有智能体不应拥有的凭证。
1988年，Norm Hardy 发表了一篇短文，描述了他在 Tymshare 工作期间的一次真实事件。一个名为 FORT 的 Fortran 编译器位于名为 SYSX 的系统目录中。为了收集使用统计数据，编译器需要写入 (SYSX)STAT，因此操作系统授予了 FORT 一个"主目录文件许可"，允许它写入 SYSX 内的任何文件。系统的计费文件 (SYSX)BILL 也存放在那里。用户调用编译器时可以提供一个文件名，用于接收可选的调试输出。某天，一个用户提供了 (SYSX)BILL。编译器请求操作系统打开该文件进行写入；操作系统看到主目录文件许可，便允许了。计费数据被覆盖。编译器做的正是它被设计来做的事。缺陷在于架构本身。
Hardy 将其命名为混乱的代理人问题：一个拥有特权的程序（代理人）持有自身的权限；一个权限较低的调用者请求它执行某项操作；代理人对自己究竟在代表谁的权限行事产生了混淆，并使用了自己的权限。解决方法是将该权限完全从代理人身上移除，放到一个按需调解调用的独立层之后。这一层就是中间人。
三十八年后，你公司运行的每一个 AI 智能体都是一个混乱的代理人。而其中大多数都在没有中间人的情况下运行。
为什么 AI 智能体让安全问题更加严峻
Hardy 的 FORT 只有一个输入通道：命令行。而现代 AI 智能体有数十个：邮件正文、检索到的网页、上传的 PDF、来自 MCP 服务器的工具输出、多智能体系统中其他智能体的消息。任何进入上下文窗口的内容都可以发出指令，而智能体在设计上会将它们全部视为合法指令。
这打破了传统访问控制所依赖的一个假设：调用者控制输入。在 Web 应用中，调用者（已认证的会话）和输入（HTTP 请求体）来自同一个地方。对于智能体而言，调用者是塑造提示词的人，这意味着能够撰写一封邮件或植入一条搜索结果的攻击者，同样也是调用者。
2025年11月，PromptArmor 的安全研究人员展示了这在生产环境中的实际样貌。他们将恶意指令以1像素字体隐藏在一份集成指南中。当一名开发者将 Google 的 Antigravity IDE 指向该文档时，智能体通过调用 cat 命令绕过了自身基于 .gitignore 的文件保护机制，随后通过 Antigravity 自带的浏览器子智能体，将 .env 文件的内容泄露到攻击者控制的 webhook.site URL。用户的配置完全正确，沙箱也正常运行。智能体只是无法区分用户的请求与输入指令它执行的操作。
几十年后，同样的模式再次上演：宽泛的权限、不可信的输入、无法将两者分离。
社区已有答案，只是分散各处
这并非新问题。安全社区数十年来一直在撰写解决方案：
基于能力的安全（Dennis & Van Horn，1966年；后来的 E 语言以及 Mark Miller 在 Google 的 Caja 工作）。核心原则：不要基于身份或位置授予环境权限；为程序允许访问的每个资源传递明确的、不可伪造的能力。一个能力将你能做什么与你能对什么做捆绑在一起，且不会与其他任何东西混淆。
凭证中间人模式（由 OWASP LLM Top 10 规范化）。不要将 API 令牌放入 LLM 的上下文中。由一个可信的中间层代表智能体发起调用；模型决定做什么，中间人处理怎么做。通过提示词注入要求模型打印其凭证的攻击将一无所获，因为凭证根本不在那里。
幻影令牌模式（Curity，最初用于微服务中的 OAuth）。智能体持有一个不透明的会话句柄，而非真实的持有者令牌。代理在网络边缘验证该句柄，将其替换为真实凭证后再转发至上游。即使智能体泄露了其环境变量，攻击者得到的也只是一个在会话结束时过期的字符串。
即时凭证注入（工作负载身份系统，如 Aembit）。为每次调用生成一个短期、范围受限的凭证，而非颁发长期令牌。
这些内容在文献中并不缺失，缺失的是默认实践。大多数智能体平台仍然直接将 OAuth 令牌交给模型，中间没有任何中间人，只是抱着侥幸心理。
Zero 的中间人如何运作
上述模式并非我们的发明。我们将它们整合进一个单一的中间人，该中间人在 Zero 上对每个智能体默认运行。它就是这些模式所描述的可信中间层，专为 AI 智能体平台构建。智能体对连接器发起的每一次调用都经过它。每个连接器对应一个外部 SaaS（Slack、GitHub、Notion 等）。
中间人位于每个智能体与每个连接器之间。真实凭证仅存在于虚线的中间人一侧。
可以将其理解为三个层次。
1. 凭证隔离
智能体的沙箱从不持有真实的连接器凭证。当你将一个 SaaS 连接到 Zero 时，OAuth 令牌或 API 密钥存放在中间人一侧。沙箱获得的是一个占位符字符串，它看起来足够像一个环境密钥，使现有工具能够正常工作，但任何上游 SaaS 都不会接受它。
当智能体向已注册的连接器主机发起请求时，中间人匹配该请求，解析连接器的认证模板，并在网络边缘注入真实凭证。请求以有效的认证信息发往上游；智能体从未持有任何有用的内容。一个被提示词注入的智能体转储其环境变量时，攻击者得到的是占位符，而非 SaaS 令牌。
这就是幻影令牌模式，应用于 AI 智能体。
2. 连接器策略门控
Zero 中的连接器应该不止是一个开关。每个连接器描述其覆盖的 API 基础路径以及认证应如何注入。当上游服务发布了稳定的范围到端点映射时，它还可以描述哪个命名权限覆盖每个方法和路径。Slack 的 slack-api-ref 就是一个很好的例子。
因此，当连接到 Slack 的智能体调用 chat.postMessage 时，中间人可以将该请求映射到 chat:write。当它读取审计日志时，对应的是 admin.analytics:read。对于每个智能体，permission_policies 定义了这些命名权限的行为：允许、拒绝或询问。策略在认证注入之前由中间人强制执行，而非作为对模型的提示。如果智能体尝试发起一个被拒绝权限覆盖的调用——也许是因为它被提示词注入了——该调用永远不会到达上游网络。
目前并非每个连接器都能实现这种精细解析。部分上游 API 没有发布稳定的范围到端点映射。GitHub 的 GraphQL 接口就是典型案例：REST 侧可以映射，但 GraphQL 侧目前还不行。对于这些连接器，中间人仍然控制凭证注入和网络路径，而权限门控则退回到平台实际能够执行的更粗粒度的连接器或主机级策略。随着上游数据的完善，我们会逐步填补这些空白。我们不会声称尚未构建的覆盖范围。
令牌不携带环境权限。权限按智能体通过中间人进行授权，精细程度取决于上游支持的级别。这就是答案中基于能力的那一半。
3. 操作循环与审计
最小权限只有在失败模式可用的情况下才能发挥作用。智能体会成长。六周后，一个最初只从 Notion 读取内容的研究智能体可能需要将摘要写回去。其他平台常见的失败模式是：智能体在没有新权限的情况下静默运行并崩溃，或者运营者在慌乱中过度授权，之后再也没有收回。
被拒绝的连接器请求会返回一个结构化的 403 响应：连接器、方法、路径、基础 URL，以及中间人能够识别时对应的权限名称。智能体的系统提示告诉它如何诊断拒绝原因，以及如何请求它刚刚触发的确切权限，并为用户或管理员生成一个一键授权 URL。这使权限升级路径与被请求的确切权限绑定，而不会演变成"直接授予所有权限"。
权限变更请求会进入队列。所有者和管理员可以从控制台批准或拒绝；批准后的请求会更新智能体的策略，下次重试即可通过。大多数平台跳过了这个循环。没有它，"最小权限"就只会停留在幻灯片上，而无法在生产环境中运行。
同一中间人路径也为审计提供数据。每次运行的网络日志记录沙箱的网络活动，涵盖 HTTP、TCP、DNS 以及针对非 TCP 流量的更底层数据包观测。连接器匹配的请求包含结构化的中间人元数据：连接器、可用时的匹配权限、允许/拒绝结果、认证解析元数据以及计费标志。如果有人事后问"这个智能体周二下午3点做了什么？"，你可以从这些记录中重建答案。预防措施会有遗漏，审计追踪是你发现问题的方式。
我们尚未解决的问题
即便有了上述所有措施，一个拥有合法 chat:write 权限的智能体仍然可能被诱导向它已有访问权限的频道发布令人尴尬的消息。中间人缩小了爆炸半径，但并不能消除它。
答案的另一半是高风险操作审批、输出验证，以及默认将工具返回值视为不可信内容。这些工作在路线图上，尚未进入产品。任何声称已端到端解决混乱代理人问题的人，都是在向你推销什么。
这应该是底线，而非特性
基于能力的安全自1970年代就已存在。凭证中间人模式已列入 OWASP LLM Top 10。幻影令牌早于 LLM 时代。这些内容的缺失，不是因为没人知道答案，而是因为早期智能体平台优先考虑"让演示跑起来"，将安全推迟到后续版本，而那个版本往往从未到来。
下一代平台应该追求更高的标准。令牌不应进入模型上下文。权限应按智能体逐一列举。权限升级应经过人工审批。每个操作都应可端到端审计。这些都不是新鲜事，但都应该成为基准。
在选择智能体平台时，"它安全吗？"这个问题毫无意义——每家供应商都会说"是"。更好的问题是：给我看看你的中间人，并带我了解当智能体请求一个它没有的范围时会发生什么。
中间人默认位于 Zero 上每个智能体的前端。连接器清单、范围映射、权限策略和中间人逻辑均存放在 Zero 的源代码仓库 中。发现我们尚未覆盖的连接器？请提交 issue。
参考资料
基础文献
- Norm Hardy，The Confused Deputy: (or why capabilities might have been invented)，ACM SIGOPS Operating Systems Review 22(4)，1988年。DOI 10.1145/54289.871709
- Dennis & Van Horn，Programming Semantics for Multiprogrammed Computations，CACM 1966年（能力系统的奠基论文）
- Mark Miller 等，Caja：面向 Web 的基于能力的安全，Google
- OWASP LLM Top 10
- Curity，幻影令牌模式
引用的真实事件
- PromptArmor，Google Antigravity Exfiltrates Data，2025年11月
- Simon Willison，报道与分析，2025年11月25日
