CTO 已拨款但安全团队拒绝让你上线的 AI 功能

事后分析报告（post-mortem）会说“我们发现安全问题太晚了”。但实际的调查结果应该是：安全团队发现你的时间很准时，是你的流程发现安全问题太晚了。

这是一个在 1 月份就通过了预算审批的 AI 功能，因为 CTO 和 CFO 都认为公司需要一个“AI 高光时刻”。3 月份它通过了初步的法务审查，因为当时还只是一个原型。整个第二季度，工程团队都按照商定的规范进行开发。7 月底，发布前的安全审查启动了，结果第一天威胁模型（threat model）就反馈了阻碍性问题：身份验证范围（auth scopes）、数据泄露路径、模型供应商的数据驻留（residency）政策，以及提示词注入（prompt-injection）的攻击面。团队整个季度的时间现在都花在了重新架构上，以解决那些本该在最初规范中就被明确的问题。两个季度的进度延迟，一份关于“流程改进”的高管备忘录，以及在下一个规划周期中悄然决定“降低 AI 深度集成的优先级”。

发布失败并不是因为安全团队动作慢，而是因为安全团队在功能形态已经固化之后才介入。

无人察觉的形状约束

AI 功能的威胁模型不是你在最后盖个章的检查清单。它是一种形状约束（shape constraint）。它决定了该功能到底能做成什么样。

以一个能读取工单、查询内部知识库并向用户发送回复草稿的客户支持代理（agent）为例。产品需求文档（PRD）用一段话描述了这一用户旅程。而安全威胁模型则描述了一个完全不同的产物：该代理的服务账户拥有哪些权限范围？用户的工单是否包含代理会当作命令执行的指令？知识库返回的文档中是否有代理应该拒绝转发的内容？供应商的推理端点是否会保留客户数据？邮件草稿是否需要人工审核环节？

这些问题并不是在完善 PRD，而是在约束它。身份验证范围决定了代理可以使用哪些工具。数据外泄模型决定了代理是否能从一个租户读取自由文本并写入另一个租户。供应商的数据驻留姿态决定了欧盟客户是否能使用该功能。提示词注入攻击面决定了发送邮件步骤是自动发送还是必须经过人工审核。

如果你在没有解决这些约束的情况下签署了一份写着“代理将草稿发送给用户”的 PRD，你并没有在设计功能。你只是在写下一个愿望，而你实际能发布的产品的形状，最终会被别人在稍后根据你的时间表发现。

为什么“轻量级原型审查”是个陷阱

非 AI 功能在设计文档阶段都会通过轻量级的架构审查。新的支付路径会有安全架构师把关。新的身份验证集成会有 30 分钟的威胁建模。新的管理端点会快速检查 IDOR 风险。没有人抱怨，因为大家都已经意识到，事后修补身份验证（authn/authz）而不付出代价是不可能的。

AI 功能正在跳过这一步。原因在于文化：AI 功能感觉更像是“研究型”的。它们诞生于笔记本（notebook）、提示词或 Loom 演示。它们看起来还没被“构建”出来，所以进行常规的架构审查感觉为时过早。产品团队将早期开发视为原型。工程团队将其视为可行性探索。安全团队未被邀请，因为据说没什么可审查的。

等到有东西可审查时，身份验证模型已经在不知不觉中由原型服务账户所拥有的权限决定了。数据流已经在不知不觉中由最容易接入的 API 决定了。供应商已经在不知不觉中由原型设计者首先导入的 SDK 决定了。那个看起来像原型的东东，其实已经是一个固化的架构，只是还没被贴上标签而已。

解决方法不是放慢原型的速度，而是要意识到，AI 原型的第一次代码提交比非 AI 功能的设计文档具有更高的设计决策利害关系，并据此进行同样的轻量级架构审查。

AI 威胁模型到底能发现什么

AI 代理的攻击面与传统应用程序不同。它是动态的、依赖上下文的，并且能够实时采取后果严重的行动，通常是通过安全团队之前未曾归类为代码路径的工具（tools）来实现的。

一个有用的 AI 威胁模型至少能捕捉到通用 API 审查会遗漏的五点：

• 提示词注入攻击面（Prompt-injection surface）。 模型读取的每一段不可信文本都是潜在的指令。工单、代理获取的网页、附件、工具返回结果——这些都可能携带隐藏指令，重新引导代理。微软安全团队记录了代理框架中的提示词注入路径，这些路径从“模型说了些奇怪的话”升级到主机级别的代码执行，因为一旦模型连接了工具，提示词注入就变成了一种代码执行原语，而不仅仅是内容问题。
• 工具权限范围爆炸半径（Tool-scope blast radius）。 代理的服务账户就是代理的权力。如果代理拥有 send_email 工具和 read_ticket 工具，通过工单进行的提示词注入就可以触发邮件发送。爆炸半径不是“模型表现不佳”，而是“代理通过团队赋予它的工具采取了实际行动”。威胁模型会在确定工具列表之前，强制对每个工具的能力进行审计。
• 跨租户上下文泄漏（Cross-tenant context leakage）。 许多 AI 功能在不同租户之间共享向量索引、提示词缓存或微调适配器。检索步骤随后成为了跨租户的边界，如果检索键（retrieval keys）错了一列，租户 A 的文档最终就会出现在租户 B 的提示词中。这并不是一种罕见的失败模式；对于那些在设计隔离机制之前就构建检索功能的团队来说，这是默认的风险。
• 供应商数据路径和驻留（Provider data path and residency）。 如果 LLM 正在处理客户数据，LLM 供应商就是子处理方。这会触发 DPA 修订、针对欧盟数据的标准合同条款（SCC）、退出训练/保留策略的申请，以及可能需要选择具有 GDPR 兼容条款的模型。SaaS 应用程序在配置（provisioning）时做出驻留决定；而 AI 代理在推理（inference）时做出决定，这意味着驻留姿态不能推迟到部署步骤再考虑。
• 来自第三方内容的间接提示词注入（Indirect prompt injection）。 间接提示词注入——隐藏在代理读取的网页或文档中的指令——在两年前还只是理论，而现在已经在针对生产环境代理的攻击中被观察到。如果你的功能读取任何非用户创作的内容，那么该内容就是一个攻击面，威胁模型必须指明哪些抓取操作需要隔离步骤。

加载中…