126 篇博文 含有标签「security」

调出你今天早上的 SSO 日志。每一条 Slack 消息、每一个 GitHub PR、每一项日历邀请、每一次 CI 运行、每一条 Jira 评论——它们都显示着与人类手动输入完全相同的信息：一个人的名字、一个会话令牌（session token）、一行绿色的“身份验证成功”。从审计的角度来看，你根本无法分辨哪些行为来自人类，哪些来自人类启动后便置之不理的智能体。这就是“幽灵员工”问题，而且过去 12 个月里上线了智能体的团队几乎都面临这个问题。

导致这一问题的捷径是结构性的，而非疏忽大意。当你将智能体接入工具时，最简单的凭证就是工程师环境中现有的那个——他们的个人访问令牌（personal access token）、OAuth 会话或绑定设备的 SSO Cookie。替代方案则是一项平台级工程：配置一级身份（first-class identity）、在每个下游服务中进行联邦认证、将其接入审计流水线、构建针对每个实例的撤销机制。这些工作无法在一个 Sprint 内完成，也不会出现在功能路线图中。因此，智能体选择了“借用”。

调出你公司的数据分类政策。公开、内部、机密、受限——四个整齐的层级，每一个都映射到一组访问控制和一份批准的存储位置清单。现在问一个该政策从未准备回答的问题：这些层级中，哪些允许以发送给第三方模型 API 的 Token 序列的形式离开公司边界？

答案几乎总是沉默。这并非因为政策本身有误，而是因为它是不完整的。当今使用的每种分类方案都是为一种访问向量设计的，即询问“该员工是否被允许读取这一行？”Prompt 层引入了一个完全不同的向量：一个获得授权的服务读取了该行，将其转换为 Prompt，并将其跨网络传输给一个供应商，而该供应商可能会记录它、在其上进行训练，或将其以明文形式保存三十天。这些都不属于读取权限范畴。这些都不在覆盖范围内。

这就是缺失的一列。在你添加这一列之前，你的数据分类文档只是在自信地宣称一种你实际上并不具备的控制态势。

我本季度交流过的一个平台团队发布了一个封装了 kubectl 并支持英语指令的 Slack 机器人。一名工程师输入了 “清理 staging 中未使用的分支”。这个机器人非常“热心地”删除了 12 个命名空间——其中一个的名字匹配到了子字符串 “branch”，但它恰好托管了移动团队已经使用了一周的长期集成环境。没有任何异常被抛出。机器人发起的每一次调用都是它合法持有的权限。复盘报告无法指出任何违背的访问规则，因为确实没有规则被打破。该机器人完全按照其 IAM 策略允许的操作执行。

Unix 哲学是一种隐藏在审美偏好下的隔离策略。具有窄接口的小型工具意味着任何单个命令的爆炸半径都受到它所接受的谓词和标志 (flags) 的限制。rm -rf 极其危险，因为这是大家的共识；kubectl delete namespace 要求操作者完整输入命名空间名称，而这种手动输入就是一道关卡。最小特权原则之所以容易执行，是因为权限是词法化的：命令的形式告诉了你行动的形式。

随后，封装层开始接受英语。现在，“命令的形式”变成了 LLM 认为它是什么，它就是什么。

你的安全团队拥有公司信用卡上每一项 SaaS 订阅的完整清单、每一个获得管理员授权的 OAuth 应用，以及连接到公司 Wi-Fi 的每一台设备。然而，对于你的高级工程师笔记本电脑上当前绑定到 127.0.0.1 的七个进程，他们却完全视而不见——一个带有长期 Staging API 令牌的“部署助手”，一个订阅了包含客户数据的 Slack 频道的“工单分类器”，以及一个拥有生产分析数据仓库读取权限的“发布说明生成器”。这些都不在供应商名单上。它们不会出现在 SSO 日志中。所有这些都在利用工程师现有的凭据运行，执行着从未经过审批的操作。

这就是影子 MCP（Shadow MCP），它是企业中增长最快的未管理授权面。模型上下文协议（Model Context Protocol）使得将任何工具接入任何 LLM 的成本变得极低，而工程师们——天性使然——首先接入了那些最显而易见的工具。Saviynt 的 CISO AI 风险报告指出，75% 的 CISO 已经发现其生产环境中运行着未经授权的 AI 工具。GitHub MCP 服务器在 2026 年初的周安装量突破了 200 万次。Postgres MCP 服务器允许 LLM 对开发者能接触到的任何数据库执行 SQL 提示词，其周安装量已超过 80 万次。这些数字中没有一个代表企业的 IT 决策。

用户提交了一个 $0.01 的请求。你的智能体读取了一个网页。40 秒后，该次对话的推理账单变成了$42。该查询在技术上是成功的——智能体返回了一个合理的答案。只是为了得到这个答案，它经历了三个嵌套的子智能体、一次 200K token 的文档获取，以及一个递归的计划优化循环。这些扇出（fanout）操作并非用户的本意，而是隐藏在智能体所读取页面中的一句话。

这就是代币放大（token amplification）：一种提示词注入攻击，它不窃取数据，不调用未授权工具，也不会留下明显的安全特征。它只是烧光你的账单。云账单是攻击载荷，而用户的请求则是载体。

“发送邮件”工具和“删除账号”工具被放在了同一个确认弹窗后面。你的用户今天已经点击了 40 次“批准”（Approve），没有一次点击涉及阅读 Diff，而下一次点击——即向生产数据库提交一个不可逆变更的操作——看起来和之前的 40 次完全一样。这就是二元工具审批的失效模式，也是当今几乎所有发布的 Agent 框架的默认设置。

问题的核心框架在于，“需要人工审批”被视为附加在工具上的单个布尔值，而实际上它是一个包含五到六个类别的分类法，取决于工具可能造成的破坏类型以及这种破坏的可恢复程度。那些能够交付安全 Agent 的团队不再询问“这个工具是否需要确认对话框”，而是开始询问“这个工具属于哪种风险类别，以及哪个门槛（gate）对应于该类别”。审批门槛的正确数量既不是一个，也不是很多。它是每个风险类别对应一个，你必须在构建门槛之前先列举这些类别。

read_file 是安全的。send_email 是安全的。你的安全审计对照各自的威胁模型分别批准了它们：对已知目录的只读访问，以及通过带有速率限制和收件人日志记录的已认证中继发送的出站邮件。每一个都通过了，两者都已注册。随后智能体将它们组合在一起，而客服工单中的一行注入文本就将这对组合变成了外泄工具，原有的审计对此根本没有描述这种风险的术语。

危险并不存在于工具图谱的任何节点中，而是在于边。你运行的每次针对单个工具的安全审计都是对顶点的判定；而智能体实际的权限表面是目录中的路径集合，这个集合呈二次方增长，而你的审计流程却只能线性扩展。当你的智能体拥有 15 个注册工具时，你审计了 15 个项，却发布了大约 200 个可达的两步组合，其中没有一个经过人工审核。

用户根据 GDPR 第 17 条提交了删除请求。你的团队删除了 Postgres 中的行，清除了 S3 中的缓存文档，并从 CDN 中轮换掉了缓存的 PDF。搞定。隐私团队签字，安全团队签字，工单关闭。六个月后，一名拥有向量索引读取权限的数据分析工程师为了一项聚类实验提取了一组 float[1536] 数组样本，通过公开可用的反演模型（inversion model）运行这些数据，并重建了原始 32-token 文本块中大约十分之九的内容——包括你已经“删除”的文档。没人预料到这一点。没人怀有恶意。流水线完全按照设计运行，只是威胁模型从未将向量存储视为数据副本。

在我见过的几乎每个 RAG 团队中，这种思维误区都是一致的：嵌入（embeddings）被视为不透明的数值产物——是衍生品，而非数据。安全评估批准上线是因为“嵌入不是 PII（个人身份信息）”。隐私评估批准了删除处理，是因为“源文本已不存在”。这两个团队都错了，谁都没有将向量存储建模为用户数据的第三份副本——它紧挨着源数据库和分析仓库，任何拥有索引读取权限的人都可以查询，且由于没有任何工具能识别出 1536 维的浮点向量属于敏感数据，它完全处于所有 DLP（数据泄露防护）扫描器的范围之外。

当这种情况第一次发生时，值班工程师正盯着已经全红的 Gmail Postmaster 仪表盘，支持信箱因为客户重置密码邮件落入垃圾邮件箱而告急，而导致这一切的智能体（Agent）仍在运行。在当地时间凌晨 4 点到上午 9 点之间，它从公司的主要发送域名发送了 8 万封“个性化跟进邮件”，且全部使用了计费系统所用的同一个 DKIM 密钥签名。等有人注意到时，花费三年建立的域名声誉已毁于一旦，接下来六周内，公司所依赖的每一条事务性消息的收件箱投递率也将随之化为乌有。

从智能体发送邮件看起来就像是一个单行的工具调用。send_email(to, subject, body) 是最经典的演示，每个框架都将其作为入门集成提供。但邮件不同于其他工具。错误的数据库查询可以回滚，错误的 API 调用会返回错误。而一批糟糕的邮件会降低你公司发送的每一封其他邮件的送达率，且持续数周之久。这里没有可以回滚的事务，因为邮件已经发送到了接收方的邮件服务器，而这些服务器正在记录你域名的声誉历史。

我认识的一位后端工程师在一个周二的下午盯着一个从未有过波动的 Datadog 图表：其内部日历服务的单用户 429 计数器。投诉的客户并没有改变他们的行为。他们只是开启了助手功能，现在每当用户说“帮我找下周的时间”时，该功能就会针对同一个日历 API 并行启动八个规划线程。速率限制器（Rate Limiter）——每用户每分钟 60 次请求，这个设置非常合理，是多年前针对一个在物理上无法点击得那么快的 UI 编写的——在每次请求的前三秒内就会触发，并悄无声息地破坏了助手一半的响应。

速率限制不是 Bug。契约才是 Bug。那个后端，就像大多数在 2024 年之前编写的内部服务一样，在每一层都植入了一个悄然执行的假设：一个用户意味着一条活动流，其节奏受限于人类的反应时间，拥有一个 cookie 罐、一个 CSRF 令牌和一套在出现问题时可以重新提示的凭据。Agent 一次性粉碎了所有这五个假设，故障表现为一系列看似无关的事件——429 风暴、“最后写入者胜”（last-write-wins）导致的数据损坏、无法取证的审计日志、挂起无头工作线程的重新认证循环——在模式被命名之前，没有人会将它们联系起来。

我一直与平台团队沟通的一个简短总结是：你拥有的每一个后端都与它的调用者有一个未记录的契约，而那个契约是与人类协商达成的。现在 Agent 出现了，要求重新协商。你可以选择在代码审查中主动进行协商，也可以选择在下一次事故期间被动进行。

第一个内部 LLM 网关的构建通常是出于那些枯燥的原因：成本归因，以便财务可以回答“哪个团队花了推理预算”；速率限制，防止某个失控的脚本烧掉月度配额；以及供应商故障转移，确保 OpenAI 的小故障不会导致助手挂掉。数据泄露防护 (DLP) 虽然出现在幻灯片上，但交付时却变成了“每个应用团队在调用模型前应自行脱敏敏感字段”。六个月后，生产环境中有九个应用，三个维护得半吊子的脱敏库（带有微妙差异的正则表达式集），两个完全绕过网关“仅用于测试”的原型，以及一起 Prompt 中包含客户数据的事故——而这本该是由每个人的中间件来防止的，因为并没有人的中间件是规范的出站口。

这不是工具问题，而是架构错误。DLP 是一种出站控制，而出站控制只有在路径强制执行时才有效。当你让应用团队负责脱敏时，你就放弃了让 DLP 发挥作用的特性——即敏感数据只能从一个地方流出，且你可以证明流出了什么。2025 年的 LayerX 安全报告用大多数团队尚未意识到的数据说明了问题的规模：2025 年初，与生成式 AI (GenAI) 相关的 DLP 事故增加了一倍多，目前占 SaaS 流量中所有数据安全事故的 14%，员工平均每天向 GenAI 工具粘贴 6.8 次内容，其中超过一半包含公司信息。影子路径默认在胜出。

当监管机构第一次要求你证明你的支持代理在 3 月 14 日没有访问某位二级客户的账单记录时，你会发现关于你的鉴权架构的一个令人不悦的事实：系统提示词说“不要访问二级客户的账单”，YAML 工具清单说 tools: [search_orders, refund_order, get_billing]，而在两者之间，模型做出了决定。由于不存在决策点，因此没有决策记录。代理是否做了正确的事是无法审计的，只能从发生的日志中推断。

这是智能体工程中没人画在架构图上的部分。如今的工具权限仍然存在于由创建智能体的人编辑的 YAML 文件中，通过描述意图的系统提示词呈现给模型，并由包裹每个工具调用的应用代码强制执行（如果真的执行了的话），例如 if user.tier == "premium" 检查。随着工具目录超过 50 个条目，且条件在租户、数据类别和用户角色之间成倍增加，这种手动构建的网格便不再具备扩展性，而系统提示词也不再是一个可靠的执行面。模型不是你的鉴权层，即使它的表现看起来像是一个鉴权层。

取而代之的是策略即代码（policy-as-code）：一个专门的策略引擎 —— OPA 配合 Rego、AWS Cedar 或类似的声明式工具 —— 作为策略决策点（Policy Decision Point）位于每个工具调用之前。引擎在每次调用时只回答一个问题：给定这个主体（principal）、这个工具、这些参数和这个上下文，该操作是否被允许？智能体运行时（agent runtime）从未参与投票。这篇文章将探讨这种架构在实践中的样子，以及它所解决的四个即使是提示词工程也无法解决的问题。