为 AI 开发工作流建立威胁模型

选择范围有限的场景

从一套容易理解的工作流开始。例如，智能体读取 issue、修改代码仓库、运行测试并创建 pull request。纳入支持这些操作的系统。

列出重要资产：源代码、客户信息、凭据、发布制品和服务可用性。明确各自负责人，再识别谁或哪些系统可以读取、修改每项资产。

OWASP 建议先为系统建模，再识别威胁、选择应对措施并验证结果。尽早使用这种方法，并随系统变化更新。参见威胁建模指南。

对于这个虚构的 issue 到 PR 工作流，画出以下连接：

Issue → agent → repository → test runner → artifact store → deployment

加入模型提供方和秘密信息存储系统。标出哪些内容来自可信度较低的来源。标出身份在哪里获得新的能力，例如从读取 issue 转向写入代码仓库文件。

仅有应用图不能展示完整的开发风险。生产数据库可以是私有的，而 CI 任务仍可能暴露凭据。如果临时环境和支持人员访问影响该场景，也应纳入。

避免“AI 可能不安全”这类条目。写明参与者、操作、受影响资产和后果，也写明场景发生所需的条件。

这些只是示例，不是完整威胁清单。哪些场景相关，取决于你的数据、工具和运行环境。

根据后果和可信的风险暴露确定优先级。不要用数字评分装作拥有实际并不具备的精度。记录不确定性，以及哪些证据可能改变优先级。

应对方式可以是移除高风险能力、缩小范围、增加控制措施，或接受明确定义的剩余风险。接受风险需要获授权的负责人和理由，不能只凭智能体未经审查的结论。

将选定的应对措施转化为工作，并设置可观察的验收条件。“改进智能体安全”难以验证。“测试任务无法读取生产秘密信息”则明确了一条可检查的边界。

新的连接器、模型路由、环境或权限都可能改变威胁模型。将这些变化列入复核触发条件，也利用事件和失败评估来更新假设。

尝试风险审查练习，改变场景中的数据、权限、用户范围和恢复条件。结果会提示需要考虑的问题，但不能代替针对具体系统的威胁模型，也不会授权执行工作。