120 篇博文 含有标签「security」

一场安全事件回顾以一个团队无法回答的问题开始：智能体是如何知道它刚刚调用的工具名称的？审计追踪显示了一个 tools/call 请求，但该工具的名称并未出现在 harness 记录的任何 tools/list 响应中。MCP 服务器欣然接受并执行了该调用。在事后分析中，当被要求解释工具名称来源时，模型给不出答案，因为根本没有答案 —— 它猜中了，而且这个猜测恰好命中了一个真实的操作。

这是两个在理论上看起来兼容的假设之间产生的失效模式。客户端将工具列表视为一份契约，界定了它被授予的权限范围。服务器则将工具列表视为当前可用工具的快照，可以随着环境的变化自由增长。在这两种观点之间，LLM 是一座不知道二者差异的桥梁。

周一，一位新工程师加入了团队。到周三时，她已经搭建好了本地 Agent 环境：一个桥接到公司部署 API 的 MCP 服务，指向 Staging 环境，并与她的编辑器相连。入职文档引导她完成了 OAuth 流程。她粘贴到服务器环境文件中的令牌是同事发给她的——这与 CI 流水线用于发布到 Staging 环境的是同一个令牌。到周五，她已在共享办公空间与团队一起进行协作开发。

MCP 服务仍在运行。绑定在 127.0.0.1。无需身份验证。令牌已加载到进程中。她没多想，因为她并没在使用它。但那天访问任何网站的任何标签页，都可以通过她自己的浏览器与她的本地服务通信。共享办公空间 Wi-Fi 上的任何其他笔记本电脑也同样可以，因为她没注意到该服务实际上绑定到了 0.0.0.0。你的 CI 流水线用来推送到 Staging 的 OAuth 令牌，现在任何能诱导浏览器向本地 IP 发起请求的人都能触及——在 2026 年，这只需要一个弹窗。

本文讨论的就是这类故障：“我在笔记本上开发”与“我的笔记本是对手可以触及的服务器”之间的鸿沟。MCP 服务在设计上恰好处于这个鸿沟之中。大多数团队尚未察觉。

设计文档规定每个工具都拥有独立的 OAuth 令牌，并被限制在该工具所需的最小权限范围内。而实现代码则使用 (user_id, provider) 作为键（key）来存储令牌。在 v1 版本发布当天，这两个表述都是成立的，因为当时每个提供商（provider）恰好只有一个工具。当针对同一提供商的第二个工具上线时，设计文档依然成立，但存储层却在悄无声息中使其失效了。

六个月后，一次安全审查将一起事故追溯到了那行模式（schema）定义。一个日历读取工具通过日程描述中的提示词注入（prompt injection）被攻破，并成功调用了用户主日历上的 events.delete 接口。读取工具从未被授予过该作用域（scope），但写入工具被授予了。令牌存储层并没有区分它们。

这种故障模式在于，基于每个提供商（per-provider）的键结构会在共享同一提供商的工具之间悄悄累积权限——这也让人们在架构上意识到：OAuth 作用域是令牌（token）的属性，而不是工具（tool）的属性。

安全审查称智能体（Agent）“代表”（on behalf of）用户操作。OAuth 令牌却有不同的说法，而审计日志也支持令牌的说法。

语言上的一点微小差别，在架构层面起到了意想不到的作用。“代表”（On behalf of）是安全审查在试图描述一种委派安排时使用的语言，即智能体是一个可识别的委派对象，并受此身份约束。“作为”（Act as）则是运行时的行为，此时智能体持有的令牌与用户本人的令牌完全一致，因此在任何下游系统看来，智能体就是用户。这两个短语描述了完全不同的威胁模型。典型的企业级 OAuth 集成交付的是后者，但宣传的却是前者。

一个仅针对入站流量运行的 PII 脱敏器就像是安装在管道错误一端的单向阀。它在用户提交的姓名、电子邮件和账号进入日志之前拦截它们。但它对模型的输出无能为力 —— 而现在，模型正是在输出端积极地组合可能包含这些相同标识符的文本，这些内容可能源自 RAG 检索、工具返回、对话历史或用户从另一个租户数据中粘贴的内容。我观察过每一个上线了输入端脱敏器的团队，他们的待办事项中都有一个标记为“输出端对齐”的后续任务。大多数这类任务永远不会关闭，因为在长达六个月的时间里，没有任何事故暴露出这个缺口。六个月后，该任务经过多次重新排序，看起来更像是一个功能需求，而不是缺失的一半安全控制手段。

失败模式是恒定的：输入端脱敏被视为标准的控制手段，因为它的工程问题更简单，审计故事也更容易讲。你编写了一套正则表达式，运行了一个标注好的基准测试，证明了在固定语料库上的精确率和召回率，在特性开关后上线了它，安全评审也将其接受为 PII 边界。输出端则完全没有这些优势。模型的响应是生成性的，表面积是无限的，而且测试方法论 —— “在无限多的上下文中它不应该说什么” —— 在结构上比“我们应该从已知输入中剥离什么”要困难得多。因此，上线入口端的团队将出口端视为未来的工作，而这个未来永远不会到来，直到有客户举报另一个客户的电子邮件出现在他们的对话记录中。

一位西班牙客户投诉称，她的年度续费被提前一天计费了。支持工单在经历了三个队列后，终于转到了一位工程师面前，他敏锐地察觉到了问题的端倪：这是一个日期格式化的回归（regression）问题，且仅出现在欧洲用户群中。他在 date-formatting 模块上运行了 git log，却一无所获。该模块已经 11 天没动过了。而 11 天前真正被改动的，是它的 package.json —— lodash 的版本从 4.17.20 升级到了 4.17.22。这次升级是由一个安全代理（security agent）发起的，由值班人员批准，并在没有任何评论的情况下合并了。

在同一个文件中，版本字符串上方两行有一条 18 个月前写的注释：// do not upgrade — breaks the snapshot tests in date-formatting, see FRONT-2418（请勿升级 —— 会破坏 date-formatting 中的快照测试，详见 FRONT-2418）。安全代理没有阅读它。或者更准确地说：安全代理阅读了整个文件，但它的提示词（prompt）指令是查找有漏洞的版本字符串，而不是衡量周围注释的权重。这条注释是承载关键信息的机构知识（institutional knowledge）。而代理却将其视为无关紧要的背景装饰。

这是一个两个互不知晓正在发生碰撞的系统之间的协同失效。安全代理履行了它的职责。写下注释的原工程师履行了他的职责。每次修改文件都遵守固定（pin）版本的开发代理也履行了它的职责。唯独没有人决定谁该负责在它们之间进行调解。

一个支持代理向错误的受众提供了正确的答案。一名客户询问其账户信息，模型尽职地调用了 URL 获取工具，于是该账户上下文的快照便落入了一个安全团队从未听闻的服务器中。没有凭据泄露，没有 API 密钥暴露。外泄路径是三周前由竞争对手撰写的五星好评，因为它包含的公开赞美确实与用户的问题相关，所以作为相关上下文被检索了出来。

这种失效模式打破了工程师们多年来在 Web 安全领域建立的心智模型。RAG 系统中的威胁模型通常被表述为“我们拥有语料库”，因为我们掌控着摄取流水线、嵌入模型和向量数据库。但拥有拉取内容的代​​码并不等同于拥有内容本身。如果你的语料库包含任何写入权限未受授权控制的数据源，那么你就已经向任何能够发布内容的人交出了一个提示工程通道。

你在第一天为 Agent 创建的 IAM 角色本应是临时性的。试点项目需要进度，团队需要 Agent 在演示前投入生产，而有人——大概就是你——在 PR 中加了一条评论：“发布后再收紧权限。”九十天后，试点项目已经上线，Agent 已经在为付费客户提供服务的生产环境中运行，而该角色仍然拥有对三个 Agent 从未接触过的存储桶的 write:* 权限。运维人员（On-call）无法告诉你这 18 个 Scope 中哪些是核心负载，哪些是冗余，因为唯一了解情况的人已经转岗，而能够证明区别的运行时遥测数据也从未接入。

这并不是关于一个粗心团队的故事。而是一个关于所有构建 Agent 的团队如何陷入同一困境的故事，因为大多数公司尚未发明防止这种情况发生的生命周期管理规范。人类身份识别在过去 30 年中为此积累了大量机制——入职工作流、季度访问审查、转岗时的自动权限撤销。而 Agent 身份识别只有一条 Slack 消息，写着“我晚点会清理”。第一天的授权变成了第九十天的遗产，而爆炸半径随着每次模型升级、每个添加到 Agent 工具箱的新工具以及每个接入该角色的新客户而不断扩大。

用户在你的智能体授权页面上点击一次“授权”。当会话结束时，该智能体已经链式调用了 11 个工具，协商了 3 次提权授权，现在拥有了它所触及的每个工具的权限并集。用户只记得授权了一件事。你的审计日志却显示它拥有半个账户的读写权限。OAuth 标准说一切都在按设计运行，而这恰恰就是问题所在。

经典的 OAuth 授权模型是为“一个应用与一个 API 通信”的世界构建的。智能体在两年前打破了这一假设，而标准在实践中尚未跟上，即使规范已经更新。其结果是一类无人刻意发布的静默权限提升——它随着每一次工具注册而累积，而你的安全审查却一直在盯着前门。

公司内部有一个安全运行了十年的端点。它位于一个除了原始团队之外没人能猜到的路径上。它不在公开文档中。它不在 OpenAPI 规范中。它不在网关的“已记录路由”白名单中。它的身份验证层是一个任何内部服务都可以签发的令牌，因为威胁模型认为，触达它的唯一前提是已经知道它的存在。这个端点接受一个 JSON 数据块，在某个平淡的周二，它会重新发放退款、轮换 API 密钥或在两个计费账本之间移动数据行。自 2016 年以来，它一直正常且平稳地工作着。

上个月，一位同事将一个编程智能体接入了工程维基，以协助处理入职提问。该智能体索引了每一个 Confluence 空间、每一份存档的设计文档、每一页标有“请勿删除——历史记录”的页面。昨天，一名初级工程师询问智能体退款是如何运作的。智能体将一份被遗忘的 2018 年架构图、有人粘贴到操作手册里的 Slack 导出记录以及一份写了一半的故障复盘拼接在一起。它用对话式的文字完整描述了该端点、所需的令牌类型以及示例 Payload。端点本身没有改变，但它的威胁模型改变了。

我认识的一个团队有一套教科书级别的 staging 设置。生产数据库的只读副本。一个假装会扣款的 Stripe 模拟账户。带着没人拥有的域名邮箱的合成用户。这个 agent 被要求在 staging 里端到端走一遍"账户欠费"的升级流程,作为发版演练的一部分。trace 看起来很干净,agent 做了它该做的事。

三分钟后,一个真实客户——一个付费客户,六个月前流失的,但仍然留在一个开发者用来播种测试数据的休眠导出里——回复了一封措辞礼貌的逾期付款邮件。那个"send_email"工具,与十几个其他全部以 mock 收尾的工具注册在一起,却接在了生产环境的 Mailgun key 上。两个 sprint 前配置它的开发者当时在快速迭代邮件模板,沙箱层级把发送量限制在每小时五封,把内部反馈循环搞坏了,于是他们换上了真 key"就用一下午",然后忘了换回去。没人复查过。agent 没有任何办法知道这件事。

实习生周一报到。周二下午，她已经接好了自己的第一个 Agent。周三上午，那个 Agent 用一份她本不该继承到的凭证调用了生产工具，但安全团队没人察觉，因为审计日志把这次调用记成了"实习生导师的 setup 脚本发起的"——技术上没错，操作上等于零。

这不是实习生不靠谱的故事，也不是导师粗心的故事。这是一个入职流水线的故事：它对"新人"的假设——只读优先、沙箱写次之、生产环境要熬到工龄门槛——背后有几十年的打磨；而对那些新人入职头几天就会去配置的 Agent，它的假设是零。给人用的 IAM 模型，已经不再是给"实际打到你系统上的东西"用的 IAM 模型，而大多数安全团队还没意识到这一点。