126 篇博文 含有标签「security」

Agent 事故发生后的第一个小时总是相似的。有人注意到 Agent 做了一些不该做的事情——给错误的客户开了发票，删除了 CEO 的日历事件，或者在公开的 Slack 频道发布了一段写了一半的道歉信——随后响应团队开始询问一些没人写下答案的问题。哪个下游系统持有审计日志？哪个值班轮换组负责该系统？该调用是否可逆，窗口期是多久？Agent 使用的凭证归谁所有，该凭证是否还允许它触及我们尚未检查的其他系统？编写 Agent 的团队很少掌握这些答案，因为答案存在于 Agent 调用的系统中，而且在发布时没人把它们统一记录在一个地方。

这份文档就是爆炸半径清单 (blast radius inventory)，它是大多数 Agent 团队在第一次事故中才发现缺失的产物。它不是安全检查表，不是工具 schema，也不是操作手册 (runbook)。它是 Agent 可以触及的每个外部系统的详尽列表，以及在该系统遭遇最糟糕状况时你所需的每一项事实。那些在没有这份清单的情况下发布 Agent 的团队，是在赌事故响应的上下文重构速度能超过爆炸蔓延的速度。随着 Agent 拥有的工具越来越多且功能越来越强大，这场赌局的胜算正变得越来越低。

用户要求智能体（agent）“告知 Karen 我们完成了”。智能体调用了 send_email，收件人字段设置为 karen-team@，这是它的联系人查询工具返回的最合理的地址。这条包含三段内部专用项目状态的信息——其中包括一行关于客户续约风险的坦率描述——最终发送到了四十个收件箱。其中一个收件箱恰好属于该客户。事后分析（postmortem）持续了两周。

没有提示词注入。没有模型越狱。工具完全按照规范运行。团队为 send_email 编写的契约是“向收件人发送消息”。而现实世界强制执行的契约是“广播给一个发送者未审计其构成的群体”。这种差距——即工具的命名与其核心实际能力之间的鸿沟——正是大多数出站智能体事故的源头。

电子邮件是显而易见的例子，但同样的风险潜伏在智能体接触的每一个消息工具中。人类为这些渠道建立的三十年肌肉记忆，并未转移到那些正在通过联系人列表进行模式匹配的规划器（planner）中。

90% 的公司员工都在使用个人 AI 账号——ChatGPT、Claude、Gemini——来完成工作，而其中 73.8% 的账号是非企业性质的。与此同时，57% 使用未经批准的 AI 工具的员工正在与其共享敏感信息：客户数据、内部文档、代码、法律草案。大多数高管认为他们的政策可以防止这种情况发生。但数据表明，实际上只有 14.4% 的团队部署的 AI 获得了全面的安全批准。

领导层认为正在发生的事情与实际发生的事情之间的差距，就是影子 AI 治理问题。

大多数公司的本能反应是下达禁令。在网络层面封禁个人聊天机器人账号、发布政策备忘录、进行年度培训，并称之为治理。这是最糟糕的应对方式——不是因为担忧是错误的，而是因为这种干预措施在没有缩小问题的同时，反而让问题变得不可见。

这里的数学逻辑很简单，但没人去算。在 AI 时代之前，单个用户操作（例如“总结这张工单”或“发送这封邮件”）只会产生一行应用程序日志。而在 AI 时代之后，同样的操作会产生一条请求日志、一个 LLM 调用追踪、代理调用的每个工具的工具调用 span、它读取的每个数据块的检索 span、一条响应日志，如果你采样进行离线评分，还会产生一条评估日志。一次用户点击的扇出（fan-out）现在会在你的可观测性流水线中产生 30 到 50 条记录，这还是在重试、子代理以及会让一切翻倍的规划器-执行器（planner-executor）拆分出现之前。

你在第一季度发布了一个 AI 功能。到了第二季度，你的安全总监拿着一份比上一个周期高出 4 倍的 Splunk 续订合同走进预算审查会议。AI 团队的人都不在现场。接下来的对话——关于谁来承担这笔费用、为什么威胁检测规则失效了，以及是否真的必须对每次对话进行法律保留（legal hold）——是你在设计阶段就应该进行但没有进行的对话，因为这笔成本没有出现在 LLM 的发票上。它出现在下游，出现在一个 AI 团队从未登录过的工具中。

你的 Agent 代码库中最危险的文件是你一直当作 API 文档来编写的那个。工具注册表（Tool Registry）——即告诉模型存在哪些函数以及它们接受哪些参数的 JSON 或 Pydantic schema —— 不再仅仅是一个 docstring。它是你的授权层（authorization layer）。如果你像大多数团队那样设计它，你就是把万能钥匙交给了大模型（LLM），并称之为优秀的工程设计。

考虑一个典型的工具初步尝试：query_database(sql: string)。初衷是合理的 —— 让模型根据用户的问题制定正确的 SQL。现实情况是，模型现在成了一个不受信任的客户端，拥有连接字符串所指向的任何数据库的无限 DDL 和 DML 权限。系统提示词说“仅在 orders 表上运行 SELECT” 只是一个建议，而不是控制手段。当一个受到提示注入（prompt-injected）的工具结果 —— 比如邮件正文、网页或 PDF —— 告诉模型运行 DROP TABLE users 时，你的授权模型就变成了对模型指令遵循能力的纪律要求。那不是授权。那是祈祷。

Bearer Token 模型有一个智能体正在悄然违反的假设：调用者在发起请求时知道自己想要什么。OAuth 作用域、IAM 角色和 API 密钥都是围绕一个在身份验证开始前意图就已经确定的主体设计的。你的 CI 运行器意图稳定。你的微服务意图稳定。智能体则不然。智能体的意图是在请求时，由用户提示词、系统提示词、检索到的文档以及可能由攻击者编写的工具输出共同组装而成的。当智能体去获取令牌时，IAM 层必须做的策略决策实际上已经做出了——而决策依据的输入，IAM 层从未见过。

这就是为什么在服务间通信中行之有效的身份验证模式，现在正引发一类没人能准确描述的事故。提示词注入窃取了长效的 Bearer Token。智能体在不同会话间“记住”了权限，因为令牌的寿命超过了用户的意图。一个理应需要三个作用域的多步任务，在整个会话期间都持有所有权限，而不是按步骤获取和释放。严格来说，这些都不是 OAuth 的 bug。它们是试图将假设静态意图的模型扩展到覆盖一个每轮对话都在重构意图的调用者所导致的后果。

云端 AI 的策略通常建立在一个没有人明确写下来的前提之上：出站 HTTPS (outbound HTTPS)。厂商 API、托管评测器、遥测流水线、模型注册表、向量存储、仪表板 SaaS、密钥管理器——其中的每一个都静默地解析到公网上的一个域名。一旦拔掉这根电缆，整个技术栈并不会优雅降级，而是会直接崩溃。

大多数团队直到那一刻才会发现，他们的架构中存在从未考虑过的出站依赖。一个“微小”的提示词更新可能需要调用托管分类器；评估套件需要通过网络访问 LLM 评测器；可观测性代理会向后端发送数据；模型注册表从 CDN 拉取权重。这些都不是恶意的，也并不罕见。当你忽视了那根电缆时，云原生技术栈本就是这个样子的。

安全部门花了十年时间才彻底终结了“全能服务账号”。分限令牌、短期凭据、JIT 访问、逐操作审计——这整套最小权限方案终于落地并稳固下来。然而，AI 团队接入了一个智能体，提示词要求提供工具目录，于是工程师请求了平台所能发放的最广泛的 OAuth 作用域。已被弃用的模式换了一身新衣服又回来了，而这次调用 API 的主体是一个没人确定该如何限定作用域的随机循环。

这个智能体拥有日历、文件存储、CRM 和部署流水线的读写权限，因为 API 表面无法预先枚举。令牌是长效的，因为没人接入刷新路径。审计日志记录的是持有者，而非具体操作。IAM 负责管理人类和服务的身份，平台团队负责工作负载身份，AI 团队负责智能体的实际权限，而这三方集合的交集却无人管辖。

每个智能体产品的安全仪表盘上都应该有一个数字，但几乎没人追踪它：随时间推移的人均批准率。发布一个“我可以发送这封邮件吗”或“我可以针对生产环境运行此查询吗”的权限提示，其曲线每次都如出一辙。第一天，用户会犹豫、阅读，有时会点击“不”。到了第二周，这已经是本小时内的第五次提示，拒绝的代价是必须由你亲自完成工作，于是点击率会收敛到 95% 以上。团队的安全叙事仍然声称用户批准了每一项操作。但在任何实质性的认知层面上，用户并没有。

这不是一个可以通过更好的文案来修复的 UX 问题。这是使 Cookie 横幅、浏览器 SSL 警告和 Windows UAC 对话框失效的同一种习惯化现象，只是应用在了一个运行速度比以往快几个数量级的底座上。许可门槛是一种具有半衰期的安全控制。如果在发布时不衡量它的衰减速度，你发布的只是一个用户到第二周就会习惯性忽略的复选框 —— 以及一个依赖于不再具有任何意义的点击的合规叙事。

隐私审计员在 SOC 2 续期前两天提出了一个问题：“为什么你入门引导提示词示例中的电子邮件字段是一个真实客户的地址？”产品团队在脑海中回溯了整个流程。一年前，当他们发布 AI 摘要功能时，有人需要为 few-shot 模板找一个“看看它是如何工作的”示例。他们从预发布环境（staging）中选取了一条具有代表性的客户记录，清理了明显的字段——姓名、账户 ID、电话——并提交了文件。该客户在六个月后流失了。根据数据保留政策，他们的记录已从数据库中删除。但该记录并没有从提示词模板中删除，而该模板已发布到了生产环境中的每一个租户。

团队曾像大多数团队一样，认为隐私边界就是数据库。提示词模板是代码。代码要经过评审。评审并不会标记 PII（个人身份信息），因为评审人员不会在标记为 example_input: 的 YAML 字符串中寻找它。能在 Slack 消息和邮件附件中捕捉 PII 的 DLP（数据泄露防护）扫描器不会扫描提交的代码，即使扫描，它也不会将部分清理过的客户记录识别为个人数据，因为它知道要查找的字段已被移除。剩下的所有内容——公司规模、行业、稀有的职位名称、特定的城市——都是扫描器没有规则去处理的数据。

你两年前发布的 API 是为单一类别的调用者设计的：浏览器或移动客户端背后的人，点击一次，然后等待响应。现在，大约一半的关键端点上，这个假设都是错误的。另一半流量是智能体（Agents）——你自己的、你客户的，或者是将你的端点作为工具使用的第三方集成——它们具有不同的运行逻辑。它们会产生爆发式流量。它们会无限重试。它们会并行处理。它们会逐字解析错误字符串。它们代表人类行事，而当出现问题时，人类无法即时提供意图说明。

今年出现在复盘报告（postmortems）中的大多数生产环境异常，都可以追溯到一个架构错误：将这两类调用者视为同一种类别。为人类步调设置的频率限制（Rate limits）会被智能体的并行扇出瞬间击穿。为人类可读而设计的错误消息，会被一个在 400 错误上无限重试的智能体解析错误。人类默认会满足的幂等性假设，在智能体从恢复的检查点重试相同的负载时会被打破。身份验证日志失去了区分“用户执行了此操作”与“用户的智能体代表用户执行了此操作”的能力。

解决方法不是更智能的 WAF 或更大的频率限制桶。而是一种深思熟虑的 API 设计，它定义了两类调用者，将它们的流量视为不同的形态，并记录委托链，以便在间接层级中保持可追溯性。

我合作过的一个团队在周三下午发布了一个“微小的提示词调整”。同一个 PR 还向智能体注册中心添加了一个新工具——一个对内部管理 API 的便利封装，提示词现在偶尔会调用它。评估套件通过了。金丝雀发布看起来也很正常。到周四早上，由于智能体处理了一个包含提示词注入攻击的支持工单，一名客户的计费记录被修改了。审计追踪显示，管理工具完全按照设计运行。值班工程师的第一反应——回滚提示词——毫无用处，因为凭证已经使用，数据行已经写入。

复盘报告将其定性为安全审查失败。其实不是。这是发布流水线的失败。团队通过相同的审查、相同的关卡和相同的回滚逻辑，发布了两个完全不同的资产类别——对模型的行为引导和授予智能体的新权限，就好像它们是同一种变更一样。它们并不是。一旦你将它们视为两个流水线，大多数关于“智能体治理”的争论就会变得清晰得多。