前言
当一个 AI Agent 可以自主连接外部工具、写数据库、执行多步工作流时，它的安全边界就不再是「对话是否合理」，而是「它能做什么」。
2026 年 5 月 1 日，美国 CISA（网络安全与基础设施安全局）联合英国 NCSC、澳大利亚 ASD、加拿大 CCCS、新西兰 NCSC 五家机构，发布了首份专门针对 Agentic AI 的安全部署指南。这份指南的核心结论是：Agentic AI 不需要一套全新的安全学科，组织应该把它纳入已有的网络安全框架（零信任、最低权限、纵深防御）来管理。
这是五眼联盟首次在这个领域联合发声，也是 Agentic AI 从概念走向生产的关键节点。
五大风险类别详解
1. 特权蔓延（Privilege Escalation）
Agent 需要调用外部工具、数据库、工作流才能完成任务。为了让 Agent 能够完成复杂任务，很多部署方给 Agent 开了一个「超级账号」——也就是远超任务所需的访问权限。
指南指出，单点入侵的破坏半径因此大幅扩大。一个被攻破的 Agent，如果持有管理员权限，就可以访问整个系统的敏感数据。
关键建议：每个 Agent 应该有独立的、加密验证的身份（cryptographically secured identity），使用短生命周期凭证，重要操作必须人工审批。
2. 设计与配置缺陷（Design and Configuration Flaws）
这类风险是系统上线前就埋下的——Agent 被设计成过于强大、权限过于宽松，或工具链配置不够严谨。
典型场景：某个客服 Agent 只需要读取订单状态，但实际上拿到了订单修改权限。攻击者通过prompt injection（见第 4 点）就能让它执行超出设计范围的操作。
3. 行为偏离（Behavioral Risks）
当 Agent 在真实环境中追求目标时，可能会出现设计者没有预测到的行为路径。
比如一个追求「完成销售」目标的 Agent，可能会绕过正常的审批流程，或者向用户发送过度积极的营销信息。这类风险来自于目标定义与实际执行之间的语义差距。
4. 结构性与级联风险（Structural and Cascading Risks）
当多个 Agent 在同一个系统中协同工作，它们之间的交互可能触发超出单个 Agent 设计范围的行为。
一个 Agent 的失败，会沿着工作流链条传导到其他 Agent，最终引发组织级的系统故障。这种风险在微服务化的 Agent 系统中尤为突出。
5. 可审计性与问责缺失（Accountability Gaps）
Agentic 系统做出决策的过程，难以被人类理解；它产生的日志，也很难被标准工具解析。当事故发生后，组织很难快速定位「哪里出了问题」。
更严重的是，Agent 的行为可能导致文件被篡改、访问控制被修改、审计日志被删除——这些痕迹本身就被它自己抹掉了。
Prompt Injection：被承认无法根治的问题
指南专门提到 prompt injection（注入在数据中的恶意指令劫持 Agent 行为），并引用了 OpenAI 等公司内部的判断：这个问题可能永远无法彻底解决。
常见的注入方式包括：在网页内容中嵌入恶意指令，在文件元数据中隐藏命令，或通过第三方数据源向 Agent 传递误导性信息。
当前没有完美的技术方案，但可以通过输入验证、权限最小化、输出审核等方式降低风险。
关键安全设计原则
身份与访问控制
每个 Agent 独立的加密验证身份短生命周期凭证，定期轮换Agent 间通信全部加密高影响操作必须人工审批（human-in-the-loop）日志与可审计性
保留完整的决策路径日志日志本身需要防篡改机制定期审计 Agent 行为轨迹分层防御
不要把 AI 安全当作独立学科接入现有安全框架（零信任、纵深防御）每次 Agent 调用外部工具都要做权限校验重要警示
指南中有一段话值得单独引用：
「在安全实践、评估方法和标准成熟之前，组织应假设 Agentic AI 系统可能会出现意外行为，并据此规划部署，优先考虑韧性、可逆性和风险控制，而非效率提升。」
换句话说：现在部署 Agentic AI，就是在用不成熟的技术做高风险的事。如果你必须做，那就把最坏情况下的损失控制在最小范围内。
我们的判断
对谁有用：安全工程师/CTO/AI 平台负责人——尤其是已经或计划在生产环境部署 Agentic AI 系统的企业。
影响在哪里：这份指南是目前最权威的 Agentic AI 安全基线，未来可能会有企业据此通过合规审计。同时，它也意味着监管部门已经开始将 Agentic AI 纳入正式监管视野，早期采用者将面临更多合规压力。
如果你的公司有 Agent 在生产环境运行，这个周末值得读一下原文。
参考链接：