5 篇博文 含有标签「threat-modeling」

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

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

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

一个团队在他们的日志流水线前端部署了一个经过微调的脱敏模型。它在数据进入长期存储之前剥离姓名、电子邮件、账号和 IP 地址。该模型体积小、速度快，且易于与接入层（ingestion workers）并行部署。隐私审查通过了该方案。六个月后，一位客服工程师将一行看起来很奇怪的日志粘贴到调试工具中，脱敏器产生的输出包含了一个真实客户的电子邮件地址——而这个地址在输入中根本没有出现。

流水线完全按照其构建初衷运行。而脱敏器本身就是泄露源。

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

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

你的团队为 AI 功能编写的威胁模型几乎肯定止步于模型本身。输入是不可信的：提示词注入、越狱、对抗性上传、投毒检索。输出被视为内容：需要进行安全审核、在拒绝评估中评分、发送给用户。这种威胁模型的形态大致是“不可信的东西进去，模型思考，安全的东西出来”。

新的攻击类别翻转了这种极性。模型的输出由下游系统渲染、解析、执行或中转，攻击者只要能塑造该输出——通过检索中的间接提示词注入、训练数据影响或社交工程化的用户查询——就能向模型从未直接访问过的目标传递载荷。模型变成了一个拥有攻击者所不具备的访问权限的混淆代理 (confused deputy)，而你的团队所防御的边界比实际落后了两个系统。

EchoLeak 是 2025 年的经典案例。一封精心制作的电子邮件进入 Microsoft 365 邮箱。Copilot 将其作为常规上下文读取。隐藏的指令导致 Copilot 在回复中将敏感上下文嵌入到引用样式的 Markdown 链接中，客户端界面会自动获取该外部图片——从而在无需用户点击的情况下窃取聊天记录、OneDrive 内容和 Teams 消息。微软的输入侧分类器被绕过了，因为攻击不需要破坏模型的拒绝校准，它只需要塑造输出中的一个特定 Token 序列。

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

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