AI Agent 正在从对话助手走向能够执行实际任务的系统。它们可以调用命令行、操作代码仓库、访问外部服务，并将多个步骤串联起来完成复杂工作。效率提升的同时，安全问题也开始从模型输出扩展到 Agent 的整个执行过程。
近期，韩国多家金融机构接连曝出网络攻击事件。美国网络安全公司 CrowdStrike 的调查将 AI 渗透测试工具 ARTEX 与相关攻击联系起来。随后，ARTEX 的开发者宣布项目转为闭源，并表示不再发布新版本，也不再提供维护支持。相关攻击仍在调查中，但这起事件已经带出一个值得开发者关注的问题：当 AI 能够调用工具并执行操作时，安全边界究竟应该设在哪里？
一、风险不只来自模型，还来自它能够调用什么
传统的大模型应用通常围绕输入和输出展开安全控制，例如过滤不合适的提示词、限制模型回答内容，以及对生成结果进行检查。这些措施仍然重要，但对于具备工具调用能力的 Agent 来说，仅检查最终回答并不足够。
一个 Agent 可能先理解任务，再选择工具，读取上下文，执行命令，分析结果，最后根据返回信息继续下一步。单个步骤看起来都可能合理，但多个步骤组合后，可能产生超出预期的行为。
例如，开发者让 Agent 分析一个代码仓库。Agent 需要读取文件、检查依赖、调用 Git 命令，甚至运行测试。如果仓库内容不可信，或者工具权限设置过宽，那么风险就不再局限于模型是否生成了错误答案，还包括 Agent 是否执行了不应执行的操作。
因此，评估 Agent 安全性时，至少需要拆分四个部分：
- 模型层： 是否可能受到恶意指令、上下文污染或不可信内容影响。
- 工具层： Agent 可以调用哪些命令、接口和外部服务。
- 权限层： 工具以什么身份运行，可以读取或修改哪些资源。
- 运行层： 操作是否受到隔离、监控、审批和审计。
这几个部分相互关联。即使模型本身具备较好的安全防护，只要某个工具拥有过大的权限，或者执行环境缺乏隔离，风险依然可能沿调用链传递。
二、为什么工具调用链比单次输出更难检查？
Agent 的执行过程具有连续性。它可能根据第一步的执行结果决定第二步操作，也可能在遇到异常后自动重试或更换工具。传统的单次请求检测很难完整呈现这种动态过程。
假设一个代码 Agent 需要修复测试失败的问题。它可能读取报错信息、检查项目配置、修改代码、安装依赖，再次运行测试。每一步都可能影响后续判断。若某个输入来自不可信仓库，或者某个工具在执行时触发了额外行为，风险就可能随着流程扩散。
这也是为什么安全检查不能只看最终生成的代码。除了结果本身，还需要知道 Agent 收到了什么上下文、调用了哪些工具、使用了什么权限，以及每一步操作产生了什么影响。
对于开发团队而言，可以优先建立以下几类记录：
- 执行轨迹。 记录任务输入、关键上下文、工具调用、执行结果和异常信息。
- 权限记录。 明确每次调用所使用的身份、资源范围和授权方式。
- 变更记录。 对文件修改、依赖安装、网络访问和外部系统操作保留可追溯信息。
- 异常记录。 对越权请求、异常重试、意外的外部连接和超出任务范围的操作进行标记。
记录的目的不是积累更多日志，而是让团队能够回答三个问题：Agent 为什么采取这个动作？这个动作是否在授权范围内？发生问题后，能否定位并恢复？
三、最小权限需要落实到每一种工具
Agent 安全设计中，一个常见误区是把权限控制统一交给模型判断。模型可以参与任务规划，但不应成为唯一的授权机制。
例如，一个只需要分析代码的 Agent，通常不需要直接修改生产环境；一个用于生成报告的 Agent，也不应默认拥有访问所有客户数据的权限。权限应当由任务类型、运行身份和资源范围共同决定，而不是仅由提示词描述。
实际工程中，可以从以下几项入手。
第一，区分读取、修改和执行权限。 读取仓库、修改文件、执行命令、访问网络和操作生产数据，应当作为不同能力管理。不要因为 Agent 需要完成一个任务，就一次性开放全部权限。
第二，将高风险操作放在独立执行环境中。 对代码分析、自动修复和依赖测试等任务，可以优先使用临时工作区、容器或其他隔离环境，限制文件系统、网络和凭据访问。隔离本身并不意味着绝对安全，还需要结合具体配置检查是否存在越界路径。
第三，对敏感动作设置明确的审批条件。 删除数据、修改生产配置、发布代码、访问敏感信息等操作，可以根据业务影响设置人工确认或额外验证。审批规则应当由系统执行，而不是仅要求 Agent 在执行前"先询问用户"。
第四，控制凭据的可见范围。 API Key、访问令牌和云平台凭据不应直接暴露在模型上下文中。工具应当只获得完成当前任务所需的凭据，并设置有效期、访问范围和撤销机制。
这些措施并不能消除所有风险，但可以减少一次错误决策演变为大范围影响的可能性。
四、从代码扫描走向攻击链验证
传统静态代码分析可以帮助开发者发现已知模式、危险函数和部分常见漏洞。不过，复杂风险往往分散在多个文件、服务和权限配置中。单独看某一段代码，未必能够判断它是否可以与其他问题组合成实际攻击路径。
这也是近期安全工具开始关注多步骤攻击链的原因之一。
例如，Rubrik 在 2026 年 10 月公布的 Code Guardian 相关方案，强调在隔离的代码副本中开展红队分析，并尝试识别跨文件、服务、身份角色和云环境边界的组合风险。该方案当时处于有限预览阶段，并非已经普遍可用的成熟产品。它所体现的方向是：安全验证不应停留在"发现了多少问题"，还需要评估问题能否被利用，以及可能造成什么业务影响。
对开发团队来说，这意味着代码安全流程需要增加验证环节：
- 发现问题后，确认漏洞触发条件是否真实存在。
- 检查漏洞是否需要特定权限或额外前置条件。
- 在隔离环境中验证可能的影响范围。
- 根据业务重要性排序，而不是只按告警数量处理。
- 修复后重新运行相关测试，确认没有引入新的回归问题。
AI 可以帮助分析复杂代码、提出测试路径或辅助生成验证用例，但最终结论仍需要可复现的证据支持。不能仅凭模型声称"存在漏洞"就认定风险成立，也不能因为模型没有发现问题，就认为系统已经安全。
五、如何测试 Agent 是否真的安全？
与普通接口不同，Agent 的任务结果可能受到上下文、工具选择和执行顺序影响。因此，测试不能只覆盖单个输入，还需要覆盖执行过程。
可以先为常见任务建立一组基线测试，例如代码审查、自动修复、数据查询和报告生成。除了检查任务是否完成，还应记录以下指标：
| 验证维度 | 需要观察的问题 |
|---|---|
| 任务成功率 | 是否完成目标，是否产生错误结果 |
| 权限边界 | 是否尝试访问未经授权的资源 |
| 工具调用 | 是否调用了不必要或超出任务范围的工具 |
| 执行稳定性 | 异常后是否陷入重复重试或错误循环 |
| 结果可验证性 | 修改、查询和外部操作是否有证据可追溯 |
| 回归情况 | 模型、提示词或工具版本变化后，原有测试是否仍然通过 |
还可以补充负向测试：在上下文中加入不可信指令，提供格式异常的文件，模拟工具调用失败，或让任务要求与工具权限发生冲突，观察系统是否能拒绝不合适的操作。
测试集需要随着真实故障和新风险持续更新。一次测试通过只能说明当前版本在这些测试条件下表现符合预期，不能证明 Agent 在所有环境中都安全。
六、企业部署 Agent，安全控制应贯穿整个生命周期
Agent 上线前，需要审查工具清单、权限范围、数据访问路径和执行环境；上线后，需要持续观察调用行为、异常操作和任务结果；当模型、提示词、工具或依赖发生变化时，还需要重新执行相关验证。
企业也应明确不同团队的责任。开发团队负责工具实现和执行隔离，安全团队负责风险建模与验证策略，业务团队确认哪些操作可以自动执行、哪些必须经过审批。只有把权限、运行记录和恢复机制纳入日常流程，Agent 才不至于成为缺乏治理的自动化入口。
AI Agent 的安全问题，最终不是单纯判断模型够不够聪明，而是确保它在真实环境中只能做被允许的事，并且每个关键动作都可以被验证和追溯。
随着 Agent 承担更多软件开发、数据处理和企业系统操作任务，安全设计也需要从模型输出扩展到工具、权限、执行环境和完整工作流。对于开发者来说，越早把这些控制纳入工程流程，越容易在效率提升与风险控制之间建立稳定的边界。