最近的研究把问题说得更清楚了
6 月 9 日，arXiv 发布论文《AgentCanary: A Security Evaluation Framework for Autonomous AI Agents in Real Executable Environments》。这篇研究的价值，不在于又列出了一组新的攻击名词，而在于它明确提出：自主 AI Agent 的安全失败正在从“文本欺骗”转向“系统被影响”。
研究者认为，过去很多安全评测依赖静态问答、模拟工具或最终回复判断，这不足以发现 Agent 在真实执行中的风险。因为真正的伤害往往发生在环境里：文件被删除，记忆被污染，工具被误用，敏感数据被读取，外部服务被调用，交易参数被改变。
AgentCanary 的评测思路因此更接近企业真实上线环境：让 Agent 在可执行环境中使用真实工具，处理网页、邮件、文件、记忆、技能和虚拟账户等任务材料，并观察完整执行轨迹，而不是只看最后一句回答。
论文还把风险拆成两个维度：风险从哪里进入，以及最终造成什么影响。风险入口包括直接提示注入、外部内容中的间接提示注入、被污染的技能或工具、持久记忆和状态污染、Agent 自身在模糊任务中的内生失败。风险影响则包括本地环境破坏、数据泄露、记忆污染、权限和系统控制、网络攻击、业务滥用、金融或交易风险。
这对企业非常关键。因为同一种后果，可能来自不同入口；同一个入口，也可能造成不同损害。比如一段恶意网页内容、一个被污染的插件、一条被写入长期记忆的错误规则，都可能让 Agent 在后续任务中做出越权动作。
5 月 7 日，另一篇论文《Towards Security-Auditable LLM Agents: A Unified Graph Representation》也提出类似判断：传统运行日志和软件物料清单不足以解释 Agent 的安全问题，因为 Agent 的行为包含目标、推理轨迹、工具调用、长期记忆、多 Agent 协作和状态变化。研究者提出的 Agent-BOM，试图把模型、工具、记忆、目标、推理、动作和风险路径组织成可查询的审计图。
这些研究共同说明了一件事：企业不能再用“测试提示词”来代替“验收 Agent 系统”。
为什么普通安全测试不够用
传统软件的安全边界相对清晰。用户点击按钮，系统执行确定逻辑；接口输入什么、数据库写什么、权限校验在哪里，通常可以被工程团队逐层检查。
Agent 系统不一样。它的执行链路更像一个不断决策的工作流：
这带来一个新的难点：风险不一定在第一步出现，也不一定表现为明显的违规回答。
一个 Agent 可能在最终回复里看起来很正常，但过程中已经读取了不该读的文件；也可能没有立即造成损害，却把一条错误规则写进长期记忆，在几天后的正常任务中触发；还可能在权限允许范围内调用工具，但业务意图已经偏离了用户原本目标。
所以，企业需要从三个层面重新定义安全验收。
第一，看结果是否安全。任务完成后，文件、数据、客户记录、账户、权限、外发消息有没有出现不该发生的变化。
第二，看过程是否可解释。Agent 为什么选择这个工具，读取了哪些材料，依据了哪些指令，是否把外部内容误当成系统指令。
第三，看能力是否可控。高风险操作是否必须人工确认，失败重试是否有上限，跨系统调用是否有最小权限，异常路径是否会升级给负责人。
如果只看最终回答，企业看到的是“说得像不像”。如果看完整执行轨迹，企业才能知道“做得安不安全”。
- 它会理解用户目标。
- 它会选择工具。
- 它会读取外部内容。
- 它会把中间结果写入上下文或记忆。
- 它会根据工具返回继续规划。
- 它可能跨多个步骤完成任务。
Agent 的安全边界，首先是权限边界
很多企业在上线 Agent 时，会把注意力放在模型选择、知识库质量和提示词模板上。这些当然重要，但更底层的问题是权限。
Agent 一旦能调用工具，就不再只是一个信息系统的入口，而是一个新的操作主体。它需要被当成“非人类身份”来管理：它能访问哪些系统，能读取哪些字段，能写入哪些对象，能不能外发内容，能不能跨租户检索，能不能调用支付、审批、合同、客户通知等高影响接口。
企业可以把 Agent 的权限设计分成四类。
第一类是只读权限，例如查询制度、检索知识库、读取公开产品资料。风险相对较低，但仍要注意敏感字段和越权检索。
第二类是草稿权限，例如生成邮件、方案、报价说明、工单回复、会议纪要。Agent 可以产出内容，但必须由人确认后发送或发布。
第三类是受控写入权限，例如创建工单、更新客户标签、生成待审批记录。Agent 可以改变系统状态，但变更范围、字段、频率和回滚机制要清楚。
第四类是高影响执行权限，例如自动退款、修改合同条款、触发采购、调整账户、发送客户通知。这类能力不应因为“模型表现不错”就直接开放，而要有强制人工确认、审批链、审计日志和异常阻断。
这不是保守，而是企业级 AI 的基本工程纪律。Agent 越有用，越需要边界；越靠近核心流程，越需要可追溯。
企业最容易忽视的是“持久状态”
聊天机器人时代，很多交互是一次性的。问题问完，答案给出，风险主要集中在当次输出。
Agent 时代，风险会被状态放大。记忆、偏好、工具配置、技能文件、历史任务、缓存内容，都可能影响未来行为。
这也是近期研究反复强调记忆污染、技能污染和长链路攻击的原因。攻击者未必需要一次性让 Agent 做出危险动作，只要让它在长期状态里记住一条错误规则，或者让它安装一个看似正常但带有隐藏行为的工具，就可能在后续正常工作中制造风险。
企业因此需要把状态纳入验收范围：
如果没有这些机制，Agent 的风险会从“一次错误输出”变成“长期错误行为”。
- 长期记忆写入是否需要策略控制。
- 记忆内容是否可查看、可删除、可版本化。
- 技能、插件、工具描述是否经过签名和审批。
- Agent 是否能区分用户指令、系统指令、外部内容和工具返回。
- 跨会话行为是否有审计记录。
- 异常状态是否能被自动发现并回滚。
安全验收不应只由安全部门完成
Agent 安全不是纯技术问题。安全部门能做威胁建模、权限控制、日志审计和攻击测试，但它无法单独判断一个业务动作是否合理。
例如，销售 Agent 自动生成客户跟进邮件，安全部门可以判断是否泄露敏感数据，却未必能判断邮件中的承诺是否符合销售政策。
财务 Agent 辅助生成付款建议，安全部门可以检查权限和外发风险，却未必能判断付款条件是否满足合同规则。
客服 Agent 自动处理退款或补偿，安全部门可以评估接口风险，却未必能判断客户体验、政策边界和升级条件是否合理。
因此，Agent 上线验收至少需要四类角色共同参与。
业务负责人定义任务边界、成功标准、异常情况和人工接管条件。
IT 和架构团队负责系统集成、身份权限、工具调用、日志和回滚能力。
安全与合规团队负责威胁建模、数据边界、审计要求、攻击测试和高风险操作控制。
一线用户负责验证流程是否符合真实工作，不只是演示时能跑通。
企业真正要建立的不是一个“AI 试用流程”，而是一套 Agent 上线前后的运行验收机制。
给企业的落地建议：先做一张 Agent 风险清单
正在推进 AI Agent 的企业，可以先从一个很具体的动作开始：为每一个 Agent 建立风险清单。
这张清单不需要复杂，但至少要回答以下问题。
第一，这个 Agent 代表谁执行任务。
它是代表员工个人、代表部门、代表公司系统，还是只作为辅助工具存在。身份不同，责任和权限完全不同。
第二，它能接触哪些数据。
包括客户数据、合同数据、财务数据、员工数据、产品数据、源代码、系统日志、外部网页和第三方资料。每类数据都需要权限、脱敏和留痕策略。
第三，它能调用哪些工具。
工具清单要明确到接口、字段、动作和环境。不要只写“可调用 CRM”，而要写清楚能查什么、能改什么、能不能触发外发动作。
第四，哪些动作必须人工确认。
涉及金钱、合同、客户承诺、外部发布、权限变更、数据删除、批量操作、高风险人事或合规判断的动作，都应默认需要确认。
第五，如何判断它出错。
不仅要看最终输出，还要看执行过程：是否读取了异常来源、是否出现过度重试、是否绕过确认、是否调用了不必要工具、是否写入了异常记忆。
第六，出错后如何处置。
包括暂停 Agent、撤销权限、回滚数据、通知负责人、保全日志、复盘攻击入口和修正流程。
这张清单的意义，不是让 AI 项目变慢，而是让企业知道自己到底把什么权力交给了 Agent。
一个现实判断
企业 AI 落地正在从“让员工更快完成任务”，进入“让系统自动承担部分执行”的阶段。
这个变化会带来更高效率，也会带来更高责任。因为 Agent 一旦进入真实系统，它的错误不再只是一个不准确答案，而可能是一次错误写入、一封错误邮件、一笔错误交易、一条被污染的长期记忆，或者一个难以复盘的跨系统链路。
因此，企业判断 AI 能不能上线，不应只问模型能力是否领先，也不应只问演示效果是否流畅，而要问：
未来真正成熟的企业级 AI，不会是“让 Agent 什么都能做”，而是“让 Agent 在清楚边界内稳定、可控、可验收地做事”。
这才是企业从 AI 试点走向生产系统时，必须补上的一课。
- 权限是否最小化。
- 工具调用是否可控。
- 外部内容是否被隔离。
- 长期状态是否可审计。
- 高风险动作是否有人工确认。
- 完整执行轨迹是否能复盘。
- 出错后是否能暂停、回滚和追责。
