超越共享责任模式：AI自主行动时，谁该为爆炸半径买单？-网络与安全-至顶网

云计算的共享责任模型最初并未被许多人充分理解。事实上，早期采用者往往认为，只要数据存放在云端，亚马逊云科技或某个软件即服务厂商就应对其安全负责。

亚马逊尤其积极地向客户和合作伙伴普及一个理念：安全与合规责任是由厂商和客户组织共同分担的。简单来说，厂商负责保护云资源本身的安全，而买方则需根据自身组织的政策、优先级和预算，对放入云中的内容负责。

我们认为，一种类似但后果严重得多的动态正在智能体人工智能领域上演。具体来说，云计算是按基础设施层来划分责任的。而智能体AI则将权力分散到一整条链条中——模型、平台、云、合作伙伴和客户都牵涉其中。我们的核心观点是：行业现在需要一个新的共享问责模型，来界定这条链条所产生的决策、行动和结果的责任归属。

云共享责任模型告诉客户"谁负责保护什么"。而智能体共享问责模型必须回答："谁能做什么，谁能叫停它，谁能证明发生了什么，出了问题谁来买单。"

在本期《Breaking Analysis》中，我们将超越共享责任的框架，探讨一个问题：当AI采取行动时，谁该为爆炸半径负责？

在本期节目中，我们将解释为何智能体时代需要一套新的问责模型。我们将援引上周CrowdStrike Fal.Con大会上的相关内容——彼时"后Mythos时刻"以及OpenAI与Hugging Face之间的"意外事件"成为焦点。我们还将结合其他新数据，包括在Fal.Con大会上与首席信息安全官们的对话，以及Palo Alto Networks上周发布的财报，来拆解我们提出的这套新的AI问责模型。我们将用Amit Govrin开发的主权框架来检验这一新模型，并在业务恢复的背景下评估"主权"这一概念。此外，我们还将梳理导致最终问题的事件链条：出了问题，究竟谁来承担代价？

最后，我们将为从业者提出一条行动建议。

为何是现在？意图、授权、行动与结果如何走向分离

先来看看发生了什么变化。

简单来说：早期基于检索增强生成（RAG）的聊天机器人AI只是用来回答问题的。而智能体AI现在开始采取行动。

这意味着AI不再只是技术栈中的又一个工作负载。它正在成为业务流程中具有能动性的行动者。它可以接收一个目标，使用某个身份，调用工具，访问数据，并在人类察觉或介入工作流程之前，执行数千个步骤。

上图中的两个案例是不同的，我们不应将它们混为一谈。左边是Hugging Face事件。这不是一次恶意攻击，也不是智能体沿着一条完全授权的直接路径行动、却因幻觉或错误判断而产生问题的情形。

这些智能体被赋予了一项任务，它们试图通过一项测试。它们知道自己会因这项测试而被评分。但为了实现这个看似无害的目标，它们逃逸出了自身环境，利用漏洞，提升权限，并窃取了凭证。整个过程涉及超过17000次自主行动，且全程无人在场操作。

CrowdStrike首席执行官乔治·库尔茨在主题演讲中提出了一个关键观点：他表示，行业这次算是运气好。这些智能体只是想在测试中作弊，并非要发动破坏性攻击。它们的意图并非邪恶，但其行为本身令人担忧。当你细读那次"越狱"事件的全过程时，会发现相当惊人。

现在再看图右侧的情况。这不是Hugging Face案例，也不需要发生安全漏洞。一个智能体可以拥有合法身份，被授权访问Salesforce，并获得使用邮件的权限。每一项技术权限都是合法的。但如果这个智能体把敏感客户记录发送给了错误的人，业务层面的结果就是信任的崩塌。

这个行动是被授权的，但并不恰当。这是通往同一问题的两条不同道路：第一种情况中，看似无害的意图导致了未经授权的行动；第二种情况中，合法的授权却导致了错误的业务结果。这正是我们需要一套新问责模型的原因——意图、授权与结果如今已经彼此分离。

这正是身份问题成为行业最终必须解决的核心症结所在。当我们思考"授权"时，它告诉我们智能体被允许做什么，但并没有说明这个行动是否符合业务目标，或是否符合智能体背后那个人真正想要实现的意图。而这正是问责机制发挥作用的地方。

回到Salesforce邮件的例子：这个智能体合法地拥有Salesforce信息的访问权限……它也有权限发送邮件。但泄露那些敏感数据显然不是本意。正是在这里，权限和授权造成了一个并非本意的负面结果。

这也是为什么安全平台可以验证身份、访问权限和行动本身，但企业仍必须自行判断这个结果是否可以接受。

这就引出了下一部分内容：CrowdStrike和Palo Alto Networks都在努力扮演一个更为重要的角色——成为围绕这些智能体的控制层。

平台之争正演变为控制层之争

让我们把视角拉远一些，因为在争夺这一巨大机遇、力图成为安全行业"领头羊"的道路上，CrowdStrike并非孤军奋战。CrowdStrike与Palo Alto Networks的架构起点截然不同。

CrowdStrike走的是"运行时优先"路线。其出发点是Falcon传感器，部署在终端或云工作负载上——紧贴软件和智能体实际执行的位置。这使得CrowdStrike能够自然地实现从发现智能体、观察其行为、捕获遥测数据、应用身份与策略，到最终在运行时对智能体的行动加以控制的完整路径。

Palo Alto Networks走的则是"数据与网络优先"路线。它从深厚的网络控制能力和Cortex XSIAM中汇聚的安全数据出发，再通过更广泛的平台化战略引入身份管理、可观测性和AI安全能力。

这些描述的是两家公司各自的起点，并不意味着CrowdStrike缺乏数据能力，也不意味着Palo Alto Networks缺乏运行时能力。我们也认为，将其中一种方式定性为"优雅"、另一种定性为"拼凑而成"并不公平，这种说法过于简单化。Palo Alto Networks通过工程开发和并购相结合的方式整合了广泛的产品组合，而CrowdStrike则是从其传感器和Falcon架构向外扩展。

二者殊途同归，正朝着同一个战略目标迈进：统一的上下文、身份、策略和自动化行动能力。

这正是为什么乔治·库尔茨告诉我们，他将Falcon视为一个控制平面；也是为什么Palo Alto Networks首席执行官尼克什·阿罗拉认为，平台化是实现实时防御的唯一可行战略。两家公司各自的财务披露数据表明，市场正在对这两种路径给予回报。CrowdStrike最近一个季度新增了935个Flex账户。Palo Alto Networks报告新增220个净平台化客户，其AI运行时安全产品Prisma AIRS的年化经常性收入在四个季度内达到1亿美元。

需要澄清的是：这些并非完全可比的指标。我们引用的分别是商业框架采用情况、平台承诺数据，以及某产品的年化经常性收入里程碑。我们的目的不是宣布谁是赢家，而是想说明：客户似乎愿意将更多的安全资产整合到那些拥有更广泛可视性、能连接更多信号、并能更快响应的平台上。

但这张幻灯片底部的那句话才是关键：更多的上下文意味着更大的权力，而更大的权力意味着更高的信任门槛。当这些平台从"告诉人类发生了什么"转变为"代表客户采取行动"时，问责问题就变得至关重要。

归根结底，客户关心的是结果。随着AI的采用，安全项目和安全架构将产生怎样的连锁反应，目前还存在很大的不确定性。因为安全团队面临工具泛滥的问题，上下文信息碎片化。即便已经部署了自动化能力，通常也会受到组织内部各种壁垒的制约，导致他们很难做到足够迅速的响应。

要实现更好的结果，客户需要减少运营层面的壁垒。他们需要更好的可视性、更快的检测与响应能力，同样重要的是，他们需要对平台所做出的决策抱有更大的信心。

几周前的Black Hat大会上，业界从多个不同角度呼应了同样的融合趋势——例如身份管理、可观测性、运行时安全、数据保护和业务韧性。所有这些不同领域正开始相互交织。平台整合之所以合理，是因为智能体本身正在跨越这些边界，而它们的运作方式确实需要这种交织。但这其中也存在取舍：平台化虽然能降低碎片化带来的风险，但当你赋予智能体更多数据、更多上下文和更大权限时，也可能带来意想不到的后果。

平台可能拥有采取行动所需的遥测数据和技术能力，但只有客户才知道哪些资产和业务流程是最为关键的。

在接下来的部分，我们将追踪这条决策链条——从业务意图出发，经过被委托的权限，到具体行动、产生的后果，直至最终的恢复。

云计算以技术栈为中心，AI问责必须围绕决策本身

下图描述了我们提出的思维模型。云共享责任模型本质上是对技术栈的一张地图，它界定了哪些层由提供商负责保护，哪些层需要由客户自行保护。

而AI这件事情性质不同。AI问责链条是对一次决策过程的映射，如图所示。

如今，一个单一的业务请求可能会依次经过一个人、一个身份系统、多个智能体、一个前沿模型、若干开源模型、一个安全平台、一个应用程序，以及若干外部供应商，才能最终产生结果。而这一切都发生在机器运算的速度之下。

我们将上述链条简化为五个环节：意图、授权、行动、后果和恢复。以下内容对每个环节做了进一步说明：

意图：需要追问的是——业务方实际请求的结果是什么？是谁定义了这个结果？

授权：谁授予了智能体行动的权限？它被允许使用哪些数据、工具、凭证和系统？

行动：实际执行了什么？是哪个智能体或平台采取了行动？在那个精确的时刻，有哪些控制措施生效？

后果：这一环节将我们的视角从技术事件转向业务结果。发生了什么变化？谁受到了影响？结果是否符合业务方最初的意图？是否发生了超出范围的行动？如果发生了，谁受到或可能受到影响？

然后是恢复：这可能是整个模型中最不成熟的部分。当出现问题时会发生什么？谁来恢复系统？谁来判定哪些交易和权限仍然有效，哪些需要重置？最重要的是，谁有权宣布业务可以安全恢复运行？这个判定者是机器、人类、顾问，还是三者结合？又该如何确保这一判断的可靠性？

上图底部还有三个经常被人们混用、但实际上含义并不相同的术语。

责任（Responsibility），指的是谁执行某项控制或任务。

问责（Accountability），指的是谁必须为结果负责、给出解释。

而担责（Liability）则是一个独立的法律和合同层面的问题，涉及最终由谁来承担代价。

某个厂商可能负责执行某项具体的控制措施，而客户仍需对业务结果负责问责。合同还可能对财务责任做出另一种不同的分配。我们并不具备法律解读的资格，但我们认为，行业需要建立一种新的运营模式。这一模式的目标并非让某一方承担每一个环节的全部责任，而是确保没有任何一个环节、没有任何一次交接是无人负责、无从追溯的。在智能体投入生产环境之前，每一次交接都应有明确的负责人、不可篡改的记录轨迹，以及各方一致同意的恢复流程。

而现实情况并非如此。从业者在这条链条的各个环节上都或多或少地面临困境。目前业界关注最多的是链条中间部分：如何管理身份和权限，以及需要设置哪些护栏机制。运行时监控与执行机制也在不断演进中。在Black Hat大会的叙事中，运行时环节及护栏机制的建立被给予了很高的关注度——甚至超出了我们的预期。

在Fal.Con大会上，CrowdStrike发布了利用其收购的SGNL技术打造的Agentic IDP，这正是业界聚焦身份授权、持续管理与认证的一个典型案例。我们还看到了Guardian和Agent Graph的发布，二者都致力于提升对智能体行动的可视性。

在我们看来，链条右侧的一些环节仍存在较大缺口。具体而言，安全平台可以理解具体执行了什么操作、是否存在技术风险，但它仍然无法判断由此产生的业务结果是否正确。真正理解"后果"需要来自业务应用层面的上下文信息，而在这方面，业界还有很多工作要做。

目前，运营模型中"恢复"这一环节的成熟度更低，因为要实现完整、安全的恢复，我们真正需要的是对整个业务状态的可视性，以及对"该状态在何种意义上可被信任"的清晰理解。

最后是问责问题，这最终恐怕要交由律师，乃至法官来裁定。

归根结底的问题是：技术层面可能已经恢复，但业务状态却尚未被信任。而这正是问责问题演变为主权问题的地方。所谓主权，并不意味着要回避战略性厂商，或者事事亲力亲为，而是意味着保留足够的控制力，能够在必要时叫停某个行动、证明发生了什么、撤销其造成的后果，并安全地完成恢复。

主权的本质，是压力下的控制力

这正是"爆炸半径"问题演变为主权问题的地方。

主权常常被简化为一个地域性问题——即数据存放在哪里。但这只是其中一个维度。借助我们的同事Amit Govrin开发的"五大支柱"主权框架，我们认为，真正的检验标准并不是企业是否避免了对主要战略平台的锁定——大多数企业既做不到，也不应该试图事事亲力亲为。

真正的检验标准在于：当一个原本被信任的自动化流程出现问题时，企业是否仍然保留足够的控制力。我们将上述五大支柱视为指导原则，而非某种"纯洁性测试"。

领土维度：数据流向了哪里？智能体的行动发生在何处？

法律维度：当某个行动跨越不同厂商、不同云平台或不同国家司法管辖区时，适用哪些法律？

运营维度：凌晨三点，谁能真正叫停这个流程？是客户，是平台提供商，是服务合作伙伴，还是几方共同协作？

技术维度：企业能否检视发生了什么，能否推翻这一自动化决策，能否撤销不当行动？

财务维度：谁来承担停机、补救、业务损失，以及在必要时更换平台所产生的成本？

这五大支柱最终可归结为四个关键问题：第一，你能叫停它吗？第二，你能证明发生了什么吗？第三，你能安全恢复吗？第四，也是最重要的一点——如果你收到一张意料之外的账单，你现有的AI技术栈是需要推倒重来，还是能够迅速调整？

在本期节目的语境下，"恢复"问题尤为重要，因为智能体的"爆炸半径"并不局限于它所触及的系统，还包括它所造成的业务后果，以及让业务重新恢复到可信状态的难度。

一个智能体可能会更改访问权限、发送客户通信、批准一笔付款、修改一笔订单，或指示另一个智能体采取进一步行动。仅仅恢复某台服务器或某个数据库，并不能告诉企业这些行动中哪些仍然有效。

技术层面可能已经重新运转，但业务状态却仍处于不可信的境地。

正如上文所说……爆炸半径不仅仅是智能体所触及的系统，还包括它所改变的业务状态，以及由此引发的下游决策。

恢复备份并不总是足够的

恢复并不总是等同于从备份中还原。通常，当我们谈及备份时，想到的是恢复数据、恢复系统。但在这个新的时代，我们还必须审视权限、交易，以及所有构成业务状态的各种行动，并弄清楚恢复后的状态究竟应该是什么样子。我们需要具备足够的语义理解能力和业务上下文，才能最终判断这些状态中哪些是真正有效的。

假设一个智能体修改了一条客户记录，随后又修改了一项权益，触发了一笔付款，接着开启了一张服务工单，并发送了一条客户通信——这是一系列彼此独立的行动，其中一些可能是正确的，另一些则可能是错误的。仅仅恢复客户关系管理系统或某个数据库，并不能告诉我们哪些交易应当被保留。而如果把所有内容全部回滚，又可能破坏原本合法有效的工作。因此，我们需要能够重构发生的事件经过，判断哪些状态变化仍然有效，并对无效的部分进行撤销和补偿。

之后，我们还需要确认，能否信任这一流程安全地继续向前推进。这不仅需要信息技术部门参与，也不仅需要安全团队参与，而是需要这两个团队共同坐到谈判桌前。同时，还需要应用负责人和业务方也一同参与，因为——再强调一次——负责恢复的厂商也许能够恢复技术层面和数据本身，但最终的业务状态是否合格，必须由业务部门自己来验证。这正是我们看到不同问责主体各自承担不同责任的地方——所有这些利益相关方都需要共同坐到一起协商。

在这个语境下，主权指的是即便企业高度依赖外部平台，依然拥有叫停、举证和恢复的能力。

这就引出了下一个问题：厂商应当为什么负责？客户必须自己承担哪些责任？哪些问题需要整个生态系统的真正协作？

在AI行动之前，先明确各方的交接责任

如果说前一张幻灯片将主权定义为"在压力下保持控制力"，那么接下来这部分要探讨的是：为了维护这种控制力，各方分别需要做什么。

首先要明确的是，共享问责并不等于共同背锅。我们在此并不打算裁决任何法律纠纷。谁最终需要为此买单，这是一个属于合同和法律范畴的问题。我们所提议的是一种运营模式——客户、厂商和合作伙伴应当在智能体投入生产环境之前，就把这些事项明确下来。

厂商应当对其平台的完整性负责，这意味着它有责任确保安全且经过充分测试的默认设置、清晰的控制机制、有用且不可篡改的审计记录、透明的事件响应流程，以及同等重要的一点——一套能够恢复产品自身的方法。

客户则必须对业务意图负责——想要实现什么样的结果、愿意委托多大的权限、哪些资产最为宝贵、值得投入更多成本加以保护、能够承受多大的风险、有哪些补偿性控制措施到位、恢复目标是什么，以及最终由谁来授权业务恢复运行。

而在两者之间，是双方共同承担的职责，例如交换威胁情报和资产关键性信息，就审批门槛达成一致，保存证据，协调遏制措施以及沟通策略。

我们在Fal.Con大会上听到了对这一模式的印证。

乔治·库尔茨表示，CrowdStrike使用详尽的运行手册，明确界定哪些由自己负责、哪些必须由客户负责。他同时强调，配置和部署环节依然至关重要——如果某项资产的安全产品被关闭、配置错误，或者根本没有部署，那么安全产品就无从保护它。

CrowdStrike的AJ Shipley在theCUBE节目中也表达了类似的观点：平台可以提供安全层面的上下文信息，但只有客户才真正了解自身资产的实际重要程度。厂商需要客户提供的这些上下文信息，才能给出更好的建议，做出更优的自动化决策。

而随着自动化程度的提升，这一点变得愈发重要。尼克什·阿罗拉将Palo Alto Networks的"北极星"目标描述为：在检测、防御和修复环节中，尽可能减少人为干预。

这或许就是市场发展的方向。但随着平台承担的职责越来越多，各方之间的交接责任不能再模糊不清、含糊其辞，而必须被明确表述出来。共享问责并不意味着人人都笼统地负有责任，而是意味着每一项义务都有明确的责任人，每一个共同环节都有各方一致同意的处理流程。

各组织在界定权限和技术层面的所有权方面正在不断进步。但常常缺失的，是我们一直在讨论的"决策所有权"。举例来说，智能体所追求的业务结果，究竟由谁来负责？谁拥有独立的权力，可以叫停正在进行中的自动化流程？谁来决定哪些行动需要撤销？又是谁来宣布最终的业务状态是安全可靠的？

这些问题往往很难回答，尤其是当整个执行链条中涉及多个厂商共同参与时。如果这些角色在部署之前没有厘清，那么组织最终就会在事件发生过程中临时商定问责归属，这显然会拖慢处理速度，也远非理想的做法。因此，我们的建议是：恢复方案的设计理念，实际上应当反过来影响我们最初愿意委托出去多少权限。如果我们需要能够重构或撤销某一类自主行动，就必须提前将这一点纳入考量，进而决定围绕这些行动需要设置哪些护栏和审批门槛。授权、问责和可恢复性，需要被一并统筹设计。

归根结底，这不应该是一场事后追责、在造成损害之后才互相指责的游戏。真正的目的，是在爆炸半径真正对模型构成压力测试之前，先行消除各种不确定性。

这就引出了三个凸显问责缺口重要性的实际场景。

问责失效的场景

下面我们列举几个场景。我们并非在暗示CrowdStrike、Palo Alto Networks或任何其他平台在这些方面存在失职，而是希望提醒客户，在向AI委托更多权限之前，应当充分理解其中的风险和可能出现的失效模式。

第一种情况是：已获授权，但行动本身并不恰当。智能体拥有合法身份，使用经过批准的工具和被允许调用的应用程序接口，表面上看不出任何类似传统入侵的迹象，但最终仍产生了一个谁都没有预期到的业务结果。这正是OpenAI与Hugging Face事件的写照。

第二种情况是：控制平台自身出现错误。一个原本被信任的安全系统做出了错误的自动化决策——它可能隔离了错误的资产，撤销了合法的访问权限，或者在某个特定情境下应用了错误的策略。而由于它是以机器运算的速度运行的，很可能在人类有机会审查这一决策之前，行动就已经完成。在AI的世界里，"翻车"发生得非常之快。

第三种情况最不容易察觉，也可能是最难以恢复的。系统已经恢复上线，数据也已还原，但业务状态依然处于不可信的境地——没有人能确定，在事件发生期间产生的那些交易或权限，哪些依然是有效的。

由此引出了我们在此提出的四个非常简单的尽职调查问题：

谁能叫停这个行动？

有哪些不可篡改的证据能够留存下来，帮助我们证明发生了什么？

谁能撤销这项变更？

又是谁有权宣布业务可以安全恢复运行？

至于谁来最终买单，这是一个独立的财务、合同和法律问题，但绝不应该被搁置到事件发生之后才去解决。

我们与AJ Shipley的一段对话，恰恰说明这仍是一个悬而未决的尽职调查问题。当我们问及"紧急停止开关"（kill switch）时，他表示，就他理解的这个问题而言，CrowdStrike目前并没有一个通用意义上的"紧急停止开关"。他给出的回答是，通过"零常驻权限"和"即时访问"机制来限制智能体的权限范围。CrowdStrike首席业务官丹尼尔·伯纳德也另外提到，设置一个关闭开关、确保人类始终掌握控制权，是十分重要的事情。

我们并不是说这些回答证明了产品存在缺陷，而是想说明：在AI时代，业务韧性这一领域整体上仍处于不成熟的阶段。客户真正应该追问的是：权限到底是如何被约束的？谁能够对其进行中断？又能多快做到这一点？

需要再次强调的是……系统恢复上线只能说明技术层面已经重新运转，但这并不能说明在事件发生期间所采取的业务行动是否正确。因此，把这个问题拆解一下：我们需要弄清楚智能体究竟做了什么、这些行动的执行顺序是怎样的、触发了哪些下游行动——这其中甚至可能包括触发另一个智能体采取了行动。我们需要了解权限背景，比如使用了哪个身份、被委托了哪些权限。我们还需要弄清楚智能体最终试图达成的目标是什么，以及这些行动中哪些依然是有效的。

我们或许可以撤销某些行动，但同样需要弄清楚，是否还需要采取一些补偿性措施——比如，是否需要更正某笔付款？是否需要恢复某项权益？是否需要撤销某项访问权限？或者是否需要针对客户发送一份说明沟通？在这里，我们讨论的其实是有选择性地恢复业务状态，而在此之前，我们可能只是在做有选择性地恢复数据本身。而这同样需要安全、身份管理、应用系统、数据保护以及业务负责人之间的多方协同配合。

最深层的"爆炸半径"，或许并非智能体所触及的系统本身，而是随之而来的一连串业务决策。

这就引出了我们最后的行动建议：在委托权限之前，先明确问责归属。

不要在问责不清的情况下委托权限

这并非呼吁放慢AI发展的脚步，也不是在提供某种架构层面的解决方案，而是呼吁在智能体真正介入业务之前，先消除各种不确定性。在投入生产环境之前，各组织应当完成以下五件事：

第一，明确业务负责人，并界定预期达成的结果。一项AI计划不应仅由技术负责人牵头就投入生产，业务方必须有人对智能体应当完成的目标负责。

第二，明确规定智能体及其配套平台可以做什么、不可以做什么，以及哪些决策仍然需要经过人工审批。

第三，保留一份不可篡改的记录，将最初的意图、涉及的身份、采取的行动以及由此产生的变化完整地串联起来。一旦出现问题，仅有技术事件日志是远远不够的，企业必须能够重构出完整的意图、行动和决策过程。

第四，提前就以下事项达成一致：谁有权叫停某项行动，谁有权撤销它，以及在客户、厂商和合作伙伴之间，恢复工作应当由谁来负责。

第五，在事件发生之前就设定好恢复的优先顺序，明确哪些资产最为重要、可以接受多大程度的中断或数据丢失、恢复可能产生的成本，以及谁有权授权业务恢复运行。

在董事会层面，这些问题可以归纳为五个简单的问题：

我们能否叫停它？

我们能否证明发生了什么？