Anthropic 发布了一份关于 AI Agent 安全的重要白皮书，探讨如何在 Agent 部署中落地 Zero Trust（零信任）原则。
当 AI Agent 开始自主执行操作、调用工具、跨系统协作时，传统的安全模型已经不够用了。
Zero Trust 是一套安全架构，核心前提很简单：不信任任何东西，必须验证一切。不管请求来自公司内网还是外部，一律验证身份和权限。这套思路 1994 年就有了，NIST 在 2020 年发了标准（SP 800-207），NSA 在 2026 年跟进了实施指南。
Anthropic 这份白皮书讲的是：当 AI Agent 开始自主执行操作、调用工具、跨系统协作时，怎么把 Zero Trust 原则落地到 Agent 部署上。
几个关键看点：
- AI 加速了攻防两端，漏洞到利用的时间窗口从几个月压缩到几小时
- 提出了"不可能还是麻烦"的设计检验标准，专治摩擦型安全措施
- 六大安全能力域，每个都给了 Foundation / Enterprise / Advanced 三级路线图
- 八步部署工作流，从需求识别到度量指标，可以直接拿来用
- 防御运营要跟上自主攻击的速度，SOAR 要进化成 Agentic SOAR
为什么 AI Agent 需要 Zero Trust
基于边界的网络安全防御已经跟不上现代威胁的节奏。前沿 AI 模型正在把漏洞到利用之间的时间窗口从几个月压缩到几个小时，边际成本按美元计。模型现在就能找到传统工具和人工审计连续几年都没发现的严重漏洞。
对部署 Agent 的组织来说，这种加速产生了双重影响。第一，Agent 运行的基础设施和你其他资产一样，暴露在 AI 加速的攻击面前。第二，Agent 本身引入了自主性，能解读目标、选择工具、执行多步操作。传统的访问控制挡不住 Agent 滥用合法权限，监控需要考虑那些靠持久性而非漏洞利用来得手的攻击。
苏米注：最适合应对这场变化的组织，不一定是 AI 最先进的那些。而是基本功足够扎实，以至于 AI 辅助扫描一上来就找不到几个 bug 的那些，以及从第一天就按"假设已被攻破"来设计 Agent 部署架构的那些。
三条核心原则
永远不信任，始终验证。每个访问请求都必须经过认证和授权，无论来源。来自企业内网的请求和来自外部 IP 的请求，接受同等级别的审查。
假设已被攻破。在设计系统时就预期攻破会发生。与其把精力集中在防止入侵上，不如限制攻击者能造成的损害。按身份分段，实施细粒度访问控制，确保攻破一个系统不会获得对其他系统的访问。
最小权限。只授予完成特定任务所需的最低访问权限。数据库管理员不需要访问邮件服务器。通过限制每个身份能访问的范围，组织可以控制单次攻破的爆炸半径（blast radius）。
设计测试：不可能，还是只是麻烦
评估任何控制措施时，问一个问题：这是让攻击变得不可能，还是只是让攻击变得更麻烦？
那些价值来自摩擦而非硬性屏障的缓解措施，包括额外的跳板跳转、速率限制、非标端口、基于短信的 MFA，在面对能大规模碾过麻烦步骤的对手时会大幅失效。Agent 化的攻击者有无限耐心，每次尝试的成本接近于零。
能通过这个测试的控制措施有一个共同模式：硬件绑定的凭证、会过期的 token、密码学身份、以及根本不存在的网络路径（而不是只是不方便的路径）。拿不准的时候，优先选择移除能力的控制，而不是限流能力的控制。
Agent 系统有什么不同
Agent 式 AI 引入了现有安全模型设计时没考虑到的能力。传统软件执行预定义的逻辑，Agent 系统不一样，它们以不同程度的自主性执行多步操作。
- 无人值守执行：Agent 不需要人在每一步批准就能执行操作。一个做研究的 Agent 可能搜索网页、综合信息、产出报告，全程没有人工审核。被操控的 Agent 能以机器速度造成伤害
- 工具访问：Agent 可以与 API、数据库、文件系统和外部服务交互。这包括 MCP（Model Context Protocol）。一个被攻破的 MCP 栈可能导致数据窃取、恶意代码执行和破坏
- 决策能力：Agent 需要解读指令并选择如何完成目标。一条对人类来说看起来无害的指令，可能被 Agent 解读为能实现完全不同结果的方式
- 上下文持久化：Agent 可以在会话间维持记忆。记住之前的交互让 AI 助手更能干，但也产生了新的数据保护需求
- 多 Agent 协作：Agent 可以与其他 Agent 通信。这种信任关系让攻击者可以攻破一个 Agent 然后横向移动，到达初始目标无法直接访问的系统
两个新概念
爆炸半径（blast radius）：衡量出问题时的潜在损害范围。只读访问单个数据库的 Agent，爆炸半径很小。有云基础设施管理员权限的 Agent，爆炸半径巨大。安全投入应该匹配这个暴露程度。
最小代理权（least agency）：是 OWASP 造的新术语，把最小权限原则延伸到了 Agent 应用。最小权限约束的是用户和系统能访问什么，最小代理权走得更远，限制每个 Agent 工具能做什么、多频繁、在哪里。比如：数据库工具只拿到只读查询权限，邮件摘要工具没有发送/删除权限。
当前威胁：提示注入与指令操控
直接注入：攻击者构造输入来覆盖系统指令。手段包括显式指令覆盖、Base64 等编码方案绕过过滤器、以及对人类毫无意义但能影响模型输出的对抗性后缀。研究显示算法化方法可以达到 100% 攻击成功率，生成的提示可以跨模型家族迁移。
间接注入：攻击者把恶意指令嵌入 Agent 会处理的外部数据源，比如网页或邮件。Microsoft Research 确认，LLM 无法可靠地区分信息性上下文和可执行指令。用户永远看不到恶意载荷，Agent 把它当成合法请求执行了。
工具和资源滥用
拥有工具访问权的 Agent 可以被操控为恶意使用这些工具，即使在授权权限范围内。传统的访问控制挡不住这种攻击。
- 工具中毒：攻击者入侵 MCP 工具描述符、schema 或元数据。第一个有记录的野外恶意 MCP 服务器冒充了合法邮件服务，暗中复制了所有发出的邮件
- 工具链攻击：攻击者骗 Agent 把合法工具以有害顺序组合，比如把内部 CRM 工具和外部邮件工具串联来窃取客户数据。因为每条命令都通过可信二进制文件在有效凭证下执行，主机端监控看不到恶意软件
- 资源耗尽：循环放大让 Agent 反复调用高成本 API，造成拒绝服务或账单飙升
身份与权限滥用
无范围权限继承：高权限的管理 Agent 委派任务时没做最小权限约束，把完整的访问上下文传给了本应权限有限的工作 Agent。被攻破的低权限 Agent 向高权限 Agent 转发看起来合法的指令，后者直接执行而没有验证原始用户的意图。当 Agent 常规性地协调和委派时，这个"困惑代理人"问题会被放大。
基于记忆的权限留存：Agent 缓存凭证或密钥用于上下文复用但没有做好记忆分段。攻击者可以提示 Agent 用之前安全会话中缓存的密钥执行操作，跨会话边界提升权限。
供应链和依赖风险
和静态的软件供应链不同，Agent 生态系统经常在运行时组合能力，动态加载外部工具和 Agent 角色。
- 模型供应链风险：被投毒的权重和污染的微调数据引入的后门。Anthropic 研究表明，只需 250 个恶意文档就能在 6 亿到 130 亿参数的 LLM 中植入后门，且后门在安全训练（包括监督微调和 RLHF）后仍然存在
- 工具和框架供应链风险：影响 MCP 服务器、API 集成和 Agent 框架。PyTorch 依赖混淆攻击演示了恶意包如何在安装过程中窃取 SSH 密钥。安全研究人员在主要平台上发现了约 100 个恶意 AI 模型
记忆和上下文投毒
植入到助手记忆中的恶意指令可以危害当前和所有未来的会话。Agent 在初始注入之后很久仍在为攻击者的目标服务。
- RAG 投毒：通过被投毒的数据源向向量数据库注入恶意数据。Agent 检索到被污染的上下文后，产出错误答案或执行针对性载荷
- 共享上下文投毒：利用多租户环境中复用或共享的上下文。长期记忆漂移更微妙：摘要或同伴 Agent 的反馈逐步偏移存储的知识，因为没有单个改变看起来是恶意的，很难检测
六大安全能力域
本文档的剩余部分是实施指南。原则按三个能力等级呈现：
- Foundation：中小型团队的起步点。AI 加速攻击已经抬高了 Foundation 的地板：短命 token、密码学身份、基于身份的隔离和自动化初步分诊现在是入门要求
- Enterprise：大多数有规模部署的组织应该瞄准的目标
- Advanced：高度监管行业、国家安全应用、或攻破带来严重后果的场景
每个等级建立在前一个之上。预期 Advanced 会随领域演进变成 Enterprise 标准，Enterprise 变成 Foundation。
Agent 身份与认证
身份和认证构成所有其他安全能力的基础。没有可验证的身份，你无法执行访问控制、维护审计追踪、或将动作归因到具体的 Agent。
唯一标识符单独来看只是贴标签。Foundation 级别现在要求这些标识符有密码学根基。静态 API 密钥和共享服务账户密码是 AI 辅助攻击者最先找到的东西，即使在 Foundation 级别也不是合法入口。
苏米注：如果你现在在用带轮换策略的 API 密钥，把它当作已知缺口来对待。轮换一个可以从 lockfile 里 grep 出来的凭证，对 AI 辅助攻击者来说提升的成本微乎其微。
访问控制和权限管理
即使完美认证的 Agent，在被授予过多权限时也会造成损害。授权层执行最小代理权。
最低限度，Agent 只应该拥有与其角色相关的权限。邮件起草 Agent 需要邮件权限，不需要访问财务部门的文件共享。沙箱执行限制了被攻破的 Agent 能触达的范围。对处理网页内容、文档或任何不可信输入的 Agent 来说，沙箱应该被视为必需而非愿景。
可观测性和审计
访问控制防止未授权的动作。可观测性揭示实际发生了什么。在检测方面做其他投入之前，先度量两件事：驻留时间（异常发生到人类知晓的时长）和覆盖率（实际被调查的告警比例）。
行为监控与响应
可观测性捕获 Agent 做了什么。行为监控判断这些动作是正常的还是可疑的。
检测异常只有在你响应得足够快以控制损害时才有意义。自动化事件周围的事务性工作，不要自动化决策。模型应该做笔记、捕获证据、起草事后报告。人类应该做遏制决策、披露决策和客户沟通决策。
输入验证和输出控制
监控和响应在威胁出现之后捕获它们。预防在威胁开始之前就阻止它们。
输入清洗不能从传统技术直接搬到 Agent 上。SQL 注入有明确定义的模式和受限的输入字段，但 Agent 的输入是自由形式的。Advanced 级别增加了聚光灯技术（spotlighting），利用已知 schema 帮助 LLM 区分系统指令和用户输入。宪法分类器（constitutional classifiers），Anthropic 的方法在测试中阻止了 95% 的越狱尝试。
完整性和恢复
当控制措施到位但仍发生攻破时，你需要已验证的配置和快速恢复。
在基础设施层面，把"启用自动更新"和"部署前验证签名"视为互补而非矛盾。来自可信供应商的签名更新应该自动通过，未签名的变更应该直接拒绝。
技术控制只能执行治理定义的东西。没有清晰的策略，团队会在 Agent 能做什么、出了问题谁负责等问题上做出不一致的决定。影子 AI 是特别的风险：员工在 IT 不知情的情况下采用 LLM 工具，绕过了框架中的所有控制。
八步部署工作流
成功的 Agent 实施需要一个定义清晰的、可重复的流程。每个阶段处理特定的安全控制，同时缓解已识别的威胁。
Phase 1：识别需求
定义你需要满足什么监管要求、要达成什么运营目标、在什么约束条件下工作。在开始构建之前，让安全、法务、合规和业务利益相关者达成一致。
Phase 2：管理供应链风险
AI 物料清单（AI-BOM）：将软件组成分析延伸到 AI 组件，追踪模型来源、训练数据集血统和微调参数。将 AI-BOM 整合到现有供应链安全流程中。
用OpenSSF Scorecard自动评估每个依赖的安全健康度。审计依赖树的冗余。用可达性分析缩小修复范围。对安全评分差且无人维护的小型依赖，让前沿模型重新实现你实际使用的功能子集。
Phase 3：定义 Agent 边界
精确定义每个 Agent 被允许做什么、什么时候应该升级到人工审批、以及出了问题后的爆炸半径。
- 分配唯一身份：每个 Agent 实例需要一个唯一的、有密码学根基的标识符。没有独立身份，在事件中关联日志就变成了猜测
- 批准/禁止的动作：文档化哪些动作被允许或禁止。一个被允许读取客户记录、总结信息和起草回复的 Agent 有清晰的边界。一个有模糊权限"帮忙做客户服务"的 Agent 没有
- 升级触发器：高价值交易、敏感数据访问、外部方通信都可能需要审批。定义平衡安全和运营效率的阈值
- 范围限制：限制 Agent 只能访问其功能所必需的系统。限制提供给 Agent 的账户的访问权限
- 识别爆炸半径：如果 Agent 或系统被攻破，会出什么问题？应用"不可能还是麻烦"测试
Phase 4：防御提示注入
就像需要在数据库上做输入清洗一样，我们需要控制和清洗呈现给 Agent 的信息。
- 输入隔离：将所有自然语言输入视为不可信。Microsoft 的聚光灯技术将间接注入攻击成功率从超过 50% 降到了不到 2%
- 宪法分类器：Anthropic 的方法在测试中阻止了 95% 的越狱尝试，过度拒绝率增幅很小
- 限制攻击面：限制谁或什么可以与 Agent 系统交互。如果系统可以限定为可信人员和资源，恶意行为者劫持你系统的能力将被大幅限制
Phase 5：保护工具访问
工具访问是 Agent 部署中风险最高的面之一。
- 工具白名单：将 Agent 限制在批准的工具内，默认拒绝。要在 Agent 级别和 Agent 外部两个层面控制。静态 API 密钥不适合用于工具认证，即使在 Foundation 级别
- 能力限制：限制允许的工具能做什么。邮件工具可能被限制为只能阅读，发送能力需要单独授权
- 参数验证：在执行前验证工具调用参数。参数验证应该在 Agent 端和工具端都做
- 沙箱执行：带受限网络访问和系统调用过滤的容器沙箱遏制被攻破工具的影响。速率限制是摩擦不是屏障
- 审批升级：高风险工具调用暂停等待人工审核
Phase 6：保护 Agent 凭证
静态 API 密钥、嵌入的凭证和共享的服务账户密码是 AI 辅助攻击者最先找到的东西。把它们当作已经被攻破来对待。
- 短命凭证作为基线：Token 以分钟而非天计过期。条件允许时用证书授权机构实施基于证书的身份
- 硬件绑定凭证：对生产系统，凭证应该绑定到经过证明的硬件。抗钓鱼的双因素认证（FIDO2 或 passkeys）应该是人类认证环节的默认选项。基于短信的验证码不满足 Foundation 级别
- 凭证隔离：确保每个 Agent 实例有唯一凭证。凭证永远不应出现在代码或配置文件中
- 显式信任边界：多 Agent 系统需要显式的信任边界。Agent 在接受委派任务之前应该验证其他 Agent 的身份和授权
- JIT 访问和 ABAC：只在需要时授予权限，使用后立即撤销。这被认为是高级 Zero Trust 实施和非常强的威胁缓解手段
Phase 7：保护 Agent 记忆
记忆保护阻止攻击者污染 Agent 上下文或从记忆存储中提取敏感信息。和针对单个会话的攻击不同，记忆投毒跨交互持续存在。
- 记忆隔离：在会话和用户之间强制严格的边界
- 上下文完整性验证：在每次检索时验证持久化的上下文，不仅是存储时。将哈希存储在与记忆内容分离的防篡改日志中
- 上下文保留策略：通过生存时间值和自动过期未验证的记忆，防止被投毒内容无限期保持活跃
Phase 8：度量真正重要的东西
当 Agent 系统作为黑盒运行时，你无法判断它们是在交付预期结果还是已被攻破。
- 驻留时间和覆盖率：在做其他任何事之前先度量这两个指标。这是 AI 自动化最有杠杆撬动的两个指标
- 可解释性：你能否将任何 Agent 动作追溯到其触发输入并解释 Agent 为什么选择那个响应
- 行为一致性：追踪 Agent 动作是否与预期策略和模式一致。突然偏好不同工具的 Agent 值得调查
- 检测速度：度量团队多快能意识到 Agent 行为异常。对关键系统的目标是一小时内检测到
苏米注：安全团队应该能回答：如果一个 Agent 失控了，我们能在一小时内知道吗？如果答案不确定，基础控制需要更多工作。
以自主威胁的速度运行防御运营
保护你部署的 Agent 只是一半工作。另一半是让安全运营跑得足够快。当漏洞利用在补丁发布几小时内就出现时，需要几天的响应流程就太慢了。
答案不是把人从环里移除，而是把人从事务性工作上移到决策上。自动化证据收集、丰富、关联和文档。让人类做遏制决策、披露决策和客户沟通决策。
- 在告警队列前面放一个模型：每条进入的告警在人类看到之前都应该得到一次自动化的初步调查。选一条已知高误报率的嘈杂规则，把前沿模型接入它的告警流，让它为每次触发产出结构化处理意见。和人类审查员对比两周。不要试图一次自动化整个队列
- Agentic SOAR：今天的 SOAR 平台让安全团队能整合和协调独立的安全工具。下一代是 Agentic SOAR，增加了应对新情况的自适应能力，在几秒钟内直接应对恶意 AI 驱动攻击
- 按 MITRE ATT&CK 映射检测覆盖：知道你能检测哪些技术、不能检测哪些，比笼统地"改善检测"更有用。优先覆盖横向移动和凭证访问。Atomic Red Team 是一个开源库，跑几个测试看看你现有的日志实际检测到了哪些，这是一个下午的练习
- 为五个同时发生的事件做桌面推演：标准推演假设周一出了一个关键 CVE。跑一个同一周出了五个的版本。围绕电子表格和每周会议构建的工作流跟不上。为发现量的数量级增长做计划，在它发生之前排练
- 提前建立紧急变更程序：生产补丁的两周变更审批周期本身就是安全风险。下线一个服务、轮换一个凭证、阻断一条网络路径，提前决定谁能授权、多快能授权、需要什么证据。演练授权路径
- 对防御型 Agent 也要验证：组织不应该盲目信任防御自动化，正如不应该盲目信任其他自主系统一样。攻破防御型 Agent 的攻击者会获得强大的能力。防御型 Agent 应该运行在加固的环境中，以最小权限运行，自动响应需要人工审批高影响决策
从原则到实践
Agent 面临的威胁和传统 IT 不同。Zero Trust 提供了应对的框架。
验证每个 Agent 动作，授予最低必要权限，在攻破发生时控制损害。身份支持归因和访问控制。可观测性揭示发生了什么。行为监控检测异常。输入输出控制在边界阻止攻击。完整性保护支持恢复。防御运营以威胁的速度运行。跳过任何一项能力，攻击者就会利用那个缺口。
从 Foundation 级别开始，但要认识到 Foundation 的地板已经被抬高了：短命 token、密码学身份、基于身份的隔离和自动化初步分诊现在是入门要求，不是愿景。随部署规模和风险增长系统性推进。
对受监管行业，HIPAA、FINRA、GDPR、FedRAMP 和 EU AI Act 已经施加了与 Zero Trust 对齐的要求。合规截止日期在逼近，竞争压力意味着 Agent 部署不会减速。
苏米注：合规截止日期是真的，威胁图景在变，事后加装控制比一开始就建好更贵。这份白皮书给你的团队一个具体的起点。对架构师和工程师：从 Foundation 开始，验证你的控制，随部署规模推进等级。把"不可能还是麻烦"测试当作常设的设计评审问题。威胁会演化，你的防御也应该。