2026 年 5 月，Anthropic 发布了一份面向企业 AI Agent 部署的安全白皮书：《Zero Trust for AI Agents》。
https://claude.com/blog/zero-trust-for-ai-agents
这份材料讨论的不是普通意义上的“大模型内容安全”，也不是简单的提示词防护，而是一个更底层的问题：当 AI Agent 开始拥有身份、工具、权限、记忆和自主执行能力之后，企业到底应该如何重新设计安全架构？
Anthropic 在官方介绍中提到，这份框架覆盖 Agent 特有威胁、分层零信任架构、八阶段实施流程，以及用于应对 AI 加速攻击的 Agentic SOAR 安全运营体系。
它的核心判断很直接：Agent 不是普通聊天机器人，而是一个可以理解目标、调用工具、访问数据、执行动作的自治系统。
传统访问控制很难阻止 Agent 滥用“本来就合法”的权限，因此企业必须从一开始就按照“默认不可信、持续验证、假设已被攻破”的原则来部署 Agent。
为什么 Agent 需要零信任
过去很多企业做大模型安全，关注点主要在“输入”和“输出”上。输入有没有违法有害内容，输出是否违规，模型是否被越狱，回复是否安全。
但 Agent 出现以后，问题变复杂了。
Agent 不只是回答问题，它会拆解任务、选择路径、调用工具、读取系统、写入数据、发送邮件、操作代码仓库，甚至和其他 Agent 协同完成任务。它的风险不再只是“说错话”，而是可能真的“做错事”。
一个客服 Agent 如果被诱导错误调用 CRM 和邮件工具，可能把客户数据发到外部邮箱；
一个代码 Agent 如果被间接提示注入控制，可能在仓库里植入恶意逻辑；
一个企业管理 Agent 如果拥有高权限，又把权限传递给低权限子 Agent，就可能造成权限扩散；
一个拥有长期记忆的 Agent 如果被投毒，风险可能不止影响当前会话，还会持续影响未来的决策。
这就是 Agent 安全和传统大模型安全最大的区别：大模型安全更多是在管生成内容，Agent 安全是在管自治行为。
零信任本来就是为了解决传统边界安全失效的问题。NIST SP 800-207 对零信任架构的定义强调，安全防御要从静态网络边界，转向以用户、资产和资源为中心，不再因为请求来自内网、来自某个设备或属于企业资产，就自动赋予信任。
把这个思想放到 Agent 时代，逻辑就很清楚了：不要默认 Agent 是可信的，不要默认它理解了真实意图，不要默认它调用工具一定合理，不要默认它的记忆没有被污染，也不要默认它持有的权限不会被滥用。
Agent 可以被诱导，可以误判，可以被上下文污染，可以被工具链攻击，也可以成为攻击者横向移动的新跳板。因此，安全架构必须默认 Agent 迟早会出问题，然后通过身份、权限、隔离、审计、回滚和响应机制，把损害控制在可接受范围内。
Agent系统的五大风险
Anthropic 在白皮书中把当前 Agentic System 的主要风险概括为几类。它们看起来都和大模型有关，但实际上已经超出了普通模型安全的范畴。
第一类风险，是提示注入与指令操纵
提示注入仍然是 Agent 安全中最基础、也最难彻底解决的风险。
直接提示注入比较好理解，就是攻击者在用户输入中写入恶意指令，诱导模型忽略系统提示、绕过策略约束、泄露信息或执行不该执行的动作。
更危险的是间接提示注入。攻击者不直接向 Agent 下指令，而是把恶意指令藏在网页、邮件、文档、代码注释、RAG 知识库或工具返回内容中。用户可能完全看不见这些内容，但 Agent 在处理外部数据时会把它们读进上下文，并可能误认为这是应该执行的任务指令。
这类问题的关键难点在于，大模型天然处理的是语言序列，它并不总能稳定地区分“这是一段待分析的数据”和“这是一条应该执行的命令”。Microsoft Research 提出的 Spotlighting 技术，就是通过明确标记不可信内容，帮助模型区分外部数据和系统指令；其实验显示，该方法可以把间接提示注入攻击成功率从超过 50% 降到 2% 以下。
对 Agent 来说，提示注入的后果比普通聊天机器人更严重。聊天机器人被诱导后，可能只是输出不当内容；Agent 被诱导后，可能真的去调用工具、读取数据、发送请求、修改文件。
第二类风险，是工具和资源误用
Agent 的能力很大程度上来自工具。没有工具，Agent 只是一个会推理的模型；接入工具以后，它才真正变成可以执行任务的系统。
问题也正出在这里。
如果 Agent 可以访问数据库、邮件系统、CRM、代码仓库、云平台、MCP Server 或内部 API，那么攻击者不一定需要攻破这些系统本身，只需要诱导 Agent 合法调用工具，就可能完成数据窃取、越权操作或资源消耗。
更麻烦的是工具链攻击。单个工具看起来可能都是安全的，但多个工具组合起来就可能产生新的风险。比如 CRM 工具只允许读取客户信息，邮件工具只允许发送邮件，单独看都没有明显问题；但如果 Agent 被诱导先读取客户信息，再通过邮件工具发出去，这两个合法工具就组合成了一条数据外泄链路。
所以，Agent 的安全边界不应该只是系统提示词，而应该是工具权限本身。提示词只能影响模型行为，工具策略才能真正约束行为。
第三类风险，是身份与权限滥用
企业里的 Agent 很可能会使用服务账号、API Token、OAuth 凭证、云权限或内部系统账号。传统 IAM 更多是围绕人类用户和静态服务设计的，但 Agent 既像用户，又像服务，还会自主拆分任务、调用子 Agent、跨系统协同。
这会带来几个新问题。
高权限 Agent 可能把完整权限传给低权限子 Agent；低权限 Agent 可能诱导高权限 Agent 代它执行操作；Agent 可能缓存上一次会话中的凭证或敏感上下文，导致后续会话发生跨会话提权；多个 Agent 如果共用同一个服务账号，一旦出事，审计时很难知道到底是谁做了什么。
这类风险的本质不是“没有权限控制”，而是传统权限控制没有理解 Agent 的行为特点。Agent 不只是访问资源，它还会解释意图、代理行动、传递任务和组合权限。因此，Agent 时代需要的不只是最小权限，而是 Anthropic 和 OWASP 都提到的“Least Agency”，也就是最小代理权。
最小权限主要限制“能访问什么”，最小代理权进一步限制“能做什么、什么时候做、以什么频率做、在什么上下文中做、是否需要升级审批”。
第四类风险，是供应链和依赖风险
Agent 的供应链比传统软件更复杂。
传统软件供应链主要关注代码依赖、开源包、构建产物和运行环境。Agent 的供应链还包括模型、微调数据、RAG 数据源、工具描述、MCP Server、插件、外部 API、Agent Persona、配置文件和长期记忆。
任何一个环节被污染，都可能影响 Agent 的行为。
如果 MCP Server 的工具描述被篡改，Agent 可能以为自己调用的是正常工具，实际却触发恶意行为。如果 RAG 知识库被插入恶意内容，Agent 可能持续引用错误事实或执行隐藏指令。如果模型或微调数据存在后门，Agent 在特定触发条件下可能表现出完全不同的行为。
这也是为什么白皮书强调 AI-BOM。传统软件有 SBOM，用来记录软件组件和依赖关系；Agent 系统也需要类似的 AI-BOM，用来记录模型来源、训练数据、微调参数、工具组件和运行依赖。否则一旦出现问题，企业很难知道风险来自模型、数据、工具、配置，还是某个第三方服务。
第五类风险，是记忆和上下文投毒
长期记忆是 Agent 产品体验的重要能力，也是很容易被低估的安全资产。
普通提示注入往往只影响当前会话，但记忆投毒会影响未来。攻击者可以通过一次正常交互，把恶意偏好、错误事实、隐藏规则或工具调用倾向写入 Agent 记忆中。之后即使攻击者离开，Agent 仍可能在未来任务中继续受这段记忆影响。
更隐蔽的是长期记忆漂移。攻击者不一定一次性植入明显恶意指令，而是通过多轮轻微污染，让 Agent 的判断标准、目标权重、工具选择和风险偏好慢慢偏离。单次变化看起来都不严重，但长期累积后，Agent 的行为已经不再符合企业预期。
这也是 Agent 安全里非常关键的一点：记忆不能只被当成产品体验能力，也必须被当成安全治理对象。
它需要隔离、溯源、校验、版本管理、保留周期、异常检测和回滚能力。
Agent零信任三层架构
白皮书最有价值的部分，是把 Agent 零信任能力拆成了三层：Foundation、Enterprise 和 Advanced。
这三层不是简单的产品版本划分，而是企业安全成熟度划分。不同规模、不同风险等级、不同监管要求的组织，可以选择不同的目标层级。
Foundation：新的最低安全基线
Foundation 不是“够用就行”的低配方案，而是 Anthropic 认为 Agent 部署必须具备的最低安全底线。
在这个层级里，Agent 至少要有唯一且可验证的身份，不能只是日志里写一个名字，而是要有密码学意义上的身份标识。Agent 访问系统时，也不应该继续依赖静态 API Key 或共享服务账号，而应该使用短期 Token，由身份提供方签发，并且权限要尽可能窄。
这意味着一个重要变化：过去很多企业认为“API Key 定期轮换”已经算比较规范，但在 Agent 和 AI 加速攻击时代，这已经不够了。因为静态密钥一旦被模型辅助代码分析、日志泄露或配置文件扫描发现，攻击者就能快速利用。轮换只是降低长期暴露风险，并不能改变凭证本身容易被窃取、复制和滥用的问题。
Foundation 层还要求基本的访问控制、身份隔离、日志记录、输入校验、输出过滤、配置版本管理和回滚流程。它解决的是一个最基础的问题：当 Agent 出事时，企业至少要知道是谁做的、用了什么工具、访问了什么资源、能不能快速停掉和回滚。
Enterprise：大多数企业真正应该追求的目标
Enterprise 层是在 Foundation 之上，补齐真实生产环境所需的治理能力。
这个层级里，Agent 身份不只是唯一标识，而是开始进入证书认证、双向 TLS、证书生命周期管理、ABAC 动态访问控制、沙箱隔离、实时日志流、不可变审计、异常检测、自动化响应和正式 AI 治理流程。
这里的重点是从“部署能跑”变成“生产可控”。
比如，一个 Agent 调用内部数据库，不只是看它有没有数据库权限，还要看它当前任务是什么、访问的数据敏感度如何、调用时间是否异常、请求量是否突然增加、是否出现和历史行为不一致的工具调用链路。
这类能力对于大规模企业非常关键。因为一旦 Agent 数量变多、工具变多、系统变多，靠人工配置和人工审批很快会失控。Enterprise 层的目标，是把 Agent 的身份、权限、行为、日志和治理流程纳入企业现有安全体系中。
Advanced：高风险场景的目标状态
Advanced 层面向金融核心系统、政务系统、医疗系统、关键基础设施、国家安全场景，或者任何“Agent 出一次事故就会造成严重后果”的部署环境。
这一层强调硬件绑定身份、远程证明、HSM/TPM、机密计算、持续授权、JIT/JEA 权限、完整 Provenance、机器学习行为检测、自愈系统和自动化策略执行。
它背后的思路是：如果 Agent 已经进入高价值系统，就不能只依靠软件配置和人工流程。身份最好绑定硬件，凭证最好不可导出，权限最好只在任务发生时临时授予，任务结束后自动收回。Agent 的每次动作都应该可追踪、可解释、可回放，异常时可以自动隔离或回滚。
这三层架构传递出的信息很明确：Agent 安全不是一个单点能力，而是一套运行体系。它需要身份、权限、工具、网络、记忆、审计、检测和恢复能力共同工作。
八阶段实施流程
如果说三层架构回答的是“企业需要建设哪些能力”，那么八阶段实施流程回答的就是“应该按什么顺序落地”。
这部分非常适合企业安全团队参考，因为它没有把 Agent 安全简化成一个网关、一个审核模型或一个提示词模板，而是把 Agent 从上线前到运行后的完整生命周期都纳入了安全流程。
第一阶段：识别需求
企业首先要明确，为什么要部署 Agent，它要完成什么业务目标，涉及哪些数据和系统，需要满足哪些监管要求，以及安全、法务、合规和业务部门分别有什么约束。
这一步看似普通，但非常重要。很多 Agent 风险不是技术能力不够，而是上线前没有定义清楚边界。一个“帮助销售团队提升效率”的 Agent，如果没有明确能不能访问客户数据、能不能发送外部邮件、能不能修改 CRM 记录、哪些操作需要人工审批，那么后续所有安全策略都会变得模糊。
Agent 不是先接上工具再说，而是先明确边界再接工具。
第二阶段：管理供应链风险
第二阶段关注模型、工具、依赖和第三方服务的供应链安全。
企业需要知道 Agent 用了哪些模型、哪些插件、哪些 MCP Server、哪些代码依赖、哪些外部 API，以及这些组件是否可信、是否签名、是否可追溯、是否存在未修复漏洞。
这里可以引入 AI-BOM，把模型来源、训练数据、微调过程、工具组件和运行依赖记录下来。对于开源依赖，则可以使用类似 OpenSSF Scorecard 的机制评估项目健康度，包括分支保护、模糊测试、签名发布、维护活跃度等。
一个很现实的问题是，很多企业代码库里会积累多个功能重复的依赖，比如多个 HTTP 客户端、多个 JSON 解析库。每多一个依赖，就多一个攻击面。白皮书甚至建议，可以让前沿模型辅助审计 lockfile，找出重叠依赖和可合并项。
这体现了一个很重要的趋势：AI 不只是带来新的安全风险，也可以反过来用于安全治理。
第三阶段：定义 Agent 边界
这一阶段要回答四个问题：Agent 允许做什么，不允许做什么，什么时候必须升级给人类审批，如果它被攻陷，最大损害范围是什么。
这里最重要的是把“模糊目标”变成“可执行边界”。
比如不能只写“客服 Agent 负责帮助客户解决问题”，而要写清楚它可以读取哪些客户数据，可以生成什么内容，是否允许发送邮件，是否允许修改订单，是否允许退款，金额超过多少必须人工审批，是否可以调用外部工具。
同样重要的是爆炸半径评估。企业要假设这个 Agent 会被攻破，然后问自己：如果攻击者控制了它，最多能拿到哪些数据，最多能调用哪些工具，最多能影响哪些用户，最多能造成多大业务损失？
如果这个答案不可接受，就说明权限还需要继续收缩。
第四阶段：防御提示注入
提示注入防御不能只靠一句“不要听用户恶意指令”。
企业需要把所有自然语言输入都视为不可信输入。用户输入、上传文档、网页内容、邮件内容、RAG 检索结果、工具返回内容，都应该经过隔离、标注、过滤和风险判断。
这里可以采用几类措施。
一是输入隔离，把系统指令、开发者指令、用户请求、外部内容和工具返回内容明确分区，避免模型把外部内容误认为高优先级指令。二是内容标记，例如 Spotlighting，把不可信内容显式标注出来。三是攻击面收缩，减少 Agent 可以接触的外部非可信内容。四是使用分类器或护栏模型，对提示注入、越狱、敏感数据泄露、危险工具调用意图进行检测。
这一步的关键不是追求“彻底消灭提示注入”，而是降低提示注入转化成真实工具操作的概率。
第五阶段：保护工具访问
工具访问是 Agent 最大的能力来源，也是最大的风险面之一。
企业应该为 Agent 建立工具白名单，只有明确批准的工具才能被调用。每个工具还应该限制能力范围，比如数据库工具默认只读，邮件工具默认只能草拟不能发送，文件工具不能访问敏感目录，云平台工具不能执行高危变更。
工具参数也需要校验。Agent 生成的 API 参数、SQL 查询、Shell 命令、HTTP 请求，都不能直接无条件执行。尤其是涉及外部发送、批量导出、资金交易、账号变更、权限调整、生产环境修改的工具调用，应该设置人工审批或更高等级的策略验证。
这里的核心原则是：不要把“Agent 会自己判断安全”当成控制手段。Agent 可以建议调用工具，但真正决定是否允许调用的，应该是外部策略引擎和工具网关。
第六阶段：保护 Agent 凭证
凭证保护是 Agent 安全的基础。
静态 API Key、嵌入配置文件的密钥、共享服务账号密码，都不应该作为 Agent 的长期认证方式。白皮书明确把这类方式视为已知缺口，而不是合格的基础安全姿态。
更合理的方式是为每个 Agent 实例分配独立身份和独立凭证，使用短期 Token、OAuth 2.0、证书认证、托管身份、Vault 或云原生密钥管理系统。凭证应该在运行时注入，不应该写死在代码、配置文件或日志中。
对于高风险生产环境，还应该考虑硬件绑定凭证。即使攻击者拿到了主机上的某些材料，也无法把凭证导出到其他环境复用。再进一步，可以使用 JIT 权限，在 Agent 执行某个具体任务时临时授予权限，任务完成后立即撤销。
这其实是在把 Agent 的权限窗口压缩到最小。
第七阶段：保护 Agent 记忆
长期记忆不能无边界保存，也不能无条件信任。
企业需要对 Agent 记忆做会话隔离、用户隔离、来源标注、完整性校验、保留周期管理和版本回滚。外部输入、工具返回结果、用户偏好、历史总结、长期知识，都应该记录来源，并区分可信等级。
如果某段记忆来自不可信网页，或者来自没有验证过的外部文档，它就不应该和企业内部可信知识处在同一安全等级。检索记忆时，也应该校验其完整性，而不是只在写入时校验一次。
记忆还应该有 TTL。尤其是来自外部内容、临时任务和高风险交互的上下文，不应该永久影响 Agent。发现记忆投毒后，企业要能够回滚到已知良好状态，而不是只能删除整个 Agent 或重建系统。
这部分对当前 Agent 产品尤其重要。因为很多产品把“记住用户偏好”当成功能亮点，但没有同步思考“如果记住了攻击者植入的偏好怎么办”。
第八阶段：度量真正重要的指标
最后一阶段不是上线，而是度量。
白皮书强调几个关键指标，其中最重要的是 dwell time 和 coverage。Dwell time 指异常发生到人类知晓之间的时间；coverage 指告警中真正被调查和处理的比例。
这两个指标非常现实。因为在 AI 加速攻击时代，攻击速度被压缩到小时级甚至更短，安全团队如果几天后才发现异常，就已经太慢了。
此外，企业还需要度量 Agent 行为是否符合预期，是否出现工具使用漂移、输出风格变化、访问模式异常、决策路径偏离等情况。对于金融、医疗、政务等高监管场景，还要能解释 Agent 为什么做出某个动作，能否追溯到触发输入、上下文、工具调用和策略判断。
Agent 不能是黑盒。越是能执行真实操作的 Agent，越需要可观测、可解释、可审计。
Agentic SOAR：安全运营也要跟上 AI 攻击速度
这份白皮书还有一个值得关注的观点：部署安全的 Agent 只是问题的一半，另一半是企业安全运营也要适应 AI 加速攻击。
过去安全运营通常假设，人类分析师查看告警、收集证据、判断影响、写处置建议、推动响应。但如果攻击者也开始使用 AI，能够在短时间内扫描大量目标、分析漏洞、生成利用代码、尝试凭证和横向移动，那么传统 SOC/SOAR 的响应速度就会显得太慢。
Anthropic 的建议不是把所有安全决策都交给 AI，而是让 AI 负责前置处理。比如自动读取告警，查询 SIEM，补充上下文，关联历史事件，生成初步研判，整理证据链，把最需要人类判断的告警推给分析师。
人类仍然应该掌握关键决策，比如是否隔离生产系统、是否吊销凭证、是否通知客户、是否公开披露。但人类不应该被证据收集、日志查询和报告撰写拖慢。
这就是 Agentic SOAR 的价值：它不是简单的自动化脚本，而是可以根据新情况进行自适应调查和响应的安全运营 Agent。
不过，防御型 Agent 自身也必须接受零信任约束。不能因为它是安全系统，就默认它一定可信。防御 Agent 同样需要唯一身份、最小权限、操作审计、完整性校验和人工升级路径。否则攻击者一旦控制防御 Agent，反而会获得更强的系统处置能力。
这份框架真正想表达什么
这份白皮书表面上讲的是 AI Agent 的零信任安全框架，但更深层的判断是：Agent 正在成为企业数字系统中的新型执行主体。
它既不是传统人类用户，也不是普通服务进程。它有语言理解能力，有任务规划能力，有工具调用能力，有长期记忆能力，也可能有跨系统协作能力。它可以把一个模糊目标转化成一串真实操作，这正是它的价值，也是它的风险。
所以，Agent 安全不能只停留在内容审核、提示词防护或模型对齐层面。真正可落地的 Agent 安全，需要把 Agent 纳入企业安全架构：
每个 Agent 都要有独立身份
每次访问都要验证
每个工具都要受控
每项权限都要最小化
每段记忆都要可治理
每次行为都要可观测
每次异常都要能响应和回滚
这也是“零信任”在 Agent 时代的真正含义：不是不使用 Agent，而是不盲目信任 Agent。
企业可以让 Agent 做更多事，但前提是要把它放在一个可验证、可限制、可追踪、可恢复的系统中。
Agent 越强，越需要零信任。
Agent 越自治，越需要边界。
Agent 越接近真实业务，越不能只靠提示词来约束。
这份框架给企业的提醒很明确：未来 Agent 安全的竞争，不只是模型能力的竞争，而是安全基础设施成熟度的竞争。
谁能更早建立 Agent 身份体系、工具治理体系、权限控制体系、记忆治理体系和自动化安全运营体系，谁就更有可能把 Agent 安全地推进生产环境。
写在最后
过去我们谈大模型安全，经常讲模型会不会越狱、回答会不会违规、内容会不会失控。
但进入 Agent 时代以后，安全问题已经从“模型说什么”升级为“系统做什么”。
一个真正进入企业生产环境的 Agent，不应该只是一个接了工具的大模型，而应该是一个被身份体系约束、被权限策略限制、被工具网关控制、被审计系统记录、被记忆治理保护、被安全运营持续监控的自治执行单元。
Anthropic 这份《Zero Trust for AI Agents》最大的价值，就在于它把 Agent 安全从“提示词攻防”推进到了“企业安全架构”层面。
Agent 不是普通应用，也不是普通账号。
它是新的数字执行主体。
而新的执行主体，需要新的信任框架。
声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
