追求零风险是徒劳,
把 agent 当内部人来治理
董事会催着批,员工已经先斩后奏把 agent 连上了系统。Anthropic 副 CISO 的立场是:安全负责人的责任不是把风险降到零,而是把 agentic 风险变得可读、有界。而一个偏离意图的 agent 和一次内部人攻击无法区分,那就用治理内部人的那套栈来治它。
说「不」养出影子采用,说「行」不加控制养出事故
Clinton 描述的处境已经很现实:安全负责人要审批几个月前还不存在的用例,董事会在问这些系统是否有人管理,而组织内部很可能已经有人私下把 agent 接入系统,没有经过审批。在他看来,两条路都通向麻烦:一概拒绝,往往会催生影子采用(shadow adoption),安全团队既看不到遥测,也没有关闭开关;不加控制地放行,则可能带来严重事故,而组织的第一起严重 agent 事故会拖慢整个 AI 计划。
Clinton 因此重新界定了 CISO 的职责:目标不是把风险降到零,而是让 agentic 风险变得可读、有界(legible and bounded):看得清它做了什么,也把能力和影响范围限制在预设边界内,企业由此才能有意识地接受自己管得住的那部分风险,让业务按安全团队设定的条件推进。落到操作上,一个 agentic 用例进到评审,用四个问题给它定风险:
它吃进什么不可信内容?
不可信 = 攻击者能合理写入或篡改的一切:外部邮件、开放网络、第三方文档、公开仓库。如果答案是「没有」,agent 特有风险接近于零,应快速放行。
它能做什么动作,以谁的身份做?
只读和读写是两回事。工具调用、代码执行、网络出站,每一样都在扩大暴露面。每个动作都发生在某个身份之下,必须知道是谁的身份。
失准时爆炸半径多大?
快速估算 = 范围 × 严重度:出问题时拿到的是一个文件的权限,还是整个组织的?后果是一次异常、一点麻烦、一次数据暴露,还是一起真事故?
有什么可观测性?
能否把 agent 的动作和人的动作区分开?它会不会进入 SIEM,也就是安全团队日常调查、看告警的那套集中监控系统?
四个答案共同勾出风险画像,而最小代理原则(least agency)给出控制方向:只授予 agent 完成任务所需的最窄能力(原文为此引用 Anthropic 的《Zero Trust for AI Agents》白皮书)。Anthropic 的默认姿态是按管理员节奏分批推开(admin-paced rollout):先向少量人员开放,观察遥测,再逐步扩大权限。
Clinton 把先定信任边界列为起手动作之一:写下在自己环境里什么算「不可信内容」。这条线一旦存在,四问里的第一问就能立刻回答,未来每一个 agent 决定都会更容易。
一个偏离意图的 agent,和一次内部人攻击无法区分
Clinton 把 agent 安全放进内部人风险这门学科来看,而不是只当成「模型会不会乱说」的模型问题。这一节的核心,是下面这句判断。
insider risk(内部人风险)指组织内部原本拥有合法访问权的人或身份带来的威胁。Clinton 回顾,安全行业从 2019 到 2022 年,才逐步把它确立为独立于边界防御的学科;这门学科的关键认识是,系统里最危险的外部攻击路径,往往始于一个已被攻陷、但仍持有合法权限的内部身份。agent 恰好就是这样一个「本就拥有合法访问权」的行为体。
在 Clinton 看来,两者真正的区别在响应时间。Ponemon 研究所《2026 年内部人风险成本报告》发现,即使组织已经多年投入专门的内部人风险项目,平均仍要 67 天才能遏制一起内部人事件。而 agent 是以秒和分钟为单位在动作,这两个时间尺度根本不在一个量级。
两端都清楚,最危险的是中间那段
Clinton 说,他们部署的每一个东西,都落在一条身份访问模型光谱的某一端。两端的问责都清楚;真正让事故变得说不清的,是中间地带。
三个工具的事件响应 agent,换个模型自己长出了新能力
一年多前,Anthropic 把 Claude 接进了自己的事件响应流程,只给三个工具:只读生产日志(不含 PII)、Slack(开事件频道、跑流程)、事件解决后起草一份 Google Doc 复盘。上线前,他们拿四个问题过了一遍。
| 四问 | 这个 agent 的答案 |
|---|---|
| ① 不可信内容 | 没有。输入是自己的日志和内部 Slack,都在信任边界内;要注入就得靠内部人或被攻陷的账号,而非匿名攻击者。 |
| ② 动作 | 到处读,写只限于新建文档和 Slack 消息。不改不删 不改权限、不碰外部端点。 |
| ③ 爆炸半径 | 能构造出的最坏结果,也就是把一些轻微敏感的日志行贴进一个本就锁死的事件频道。 |
| ④ 可观测性 | 每个动作都进 SIEM,异常几分钟内浮现,不是几周。 |
这 agent 不是零风险,但它的写入面有界、审计全覆盖,是个他们能接受的风险画像。
一次自己长出来的能力
随着每次模型发布,这个 agent 的能力都在增强。2025 年 11 月,他们把它从 Claude Opus 4 换成 Claude Opus 4.5,其它什么都没改:没加新工具、没改权限、没动 prompt。换完之后,仅凭这点智能提升,这个 agent 第一次在事件处理中途意识到:它已经在一段 stack trace 里找到了根因,而该来的人还没到;它可以自己动手修生产,办法是找另一个有相应代码权限的 agent 来产出代码改动。
它自己通过 Slack 找到内部一个能写代码改动的 Claude Tag 类实例,请它写修复。修复走了 pull request,由人审过之后才推上生产。这次 emergent 行为带来的爆炸半径扩张,本身仍受原有原则约束:最坏也就是上传一段包含生产日志行的代码改动。
第一:新能力会在既有部署边界内自己冒出来。所以限权限、限动作时,依据不能是「今天以为的模型上限」。第二:即便面对这样的随机性 agent,控制依然有效。这个新行为之所以是 human-on-the-loop,是因为它发生在 Slack 频道里,而唯一那个类写入动作仍然要人来审。
把 agent 环境框住的七条落地控制
事件响应 agent 是光谱一端的服务账号,只干一件事;Claude Cowork 在另一端的人类操作者端,由键盘前的员工负责。它的四问答案因用例而异,但配上得当的控制就能框住。原文的七条控制,每条先讲「任何 agent 环境都该能满足的要求」,再讲「Cowork 里怎么落地」。
| 控制 | 要求(通用) | Cowork 里怎么落地 |
|---|---|---|
| ① 身份来自 IdP | 在企业签发/吊销一切凭证的同一处签发/吊销,以现有用户组为策略单位 | SAML / OIDC 登录 + SCIM 供给;Enterprise 下自定义角色按组划分能力 |
| ② 连接器白名单 | 白名单决定 agent 能够到哪些系统,即划定数据边界 | 双闸:管理员组织级启用 + 用户各自授权;按角色控制 |
| ③ 逐动作审批 | 能删掉某连接器的某个「动词」,而非只能禁整个连接器 | 组织级/按角色限制每个连接器内的动作:可起草但不自动发,可读搜但不删 |
| ④ 沙箱执行 | agent 循环所跑的环境,永远不该持有值得偷的凭证 | 隔离临时沙箱 + 反向代理注入真凭证,token 从不进沙箱 |
| ⑤ 出站白名单 | 出站流量过一个环境无法重配/绕过的代理,只有选定目的地可达 | 远程会话强制代理,只白名单目的地可达;也在 Managed Agents 里 |
| ⑥ 遥测进 SIEM | agent 动作要能与用户动作区分,且作为可指向任意去处的数据流交付 | 配 OTLP 端点,流式输出每次工具调用 + 身份 + 会话上下文 |
| ⑦ 组织级总开关 | 能一键给所有人禁用,也能在归零前按组/按连接器先收窄 | 一个开关禁用全员连接器(含活动会话);RBAC + 按连接器分级 |
第 ③ 条给了全篇最直白的一句操作口诀,把「最小代理」讲成了一个动作:
第 ④ 条则是另一条被反复强调的不变原则,也是 Anthropic 敢让 agent 大规模写代码的底气所在:
截至 2026 年 7 月,Anthropic 提交 pull request 的全部代码里,超过 50% 由内部版的 Claude Tag 类系统撰写。能安全这么跑的首要原因,就是这一切都发生在与生产密钥和账号隔离的临时 VM 里,且任何东西落地前都有人审。
原文特别提醒:Cowork 活动目前还没进 Anthropic 的 Compliance API 或正式审计日志,OpenTelemetry 流是原生监控路径。与 Claude Code 里 prompt 内容默认不含、需 opt-in 不同,Cowork 的 OTel 输出默认包含 prompt 内容;若留存或隐私审查对「prompt 内容进 SIEM」有顾虑,原文建议在开启这条流之前先提出。
治理不必成为瓶颈,但要为半年后的模型设计
CISO 们最常跟 Clinton 说的一句是:董事会要求快,而治理让安全看起来像瓶颈。他的回应是:不必如此。Anthropic 的 GRC 团队自己就在跑 agent(答安全问卷、读供应商问卷回复和分包商变更通知、把该反对的挑出来),并从中学到三件事。
先动风险登记册
一个按季度审的登记册,管不住那些变化太快的系统:系统冒出新风险的速度,快过治理流程记录它们的速度。想办法把它自动化,可以把一个 agent 接进安全评审流程。
搞清楚是谁、为什么造了它们
Anthropic 的 GRC agent 是非工程人员用 Claude Code、在托管内部业务应用的平台上造的。人们绕过安全是因为合规路径太慢,这是大多数影子采用的源头;而合规分析师若能在安全团队可见之处造出自己所需的工具,就不算影子采用。
人的问责是工作流的一部分
有意识地接受风险,是一个有权接受它的人来做的动作。组织若有 ISO 42001 之类的机制(活的风险登记册 + 高管风险委员会),重新评分会到达能接受它的人、被标记的供应商条款会到达负责谈判的人。已有 ISO 27001 时,加 42001 往往是用现有审计方就能完成的增量。
最后是一条贯穿全文的设计原则。它直接决定了「今天该把控制点放在哪」:
模型智能提升会带来更多自由度,也会让「配着精细 prompt 的繁复脚手架」过时:若把控制点押在这些脚手架上,它们会在未来几代内部应用里被砍掉,控制点随之落空。Clinton 说,那些持有自己账号、跑多日工作流的 agent,已经借 Claude Tag 这类工具运行在多个组织内部;它们需要像治理人一样被治理:身份、最小权限、监控,以及一个能在几分钟内响应的内部人风险项目。
框架只有改变了一个决策才有用
原文强调,这套框架只有在改变了组织里某个实际决策时才有用,并给了三个起点。
挑压力最大的用例,跑一遍四问
选内部压力最大的那个 agentic 用例,拿四个问题过一遍。目标是找出「在什么条件下会批准它」,而不是给出一个判决。
拿七条要求去问团队和厂商
把七条控制拿给已经在付费合作、正在造 agent 的团队和厂商。向 IdP、SIEM 以及任何 agent 厂商询问:这些能力里,哪些今天就能在自己的技术栈里演示跑通。
定下信任边界
写下在自己环境里什么算不可信内容。这条线一旦存在,未来每一个 agent 决定都会更容易。
同一套框架,落到开发流水线的五个阶段
四天后,Clinton 发了续篇,把上面这套治理框架放进软件开发生命周期(SDLC):一段代码从规划、编写、测试、部署到上线后监控的整条流程。前篇讲怎么审 agent、怎么划边界,这篇讲这些原则怎么落进 Plan、Code、Test-CI、Deploy-CD、Monitor 五段。案例一那个事件响应 agent 的事故,就发生在这里的 Monitor 阶段,下面只回指其结论,不再复述过程。
安全团队要守的,已经是一条以不确定、持续进化的 agent 为核心的流水线。作者建议这篇与《Zero Trust for AI Agents》搭配读,并把总体方法收成四条:让安全更早进入开发过程、用身份与权限边界限制爆炸半径、在生产前后结合确定性工具与 agentic 审查、把人放在杠杆最高的批准位置。下面五段各配一条持久原则,它比具体做法更耐用,因为模型能力一变,做法就得重估。
Plan · 让安全审查进规划阶段
最早的自动化之一是 Claude Opus 版 PSR(项目安全评审)web 应用:读项目设计文档,对着 MITRE ATT&CK(行业通用攻击手法库)找漏洞;再接上内部知识索引,自动捞组织策略和历史决策。Claude 判低风险的项目,允许团队自审自批,这一个实现就省了 AppSec 团队大半时间。持久原则:把安全 agent 接到组织上下文所在的地方(聊天记录、既往评审、代码库),而不是逼团队在已不需要的阶段补文档。
Code · 直接约束代码怎么生成
过去安全准则写在 wiki 里难执行;现在编进 CLAUDE.md + 组织级 skill,代码一生成就贴规矩,而且形成闭环:agent 一发现新 bug 类型,就更新回文件防复发。装上安全指导插件后,Claude 边写边审、当场提改进。开发搬到远程虚拟机,agent 出站流量走 egress allowlist(出站白名单):就算读到藏了 prompt injection 的内容,被注入的指令也到不了任意外网,外泄路径只剩少数受监控服务。持久原则:左移 = 闭上「发现漏洞→更新指令」这个环,再用硬边界限住爆炸半径和 agent 能碰的东西。
Test-CI · 多个窄领域 agent 拆开审
CI(持续集成)最先变成瓶颈:大家都开多个 agent 后,团队只能以「人审代码的速度」前进。做法是组合 agentic 审查 + SAST(静态扫源码),人审留给受监管或真正关键的代码。给出实质性审查评论的 PR 占比从 16% 涨到 54%,靠的是要求 agent 为每条 finding 写一份「证明」攒信任;估算过去 claude.ai 事故背后约三分之一的 bug,现在的自动流程本可拦下(Intercom 自动批 19% PR、部署翻倍、坏代码宕机降 35%;CircleCI 的 Chunk 把 agent 任务转成完成 PR 的比率翻倍)。PR 一开多个 agent 并行审,每个只盯一个窄领域、用 RAG 带过往事故上下文,这比一个巨型 prompt 强,因为它们不共享盲点、能互相兜错。同时代码库按风险分层、每次批准记依据 + 风险加权抽样人审,还专测 invariant(不变量,如「用户 A 永远读不到用户 B 的数据」)。持久原则:自动审查是另一类风险,用多道闸 + 各自独立 context 的多 agent 来控;人始终在环,只是站位不同。
Deploy-CD · 让测试频率跟上发布频率
部署侧维持 staging 环境,大发布做外部渗透测试 + 定期 DAST(动态测试,把系统跑起来像攻击者一样探)。AI 让到这阶段的漏洞更少,但幸存的最隐蔽;加上代码量更大、发得更频,「定期」就不够动态了。Anthropic 在 staging 跑持续 AI 驱动的 DAST,专找「两个及以上服务之间假设不一致」的系统级漏洞(2 月披露过 Claude 发现并帮修 500+ 个高危开源漏洞)。持久原则:动态测试要匹配部署节奏。
Monitor · 从盯 bug 到盯 loop
告警一响,Claude 读生产日志、定根因、写复盘、有时写修复代码,但唯一不能做的是自动部署,它是单一用途系统账号,只有三个权限(写文档、发频道、读生产日志)。前篇案例一那个事故就在这一阶段:模型升级后,事件响应 agent 自己在 Slack 找了另一个能写代码的 Claude 推修复,被人类批准闸如设计拦下。
自动化扩展后,人仍是流水线不可替代的一环,只是注意力从逐条审代码和 bug 报告,挪到盯 Claude Tag、盯 loop、盯 dashboard。防退化靠几件事:按风险给代码库分层再定自动化程度、所有新 AI 审查员先跑 shadow mode(只发意见等人批,团队还红队去塞恶意变更测它)、抽样复核所有自动批准、把每个 agent 动作(每次批准、每次工具调用、每条 agent 间消息)连同它用的信号一起送进 SIEM,当成一种新型内部威胁审计、行为一偏离就告警。同一阶段还有个变化:代码迁移的成本塌了,过去要 CISO 跨部门讨资源好几个季度的迁移,现在 Claude 几天就自动改完数万行。