识别和管理 AI 智能体风险
学习目标
完成本单元后，您将能够：
- 识别工作流程中智能体与数据、决策及人员的交互位置。
- 运用威胁建模降低 AI 智能体风险。
开始之前
开始此模块前，请考虑完成下列推荐内容。
威胁建模业务工作流程
威胁建模是一种结构化方法，用于了解系统运行方式、识别潜在问题，并在风险造成问题之前决定如何管理这些风险。在本单元中，您将运用简化版威胁建模跟踪智能体在业务流程中的位置，以及风险可能潜入的位置。
在深入了解代码级威胁建模之前，先了解 AI 智能体如何融入更广泛的业务工作流程会有所帮助。STRIDE（欺骗、篡改、否认、信息披露、拒绝服务和权限提升的简称）是大多数开发人员熟悉的威胁建模框架，他们利用该框架识别应用程序中的技术安全威胁。但即便是最完善的 STRIDE 分析也无法完全捕获因智能体的使用方式而产生的所有风险。
当开发人员和安全专业人员了解业务工作流程时，威胁模型就会更加清晰。他们能够发现哪些步骤最重要并跟踪智能体决策产生的内外连锁反应。他们开始注意到集成开发环境 (IDE) 中不会出现的风险。诸如审批缺失、静默失败或交接不清等问题不会在代码编辑器中显现。但是，当对工作流程本身进行建模和检查时，这些问题很快就会浮现出来。
工作流程级别的威胁建模揭示了控制措施的薄弱之处、智能体依赖假设的位置，以及很小的疏漏如何演变为影响业务的问题。
在映射您自己的工作流程之前，让我们来看看这个示例，了解单个步骤的缺失如何导致整个流程中断，即使是系统各部分看似运行正常。
场景：消失的报表
在映射您自己的工作流程之前，让我们先通过一个快速挑战场景来热身。
贵公司的季度合规报表缺失。系统显示该报表已生成，但未能发送给监管机构。负责收集、审核并通过电子邮件发送报表的自动化智能体坚持其“已成功完成所有步骤”。以下是简化的工作流程。
步骤 | 操作人/操作者 | 描述 |
|---|---|---|
1. 数据是从财务系统中收集的。 | AI 智能体 | 从多个数据库中提取数据。 |
2. 报表已生成。 | AI 智能体 | 编译数据并格式化报表。 |
3. 报表已审核。 | 人工 | 检查总数并签字。 |
4. 报表已通过电子邮件发送。 | AI 智能体 | 将最终版本发送给监管机构。 |
您的任务
仔细查看每个步骤，注意涉及智能体的部分，然后问自己：
- 报表可能在哪个环节未能移至下一步（未保存、未交接还是未发送）？
- 哪种控制或检查措施能及早发现该故障？
- 报表未能发送时，应通知谁？
您无需写入完整回复，只需思考可能导致故障的原因以及您会首先检查哪些方面。此练习展示了小故障（检查缺失或所有权不明）如何在工作流程中产生连锁反应。
答案要点：消失的报表
可能的原因不止一个，以下列举了一些可能的原因和经验教训。
步骤 | 可能出了什么问题 | 本可阻止该问题发生的方法 |
|---|---|---|
1. 数据是从财务系统中收集的。 | 智能体可能从未启动数据收集步骤，因此工作流程未能继续推进至报表创建阶段。 | 添加触发检查，以确认流程已启动且初始数据收集成功，然后再继续进行。 |
2. 报表已生成。 | 智能体创建了报表，但未将其存储在正确的文件夹中或标记为待发送状态。 | 添加自动检查，以确认报表已保存、正确命名并准备交付。 |
3. 报表已审核。 | 人工审核员审批了该文件，但未确认发送操作是否被触发。 | 包含一份审核清单或一个仪表板，显示交付状态是待处理、进行中还是已完成。 |
4. 报表已通过电子邮件发送。 | 智能体尝试发送电子邮件，但操作失败或权限已过期，且未引发任何警报。 | 添加交付确认和通知步骤，以便审核员知晓报表何时成功发送。 |
该场景展示了智能体风险如何在实际工作流程中显现：检查缺失、交接不清以及故障未报告。这些问题对开发人员、系统管理员、网络安全专业人员以及负责配置和维护工作流程的人员最为明显。尽早检查这些接触点有助于防止很小的疏漏演变成影响业务的故障。
用您自己的工作流程尝试一下
现在，将相同的镜头应用于内部工作流程。目标旨在了解智能体与人员、数据和系统之间的联系，以及风险最可能出现的位置。按照以下四个步骤映射工作流程，识别潜在风险点，并考虑如何进行管理。
步骤 1：映射工作流程
- 首先选择一个智能体处于活动状态的流程（客户支持、排程、入职）。
- 确定从开始到结束的步骤。
- 注意谁（哪些对象）触发了该流程，哪些数据会通过该流程，以及智能体在其中的位置。
示例：客户支持的智能体工作流程
客户请求 → 智能体审核数据 → 智能体响应 → 人工审批 → 系统更新
步骤 2：标记交互
- 接下来，寻找智能体与以下内容的交互位置：
- 人员（用户、员工、客户）
- 数据（智能体读取、写入或存储的信息）
- 系统（应用程序、API、数据库）
- 人员（用户、员工、客户）
- 突出这些接触点。风险最有可能在其中出现。
示例：客户请求（数据录入） → 智能体审核数据（API 连接） → 智能体响应 → 人工审批（人工审核） → 系统更新
步骤 3：应用威胁建模镜头
现在，在每个接触点上问自己几个简单的问题。
- 此处会有什么问题呢？
- 如果智能体做出错误决策，或操作过早或过晚，会发生什么？
- 谁（哪些对象）可能利用此步骤？
创建一个简单的表格，用于记录可能出现最大问题的环节。以下是一个简略示例。
步骤 | 可能的风险 | 影响 |
|---|---|---|
客户请求 | 客户提交的数据缺失或不完整 | 智能体响应错误或无法完成任务。 |
智能体审核数据 | 过多 API 访问 | 敏感数据泄露。 |
步骤 4：制定响应计划
- 对于注意到的每种风险，决定如何处理该风险。
- 通过收紧权限、增加审核步骤或限制智能体的访问权限来修复此问题。
- 通过添加警报、日志或定期审核进行监测。
- 通过记录低影响风险来接受它们，以便日后随时查看。
- 通过收紧权限、增加审核步骤或限制智能体的访问权限来修复此问题。
- 选出您认为最重要的三种风险，并针对每种风险提出一项具体应对措施。
风险分析示例
步骤 | 可能的风险 | 响应 | 影响 |
|---|---|---|---|
客户请求 | 客户提交的数据缺失或不完整 | 修复：添加必填字段或验证检查，以防止提交不完整的请求。 | 智能体收到完整、准确的信息，并能正确响应。 |
智能体审核数据 | 过多 API 访问 | 监测：若智能体尝试访问已批准系统之外的数据，则添加警报。 | 安全分析师会在异常或不安全的数据访问变成更大问题之前就将其检测出来。 |
总结
在本单元中，您映射了工作流程，识别了智能体与人员、数据及系统的交互位置，并运用简化的威胁建模镜头揭示了潜在风险。当您进入 STRIDE 等正式威胁建模框架时，请谨记此工作流程视图。它们能帮助您识别更深层的技术威胁，但工作流程上下文则确保努力始终立足于最重要的部分——让 AI 智能体始终与企业的使命和成果保持一致。