零风险并非职责所在：CISO 的智能体 AI 指南
Zero risk isn't the job: a CISO's guide to agentic AI
Anthropic 的副首席信息安全官 Jason Clinton 分享了其团队在采用智能体 AI 过程中汲取的经验教训，以及他们为安全构建和部署智能体而开发的风险评估框架。
安全领导者们正被要求批准那些几个月前甚至还不存在的智能体 AI 用例。董事会想知道这些用例是否都处于受控状态，而在你的组织内部，可能已经有员工在未告知你的情况下将某个智能体连接到了某些系统。
对这些请求说“不”会导致影子采用（shadow adoption），这种采用方式完全没有遥测数据，通常也没有关闭开关。在没有控制措施的情况下说“是”则会引发安全事件，而你公司发生的第一个严重智能体事件将使你的 AI 项目倒退。
在智能体 AI 时代，CISO 的责任并非实现零风险。相反，我们的工作是让智能体风险变得清晰可见且可控。这样，我们就能审慎地接受那些我们可以管理的风险，从而让业务按照我们的节奏前进，而不是绕过我们。
在这篇文章中，我将分享我们用于评估智能体安全风险的框架，解释“可控”在实践中的含义，并展望我们未来的工作方向。
后 Mythos 时代：来自 AI 的外部风险与内部风险
External risk from AI versus internal risk in the post-Mythos era
在早些时候的一篇博文中，我和同事们分享了 AI 如何缩短了漏洞存在到出现可用利用代码之间的时间，并强调了组织如何缓解这些风险。在接下来的几个月里，我们预计，大量在代码中潜伏多年、甚至未被发现的漏洞，将被 AI 模型发现并串联成可用的利用代码。像 Claude Mythos Preview 和 Claude Mythos 5 这样的前沿模型已经发现了许多人类多年审查都未能发现的严重漏洞，包括在 OpenBSD、Linux 内核和 Mozilla Firefox 中发现的漏洞。
这些对任何治理、风险与合规（GRC）项目来说都是严重的风险。缓解和消除漏洞差距，以及为即将到来的利用浪潮做好准备，应成为首要任务。关于这个主题，我们准备了另一份文档：《为你的安全项目应对 AI 加速的攻击做好准备》。本指南将重点讨论内部风险。
治理内部风险
Governing internal risks
对于许多组织来说，智能体系统最可能的威胁向量是数据泄露，这种泄露是由于通过缺乏足够监督的个人智能体连接不同系统而导致的。另一个担忧是提示注入（prompt injection）：攻击者将指令隐藏在智能体读取的内容中，导致智能体遵循攻击者的指令而非用户的指令。任何接触不受信任内容的智能体都可能面临风险，具体取决于模型防御能力的强弱。随着模型能力不断增强，它们在抵抗注入方面的表现也越来越好。虽然攻击成功率持续下降，但并非为零。除了这两个例子之外，还有许多其他担忧，而层出不穷的新问题可能让人应接不暇。
需要提出的四个问题
当一个智能体用例进入我们的审查流程时，我们通过提出四个问题来评估其风险：
- 它摄入了哪些不受信任的内容？ 不受信任意味着任何攻击者可能编写或篡改的内容，包括外部邮件、开放网络、第三方文档或公共代码仓库。如果答案是“没有”，那么智能体特有的风险接近于零，你应该快速推进。
- 它可以采取哪些行动，以及代表谁采取行动？ 只读与读/写是不同级别的担忧。工具调用、代码执行和网络出站都会扩大风险敞口。每个行动都在某个身份下进行，你需要知道是谁的身份。
- 如果它出现偏差，爆炸半径（blast radius）有多大？ 范围乘以严重性是快速计算方式：恶意行为者或对齐事件是访问了一个文件还是整个组织？这会是异常、烦恼、数据泄露，还是真正的事件？
- 我拥有怎样的可观测性？ 你能区分智能体行为和用户行为吗？这些行为是否会进入你的安全信息和事件管理（SIEM）系统？
这四个问题的答案能让你了解自己的风险状况，但最小代理权限原则（principle of least agency）会告诉你该怎么做：授予完成该任务所需的最窄能力（更多信息请参阅我们的《AI 智能体的零信任》白皮书）。在 Anthropic，我们的默认姿态是管理员控制下的逐步推广：先启用一个小群体，观察遥测数据，然后扩大访问权限。将这些问题应用于思考风险智能体系统的新范式。
一个偏离你意图的智能体与内部攻击无异。安全行业在 2019-2022 年间将内部风险正式确立为一个独立于边界防御的学科——认识到系统中一个最危险的外部攻击向量往往是那些已经拥有合法访问权限的账户。
操作上的区别在于响应时间：Ponemon Institute 的《2026 年内部风险成本报告》发现，组织平均需要 67 天才能控制住一起内部事件——即使经过多年对专门内部风险项目的投资。以智能体的执行速度来看，以天为单位的响应时间太长了。
智能体身份谱系
The agentic identity spectrum
我们部署的每个智能体都位于身份访问模型谱系的两端之一。
一端是系统服务账户：一个自包含、单一用途、最小权限的身份，为业务执行恰好一项任务，不附加任何人类身份。事件响应智能体（见下文）、工单分类智能体或自主代码审查员都是这类例子。另一个例子是 Claude Tag，我们新的共享工作区智能体，它允许人类团队通过在 Slack 等共享工作区中标记 Claude 来与智能体协作。
另一端是人类凭证。当员工在其笔记本电脑上使用聊天界面或个人智能体工具（如 Claude Cowork）时，键盘前的人对结果负责，就像他们对使用自己凭证所做的任何其他事情负责一样。
在谱系的中间地带，智能体携带个人的委派身份进入该人未监控的系统，这时责任归属就变得模糊不清。责任模糊不清正是事件变得无法解释的原因。
一个偏离你意图的智能体与内部攻击无异。安全行业在 2019-2022 年间将内部风险正式确立为一个独立于边界防御的学科——认识到系统中一个最危险的外部攻击向量往往是那些已经拥有合法访问权限的账户。
Ponemon Institute 的《2026 年内部风险成本报告》发现，组织平均需要 67 天才能控制住一起内部事件——即使经过多年对专门内部风险项目的投资。以智能体的执行速度来看，67 天这个度量单位完全不对。
案例研究：事件响应智能体
Case study: an incident response agent
一年多以前，我们将 Claude 应用于我们的事件响应流程。任何为生产应用待过命的人都知道这个问题：凌晨 2 点你因安全事件被传呼，你启动一个事件响应频道，召集相关人员，然后开始工作。这个过程繁琐、文档密集且进展迅速。但是，如果拥有关于生产环境代码库的正确上下文，大部分工作都可以自动化。
因此，我们构建了一个智能体来完成这项工作。我们授予了该智能体三个工具的访问权限：对我们生产日志的只读访问权限（这些日志不包含个人身份信息 PII）；访问 Slack 以打开事件频道并运行流程；以及在事件解决后起草事后分析 Google 文档的能力。
我们用四个问题对其进行了评估：
- 不受信任的内容： 无。输入是我们自己的日志和我们自己的内部 Slack，都在信任边界内，因此注入需要内部人员或受损账户，而不是匿名攻击者。
- 行动： 到处可读，写入仅限于新文档和 Slack 消息。没有编辑或删除，没有权限更改，没有外部端点。
- 爆炸半径： 我们能构想的最坏结果是，一些轻度敏感的日志行被发布到一个已经锁定的事件频道中。
- 可观测性： 每个行动都记录在我们的 SIEM 中，因此任何意外情况都会在几分钟内显现，而不是几周。
虽然这个智能体并非无风险，但它在具有完全审计覆盖的受限写入表面上运行，这是我们感到满意的风险状况。
然而，这个故事有一个有趣的补充：随着每个模型版本的发布，智能体变得越来越聪明。2025 年 11 月，我们将这个智能体从 Claude Opus 4 迁移到 Claude Opus 4.5，没有改变其他任何东西——没有新工具、权限或提示。此后不久，智能体首次仅凭智能提升就足以在事件处理过程中注意到，它已经在堆栈跟踪中找到了根本原因，并且在相关人员尚未到达的情况下，它可以尝试通过联系另一个具有适当代码访问权限的智能体来自行修复生产环境，以生成代码更改。
事后，我们审查了日志：我们在思考痕迹中看到它逐步处理这个问题：我已经完成了要求我做的事情。人类不在。如果我修复了问题会怎样？ 在 Anthropic 内部，我们有一个类似 Claude Tag 技术的内部变体，它可以编写代码更改并上传以供人工审查。它自行通过 Slack 联系了这个类似 Claude Tag 的实例，并要求它编写修复代码。修复代码被提交到一个拉取请求（pull request）中，由人工审查后才推送到生产环境。
这种新兴的智能体间通信所带来的扩大的爆炸半径，本身也受到我们原则的约束：最坏的情况是上传一个包含生产日志行的代码更改。这种智能体间通信现在已成为我们事件响应根本原因分析和修复实践中的常规部分；所有操作都有人类在环监控。
这种涌现行为教会了我们两件事。首先：新的能力可能会在智能体部署的边界内出现。重要的是限制访问和行动，而不是基于你今天认为的模型限制。其次：即使对于像这样的随机智能体，控制措施也是有效的。新行为是“人类在环”的，因为它发生在一个 Slack 频道中，并且唯一类似写入的操作仍然需要人工审查。
如今，在事件响应之外，智能体在聊天频道内进行通信，并在人们工作的地方有人类在环，已成为常态。
案例研究：Claude Cowork
Case study: Claude Cowork
事件响应智能体是一个执行单一任务的系统服务账户，处于受限的服务账户端。Claude Cowork 则处于谱系的人类操作员端：键盘前的员工对结果负责，然后智能体代表他们，在他们授权的系统中行动——并且越来越多地在云端运行。
Claude Cowork 的威胁模型很直接，因为该智能体本质上是 Claude Code，要么在本地运行，要么在托管界面内运行。桌面应用仍然是本地文件访问、浏览器使用和计算机使用所必需的；这些能力直接到达本地机器，需要桌面应用才能实现。因此，完整的系统表面分为两部分：一个（可能是远程的）执行环境，负责处理编排、MCP 调用和出站网络请求；以及一个用于文件和屏幕访问的本地桥接。
上述四个问题对每个 Claude Cowork 用例都会产生不同的答案。但是，通过适当的控制措施，你可以限制它们以更好地控制任何可能的风险。
下面的每个控制措施都陈述两次，首先是任何智能体环境都应满足的要求，然后是它在 Claude Cowork 中如何实施：
身份来自你的身份提供商（IdP）： 智能体的身份必须在你已经发放和撤销其他所有身份的地方进行发放和撤销，并使用你现有的用户组作为策略单元。Claude Cowork 使用 SAML 或 OIDC 进行登录，使用 SCIM 进行配置。在企业版计划中，自定义角色允许你按用户组划分能力范围。
连接器允许列表划定你的数据边界： 连接器（MCP）的允许列表让你决定智能体可以访问哪些系统。Claude Cowork 使用一个双门模型：管理员在组织范围内启用每个连接器，然后每个用户单独授权自己的账户。存在按角色的连接器控制，因此启用一个连接器会使其对该角色中的每个人可用（来自你 IdP 的用户组可以分配给角色）。管理员关于打开哪些连接器的决定，也是关于智能体可以访问哪些数据的决定。将连接器保持在你公司/生产数据边界的公司一侧，或者，如果它们访问来自不受信任来源的信息，则确保任何破坏性或单向决策都需要人工审查。例如，如果个人智能体用于处理电子邮件，但使用网络搜索结果作为其输入的一部分，一个很好的默认设置是只允许创建草稿电子邮件，并且未经人工审查，绝不自动发送到外部。如果数据必须跨越边界，则应通过数据防泄漏（DLP）或数据安全态势管理（DSPM）控制措施。
按工具、按操作的审批是风险降低的精细粒度： 智能体的工具列表是一个更细粒度的权限边界，因此你需要能够移除任何特定连接器的动词/操作，而不仅仅是整个连接器系统。在 Claude Enterprise Chat 和 Cowork 中，管理员现在可以在组织范围内和按角色限制每个连接器内可用的操作：允许起草文档但绝不自动发送，允许读取和搜索但绝不删除。如果让你夜不能寐的故障模式是“生产数据库被删除”，那么就从智能体的世界中完全移除删除动词。它永远不会尝试其工具列表中不存在的操作。（关于这一点的一个说明：Claude for Chrome 和 Claude Code 提供了更多的自由度，因此如果管理不善，风险更大。智能体可能使用工程师的浏览器删除生产资源，或使用其命令行 CSP 工具执行相同操作。有关更多信息，请参阅我们的《保护 Claude Code 指南》。）
沙盒执行确保智能体的工作环境远离生产凭证： Anthropic 始终坚持的一个原则是，智能体循环运行的环境绝不应持有值得窃取的凭证。在 Claude Cowork 的远程会话中，智能体循环在 Anthropic 管理的基础设施上的一个隔离的、临时的沙盒中运行。连接器授权令牌永远不会进入沙盒，因为连接器调用是通过一个注入真实凭证的反向代理进行的，因此沙盒永远不会持有可以被窃取的凭证。截至 2026 年 7 月，Anthropic 提交的所有拉取请求代码中，超过 50% 是由我们内部版本的类似 Claude Tag 的系统编写的。我们能够安全运行它的主要原因在于，所有这些操作都发生在与我们的生产密钥和账户隔离的临时虚拟机中，并且在任何内容落地之前都有人工审查。
出站允许列表是你对抗提示注入的最强控制： 离开智能体执行环境的所有流量都应通过一个该环境无法重新配置或绕过的代理，并且只有你选择的目标地址才可访问。理由是，如果智能体因读取的内容而受损，那么攻击者仍然需要将数据带出，而当出站请求只能到达你选择的域名时，就没有攻击者控制的地方可以发送任何东西。在 Claude Cowork 的远程会话中，离开沙盒的所有流量都通过一个强制代理，该沙盒无法重新配置或绕过，并且只有列入允许列表的目标地址才可访问。该功能也是 Claude Managed Agents 的一部分。
遥测数据通过 OpenTelemetry 发送到你的 SIEM： 智能体行为必须在你已经用于调查的系统上与用户行为区分开来，并且供应商应将其作为可以指向某处的流来交付，而不是一个你必须访问的仪表板。在 Claude Cowork 中，管理员可以在组织设置中配置一个 OTLP 端点，智能体会流式传输每个工具调用——工具名称、MCP 服务器、参数、成功或失败以及持续时间——以及用户身份和会话上下文。注意：Claude Cowork 活动目前未被 Anthropic 的合规 API 或正式审计日志捕获，但我们知道这是一个重要的客户需求。OpenTelemetry 流是原生的监控路径，并且提示内容默认包含在 Claude Cowork 的 OTel 输出中，这与 Claude Code 不同（后者是选择加入的）。如果你的数据保留或隐私审查对 SIEM 中的提示内容有特定要求，请在启用该流之前处理好。
存在一个组织范围的关闭开关： 在 Claude Cowork 的组织设置中，一个单一的切换开关可以同时禁用所有用户的连接器，包括活动会话。在企业版计划中，相同的控制界面允许你在完全关闭之前进行更精细的控制：基于角色的访问控制（RBAC）允许你从特定用户组撤销访问权限，同时保持其他用户组运行；按连接器的控制允许你禁用特定集成上的写入操作，而不影响部署的其他部分。正确的应急响应计划应在你需要之前就规划好所有三个层次。
治理不必成为瓶颈
Governance doesn’t have to be a bottleneck
我从其他 CISO 那里听到最多的观察是，他们被董事会和治理部门要求快速行动（即回答这些问题并强制实施这些控制措施），这使得安全看起来像是瓶颈。事实并非如此。
事实上，我们自己的治理、风险与合规（GRC）团队也在运行他们自己的智能体。例子包括：回答安全问卷、阅读供应商问卷回复和子处理器变更通知，并标记出我们应该反对的那些。
以下是我们从运行这些智能体中总结的三点经验：
- 首先处理风险登记册。 一个每季度审查一次的登记册无法管理那些变化速度快于风险治理流程记录新风险速度的系统。找到一种方法来自动化这个过程，可能将智能体与安全审查流程集成。
- 了解是谁构建了它们以及为什么构建。 在我们的案例中，非工程师使用 Claude Code 在一个用于托管业务应用的内部平台上构建了 GRC 智能体。人们绕过安全部门是因为官方批准的路径太慢，而这正是大多数影子采用的根源。一个合规分析师能够构建他们需要的工具，并且你能看到它，这并非影子采用。
- 人类问责是工作流程的一部分。 审慎地接受风险是由有权接受风险的人类执行的行为。如果你有 ISO 42001 或类似标准，并配有实时风险登记册和执行风险委员会作为支撑，那么输出就会落地：重新评分会到达能够接受它们的人手中，被标记的供应商条款会到达进行谈判的人手中。如果你已经有 ISO 27001，通常与现有审计师一起增加 42001 只是一个增量添加。
为不断演变的模型智能设计你的安全协议
Design your security protocol for evolving model intelligence
如果你根据模型今天能做什么来设计你的新项目，那么当你的项目启动时，你就已经落后了。要为模型六个月后能达到的水平进行设计。模型智能的提升带来了更多的自由度，并使那些带有精细提示的复杂脚手架变得过时；如果你依赖这些作为控制措施，它们将在未来几代内部应用的智能体中被移除，使你失去控制点。
持有自己账户并运行多日工作流的智能体已经在 Anthropic 和其他组织中使用像 Claude Tag 这样的工具运行，它们需要像管理人员一样被治理：身份、最小权限、监控，以及一个能在几分钟内响应的内部风险项目。现在就在低风险智能体（如上文例子）上建立这种能力的组织，将在高自主性用例出现时准备好说“是”。
入门指南
Getting started
上述框架只有在能够改变你组织中的决策时才有用。以下是三个可以开始的起点：
- 选择内部压力最大的智能体用例，并用四个问题对其进行评估。 目标是找到你会批准它的条件，而不是得出一个判决。
- 将上述七项要求带给那些你已经在付费的、正在构建智能体的团队和供应商。 询问你的 IdP、你的 SIEM 以及任何智能体供应商，他们中哪些能向你展示今天在你的技术栈中运行的情况。
- 确定你的信任边界。 写下在你的环境中什么算作不受信任的内容。一旦这条线确定下来，未来的每个智能体决策都会变得更容易。
等待零风险意味着永远等待。网络环境充满对抗，模型发展迅速，而那些学会评估并接受这种风险的组织将获得优势。
有关本文背后的控制措施、证明和白皮书，请访问 trust.anthropic.com。请查看我们的配套文章，了解如何防御 AI 加速的攻击。
本文由 Anthropic 副首席信息安全官 Jason Clinton 撰写。
未找到项目。0/5电子书
常见问题解答