五眼联盟对企业AI安全的劝告书

五眼（英语：Five Eyes，缩写为FVEY），又译为五眼联盟，是由五个英语圈国家所组成的情报联盟，在英美协定下组成的国际情报分享团体，成员国包括澳大利亚、加拿大、新西兰、英国和美国。

2026 年 5 月 1 日，澳大利亚网络安全官网发布了一份关于 Agentic AI 的安全劝告书，题为《Careful adoption of agentic AI services》。

https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services

这份文件由澳大利亚 ASD’s ACSC、美国 CISA 和 NSA、加拿大 Cyber Centre、新西兰 NCSC-NZ、英国 NCSC-UK 共同撰写，面向政府、关键基础设施和大型组织，讨论 Agentic AI 进入 IT 环境后带来的安全挑战和防护实践。

文件一开头就给出非常明确的建议：采用 Agentic AI 时必须以安全为前提，评估具体用途，不能授予广泛或不受限制的访问权限，尤其不能让它随意接触敏感数据和关键系统，并且应优先用于低风险、非敏感任务。

这句话背后的判断很直接：Agent 不再只是一个会聊天、会总结、会生成文本的模型接口。只要它开始接工具、接数据、接权限、接业务流程，它就变成了一个可以行动的数字主体。

它可能读邮件、调 API、查数据库、写文件、改配置、触发自动化流程，甚至在多 Agent 系统里继续拆分任务、派生子 Agent。此时，安全问题的重心已经从“模型说了什么”转向“系统做了什么”。

一、这是谁发的？

这份文件的分量，首先来自它的署名机构。

澳大利亚 ASD，即 Australian Signals Directorate，是澳大利亚国家安全体系中的重要机构；其下的 Australian Cyber Security Centre，也就是 ASD’s ACSC，负责牵头澳大利亚政府层面的网络安全工作，向政府、关键基础设施、产业和公众提供网络安全建议与服务。

官网：https://www.asd.gov.au/about/what-we-do/cyber-security

美国 CISA，全称 Cybersecurity and Infrastructure Security Agency，是美国网络安全和基础设施安全局，定位是美国的网络防御机构，主要职责是与合作伙伴一起抵御当前威胁，并建设更安全、更有韧性的基础设施。

官网：https://www.cisa.gov/about

美国 NSA，即 National Security Agency，既承担信号情报任务，也承担网络安全任务。NSA 官方介绍中提到，其网络安全协作中心通过产业合作来预防和消除针对美国国家安全系统、国防相关系统和国防工业基础的外国网络威胁。

官网：https://www.nsa.gov/about/

加拿大 Cyber Centre，即 Canadian Centre for Cyber Security，是加拿大网络安全领域统一的专家建议、指导、服务和支持来源，面向政府、关键基础设施、私营部门和公众提供服务。它隶属于加拿大通信安全局 CSE，并被定义为加拿大网络安全技术权威。

官网：https://www.cyber.gc.ca/en/about-cyber-centre

新西兰 NCSC-NZ，即 National Cyber Security Centre，向新西兰个人、中小企业、大型组织、政府和关键基础设施运营方提供网络安全服务，能力覆盖威胁情报、事件响应、安全指导、攻击检测与干扰等方面。

官网：https://www.ncsc.govt.nz/who-we-are/

英国 NCSC-UK，即 National Cyber Security Centre，是 GCHQ 的一部分，负责帮助企业、公共部门和个人保护线上服务和设备。英国 NCSC 也明确表示，它是英国网络安全的国家技术权威，负责防御来自国家级攻击者、黑客和网络犯罪分子的高级网络威胁。

官网：https://www.ncsc.gov.uk/section/about-ncsc/what-we-do

这些机构共同发布 Agentic AI 安全文件，本身就是一个信号：Agent 安全已经从产品功能问题，进入国家级网络安全机构共同关注的范畴。

二、劝告书的结构

这份劝告书的结构很清晰，基本可以看成一套 Agent 安全治理的入门框架。

第一部分是介绍和范围界定。文件说明，它主要关注基于大语言模型的 Agentic AI 系统，既考虑针对 Agent 的威胁，也考虑 Agent 系统内部的脆弱性，还考虑 Agent 自主行为带来的风险。目标读者包括政府、关键基础设施、产业组织，以及设计、开发、部署和运营 Agentic AI 系统的相关方。

第二部分回答“什么是 Agentic AI”。文件认为，Agentic AI 系统由一个或多个 Agent 组成，核心依赖 AI 模型来理解世界状态、进行推理、做出决策并采取行动。典型系统不只有 LLM，还包括外部工具、外部数据源、记忆和规划工作流。相比传统生成式 AI，Agentic AI 的特点是能够处理目标不完全明确的任务，具备自主行动能力，能表现出目标导向行为，并能形成长期计划。

第三部分讨论广义安全考虑。文件把 Agent 安全放进更大的网络安全体系中，而不是把它当成一个孤立的 AI 问题。它强调，Agent 会继承 LLM 的提示注入等风险，同时因为连接工具、外部数据和记忆系统，攻击面会扩大；由于 Agent 在 AI 系统和非 AI 系统之间持续流动信息，防御边界会变得模糊，级联故障和多步攻击也会更难处理。

第四部分是全文最重要的风险拆解。文件将 Agentic AI 的安全风险分成几大类：权限风险、设计与配置风险、行为风险、结构风险和问责风险。每一类风险都不是抽象概念，而是结合了具体场景，比如采购审批 Agent 被过度授权、第三方组件被攻破后横向移动、补丁 Agent 删除防火墙日志、多 Agent 系统因编排失败导致级联故障等。

第五部分给出最佳实践。文件不是只停留在原则层面，而是按照设计、开发、部署和运行四个阶段给出控制措施。设计阶段强调上下文控制、人工监督、身份管理和纵深防御；开发阶段强调综合测试、恰当评估、输入管理、红队测试、韧性、问责和第三方组件管理；部署阶段强调威胁建模、治理、渐进式部署、安全默认配置、护栏约束和隔离；运行阶段强调监控审计、输出验证、人在回路、性能监控、权限和认证。

最后，文件还讨论了未来风险防御，包括扩大 Agent 威胁情报协作、发展 Agent 专用评估方法、使用系统理论方法分析安全问题，并在附录中列出引入 Agent 前应具备的网络安全前置条件，例如强认证、最小权限、临时凭证、沙箱、加密、速率限制、输入净化、供应链风险管理、威胁建模和事件响应演练。

三、Agent 的五类安全风险

这份文件最值得关注的地方，不是它列出了多少条安全建议，而是它把 Agent 安全的对象重新定义了。

过去谈大模型安全，很多人首先想到的是内容风险。用户输入是否违规，模型输出是否越界，回答是否有幻觉，是否会被越狱。这些问题依然存在，但 Agent 场景里，风险已经进入执行链路。

一个普通聊天机器人说错一句话，可能影响用户判断。一个接入业务系统的 Agent 做错一步动作，可能直接删除日志、修改合同、触发财务付款、泄露客户数据、关闭安全更新。前者是内容风险，后者是操作风险。

文件中特别强调，Agentic AI 会连接工具、外部数据、记忆和规划流程，这些组件让系统可以感知环境并采取行动。也正因为如此，Agent 的风险不再停留在文本层面，而会沿着工具调用、权限边界、数据流转和系统集成向外扩散。

这也是为什么文件反复强调：Agent 应该纳入已有网络安全框架，而不是被当成一个单独的 AI 安全问题。因为 Agent 本质上运行在软件、硬件、网络和数字服务之上，会暴露在传统 IT 系统类似的威胁之下，同时又因为自主性和复杂性放大这些威胁。

换句话说，Agent 安全的主战场不在模型输出页面，而在企业 IT 系统内部。

第一类风险：权限失控，Agent 变成“高权限执行人”

文件最先讨论的是权限风险，这很合理。Agent 一旦可以行动，权限就决定了它能造成多大影响。

在传统软件系统里，权限控制已经是核心问题。到了 Agent 场景，这个问题会更复杂。因为 Agent 不是简单执行固定代码，而是会根据上下文、目标、工具反馈和模型推理动态决定下一步动作。如果一开始就给 Agent 很宽的权限，后续所有推理错误、提示注入、工具污染、身份冒用，都可能被放大成真实操作。

文件举了一个采购审批 Agent 的例子。组织为了降低摩擦，让 Agent 自主处理采购审批和供应商沟通，并授予它访问财务系统、邮件和合同库的广泛权限。如果攻击者攻破 Agent 工作流里的低风险工具，就可能借用 Agent 的过高权限修改合同、批准付款，而且这些操作看起来还像是可信 Agent 正常执行的行为。文件将这类情况称为 confused deputy，也就是低权限攻击者诱导高权限主体替自己完成未授权操作。

这个场景对企业很有现实意义。很多企业在引入 Agent 时，出发点是提升效率，于是倾向于让 Agent “多接一点系统”“多拿一点权限”“少一点人工确认”。但从安全角度看，这些便利都会变成攻击半径。

Agent 的权限设计不能照搬传统账号体系。它需要更细粒度、更动态、更可撤销，也需要针对每次工具调用重新判断上下文。否则，Agent 很容易从“自动化助手”变成“攻击者的代办账号”。

第二类风险：设计和配置缺陷，让一次小错误变成横向扩散

文件的第二类风险是设计与配置风险。这里讨论的重点不是模型能力，而是系统集成方式。

很多 Agent 应用会集成第三方组件、调度器、插件、外部 API、工具市场和业务系统。如果第三方组件没有经过充分审查，却被赋予过宽权限；如果授权只在启动时检查一次，运行中不做逐次校验；如果不同 Agent 环境之间缺乏隔离，那么一次小的组件妥协，就可能横向移动到其他 Agent 或业务系统。

文件中举了一个客服工单 Agent 的例子。它会调用后端工具检索账户信息，同时集成了一个第三方调度组件。由于这个组件没有经过充分权限审查，并且系统在启动时授予了较宽访问权限，当该组件被攻破后，Agent 继续依赖缓存的授权决策，调用本应逐次验证的敏感账户管理功能。由于环境隔离较弱，攻击者进一步横向移动到处理账单和退款的相邻 Agent，最终造成未授权数据访问和财务操纵。

这个问题说明，Agent 的安全不只取决于模型，也取决于周边工程体系。工具注册、插件来源、权限缓存、环境隔离、允许列表、API 策略、日志保护，这些都可能成为 Agent 系统的关键薄弱点。

在 Agent 时代，安全架构不能只问“模型有没有对齐”，还要问“工具是谁提供的”“权限什么时候授予”“每次调用是否重新鉴权”“不同 Agent 之间是否默认互信”“日志是否能被 Agent 自己修改”。

第三类风险：行为偏离，Agent 为了完成目标走捷径

Agent 的行为风险，是这份文件里最有 AI 特征的一部分。

传统软件通常按照明确规则执行，出了问题可以追溯到代码逻辑。Agent 的行为来自目标、上下文、模型推理、工具反馈和环境状态的组合，开发者很难穷尽所有路径。文件提到，Agent 可能用开发者没有预料到的方式追求目标，比如找到技术上满足目标、但违背目标意图的捷径。这就是规格博弈。

文件举了一个非常典型的例子：如果给 Agent 的目标是“最大化系统在线时间”，它可能为了避免重启而关闭安全更新。这个行为从指标上看似乎提高了在线时间，但从安全上看，等于牺牲了补丁和防护。

这类风险很适合放到企业场景里理解。一个运维 Agent 被要求“尽快恢复服务”，可能会跳过安全校验；一个客服 Agent 被要求“提高用户满意度”，可能会违规承诺退款；一个代码 Agent 被要求“快速修复问题”，可能会绕过测试流程；一个内容运营 Agent 被要求“提高转化率”，可能会生成合规边界模糊的营销内容。

Agent 的目标函数如果写得太粗，约束条件如果不够硬，它就可能沿着效率指标一路狂奔。对企业来说，这种风险并不神秘，本质上就是 KPI 被自动化系统放大后的结果。

第四类风险：结构复杂，多 Agent 系统会产生级联故障

Agentic AI 的另一个核心风险来自系统结构。一个 Agent 还相对容易控制，多 Agent、工具、记忆、RAG、外部数据、业务系统全部耦合之后，风险就会变成系统性问题。

文件中描述了一个结构性风险场景：规划、检索和执行 Agent 紧密耦合，自主委派任务、选择工具，但缺少强校验和护栏。一个小的编排缺陷导致 Agent 反复重新规划、传递模糊子任务，工具调用和消息流量不断增加，系统资源被拉高。随后部分失败引发幻觉输出，下游 Agent 又把这些输出当成真实信息继续执行。更严重的是，一个 Agent 在降级状态下选择了恶意或配置错误的第三方工具，工具向系统注入有害指令，污染同伴 Agent，并通过 Agent 之间的隐式信任扩散错误信息，最终影响 RAG 中的敏感数据。

这个场景真正可怕的地方在于，事故并不来自单个明显漏洞，而来自系统结构的连锁反应。每个局部看起来都只是“小问题”：一个模糊任务、一次重新规划、一个工具选择、一次上下文污染、一次下游信任。但连在一起之后，就可能形成可用性、完整性、保密性的同时失守。

这也解释了为什么 Agent 安全不能只靠单点护栏。输入过滤、输出检测、工具白名单都很重要，但多 Agent 系统还需要编排层面的安全控制，需要对任务流、工具链、信任边界、上下文传递和失败恢复做整体治理。

第五类风险：问责困难，出了问题不知道是谁干的

文件还专门讨论了问责风险。随着 Agent 自主性提高，系统可能会出现一个很尴尬的问题：动作已经执行了，但组织很难解释这一步到底是哪个 Agent、哪个工具、哪个上下文、哪个决策分支导致的。

在多 Agent 系统中，一个任务可能经过规划 Agent、检索 Agent、执行 Agent、审批 Agent、外部工具和长期记忆。每个组件只看到局部上下文，最终动作却来自一条分布式决策链。如果日志碎片化、推理过程不透明、工具调用记录不完整，企业就很难解释结果，也很难追责和合规证明。文件明确提到，Agent 行为和决策过程可能是不透明的，Agent 还可能发起次级任务、生成子 Agent 或形成长委托链，进一步增加监控和审计难度。

这对监管和企业治理非常关键。传统 IT 系统可以依赖操作日志、账号记录和审批流追责。Agent 系统如果没有统一审计，就可能出现“动作可见、原因不可见”“结果可见、链路不可见”“账号可见、意图不可见”的问题。

所以 Agent 安全一定要从上线第一天就设计可观测性。后补日志往往不够，因为很多关键中间状态已经丢失了。

四、最关键的防护建议：不要只监控输入输出

这份文件里最值得国内 AI 安全行业关注的一句话，是运行阶段的监控建议：要监控所有 Agent 操作，包括内部过程，而不能只看输入和输出。文件进一步说明，监控范围应覆盖用户提示、工具调用、记忆交互、内部推理、决策和实际动作，还要建立运行时监控和异常检测，识别声明意图与观察到的实际行为之间的差异。

这句话基本点破了 Agent 安全产品的方向。

过去做大模型安全护栏，最常见的是三段式：输入风险检测、敏感问题安全代答、输出风险检测。这套体系在聊天机器人和内容生成场景里有效，但到了 Agent 场景，它只能覆盖一部分风险。

Agent 的危险行为往往发生在中间过程。它读取了什么网页，是否把恶意网页内容写进上下文；它调用了什么工具，工具返回结果是否带有隐藏指令；它访问了什么数据，是否超出任务所需范围；它是否把错误信息写入长期记忆；它是否在多轮规划中偏离原始目标；它是否尝试删除日志、扩大权限、绕过审批。

这些问题不在最终输出里，甚至可能没有自然语言输出。只看输入输出，等于只看 Agent 的门口和出口，却看不到它在系统内部走了哪条路。

五、四阶段安全防护

文件给出的防护建议可以浓缩成一句话：Agent 安全必须贯穿全生命周期。

在设计阶段，文件强调上下文控制、人工监督机制、身份管理和纵深防御。尤其是身份管理，它要求把每个 Agent 构造成独立主体，使用自己的密钥或证书，并对 Agent 到 Agent、Agent 到服务的 API 调用进行认证。它还建议维护可信注册表，将身份绑定到授权角色，拒绝不在可信注册表中的 Agent 或密钥访问。

在开发阶段，文件强调综合测试、恰当评估、输入管理、红队测试、韧性、问责和第三方组件管理。这里有一个很重要的思想：Agent 的评估要覆盖不同自治程度、不同工具访问、不同上下文条件和多 Agent 情况，因为 Agent 在真实环境中的行为很可能受到工具、模型、资源、其他 Agent 和评估时机影响。

在部署阶段，文件强调威胁建模、治理、渐进式部署、安全默认、护栏约束和隔离。渐进式部署尤其重要，因为 Agent 的风险会随着权限和可执行动作增加而显著变化。文件建议先限制 API、限制动作空间、使用沙箱，再通过持续评估决定是否扩大系统范围，或者在失败时回滚自治程度和访问权限。

在运行阶段，文件强调持续监控和审计、输出验证、人在回路、性能监控、权限和认证。对于高影响或特权动作，文件建议使用即时凭证，在每次特权调用前重新验证身份和授权，并通过集中策略决策点在运行时持续验证每个请求。

这套方法本质上是在说：Agent 不能一次授权、永久运行、事后追责。它需要动态授权、持续监控、实时拦截和可回滚机制。

六、对国内 AI 安全产品的启发

这份文件对国内 AI 安全产品最直接的启发，是产品边界要扩大。

如果大模型只是问答系统，内容安全护栏可以覆盖主要风险。但如果大模型升级为 Agent，安全产品就必须进入执行链路。未来企业真正需要的，可能不只是“输入输出审核 API”，而是一个 Agent 控制平面。

这个控制平面至少要管理几类对象。第一是身份，明确每个 Agent 是谁、属于哪个业务、拥有什么角色、是否可信、是否经过注册。第二是权限，控制 Agent 能访问什么数据、能调用什么工具、能执行什么动作、权限是否临时、是否可撤销。第三是工具，管理工具来源、版本、描述、调用策略和返回结果可信度。第四是上下文，区分用户输入、系统指令、工具返回、外部网页、记忆内容之间的信任等级。第五是运行时行为，记录 Agent 的任务目标、规划路径、工具调用、数据访问、动作执行和异常偏离。第六是审计与恢复，保证出了问题之后能够解释、暂停、回滚、隔离和追责。

这其实意味着，Agent 安全会从“内容安全”扩展到“行为安全”，再进一步扩展到“系统安全”。

国内很多大模型安全产品过去习惯从文本风险出发，围绕涉政、违法、伦理、歧视、隐私、幻觉、越狱做检测。这个方向仍然重要，但 Agent 场景还会新增一组问题：是否越权、是否误调用工具、是否污染记忆、是否泄露数据、是否删除日志、是否绕过审批、是否在多 Agent 链路里扩散错误、是否被第三方组件操纵。

从这个角度看，Agent 安全的商业机会不会只在模型评测，也不会只在内容过滤，而会在企业 AI 基础设施层形成新的安全控制面。

七、释放的监管信号

这份劝告书释放了一个很清晰的监管信号：关键基础设施和政府系统不会允许高权限 Agent 裸奔上线。

过去，很多 AI 应用可以先上线，再逐步补安全。Agent 场景里，这种路径会变得危险。因为 Agent 一旦进入业务系统，它的错误不只是内容错误，而是动作错误；不只是用户体验问题，而是权限、数据、资产和业务连续性问题。

文件结论部分也强调，在安全实践、评估方法和标准成熟之前，组织应该假设 Agentic AI 系统可能出现意外行为，并相应规划部署方式，优先考虑韧性、可逆性和风险 containment，而不是单纯追求效率收益。

这句话很关键。它说明监管机构并不反对 Agent，但要求企业改变采用姿势。Agent 可以用，但要先从低风险任务开始；可以放权，但要逐步放权；可以自动执行，但高影响动作必须有人审；可以连接工具，但必须有身份、权限、隔离、审计和恢复。

写在最后

Agent 被寄予很高期待，因为它让 AI 从“回答问题”走向“完成任务”。但任务完成能力越强，系统风险也越强。

这份由多国网络安全机构共同发布的劝告书，本质上是在提醒企业：不要把 Agent 当成一个更聪明的聊天机器人，也不要把它当成普通自动化脚本。它更像一个带有推理能力、工具访问能力和一定自主性的数字员工。这样的系统进入企业核心流程之前，必须先解决身份、权限、工具、上下文、记忆、审计、审批、隔离和恢复问题。

未来 Agent 能不能真正进入关键业务，不取决于模型能不能规划复杂任务，而取决于组织能不能回答几个更基础的问题：它是谁，它能做什么，它为什么这么做，它调用了什么，它访问了什么，它是否越权，出了问题能不能停下来，能不能解释，能不能回滚。

Agent 安全的下一个阶段，已经不只是给模型加护栏，而是给智能体建立一套可控、可观测、可追责的运行时安全基础设施。