SecurityHQ AI Agent Research发现政策制定快于事件问责

SecurityHQ 发布的研究显示，76% 的受访网络安全负责人已制定正式的 AI 问责政策，但仅 17% 能在数分钟内重建智能体活动。SecurityHQ 与 Datadog 合作开展的这项 AI 智能体研究揭示出一个现实矛盾：明确责任归属，并不必然让自动化决策变得可解释。

该研究于 2026 年 10 月 15 日发布，正值企业智能体开始获得跨业务系统执行工作的权限。AI 智能体是利用模型和互联工具推进任务的软件系统。它们拥有的权限带来了仅靠书面政策无法回答的问题。

Microsoft 对 Security Copilot 的扩展，为这种向委派式安全工作转变的趋势提供了具体参照。如今，安全负责人、应用所有者和供应商都面临压力，必须将自动化行动与证据及可问责的人类授权关联起来。

SecurityHQ AI Agent Research将政策与准备度区分开来

该研究调查了中大型组织中的 204 位网络安全负责人。根据研究公告，45% 的受访者曾经历涉及 AI 智能体或自动化的事件，且当时责任归属不明确。

这一表述值得关注。该事件类别包含自动化，因此结果并不能证明 45% 的受访者经历过自主 AI 智能体入侵。责任不明确描述的也是一种组织问题，而非特定技术故障或损害程度。

这一发现关注的是：当责任出现争议时，组织能否解释被委派的行动。 一项政策可以指定负责人，却未必能说明是哪项指令、权限或系统交互导致了某个结果。

SecurityHQ 公开的问责调查结果还将历史可见性与即时调查准备度区分开来。仅 49% 的受访者表示，他们能够完整重建过去 30 天内智能体的行动。

这种区别改变了买方应如何解读这些结果。保留记录与回答紧急问题是相关能力，但服务于不同的运营需求。一个组织可能保存了相关证据，却仍需投入大量人工工作才能将其串联起来。

反过来，仪表盘或许能汇总近期活动，却没有保留足够细节以支持后续调查。这两种可能性都不能证明受访组织内部实际发生了什么，但都说明，单一的“可见性”主张需要更仔细的审视。

重要的变化在于研究的框架。SecurityHQ 将政策所有权与建立行动序列的能力并置，使两者之间的距离清晰可见。

对于企业买方而言，这带来了一个更严格的采购问题。供应商对治理的说明应当与客户在智能体行动后能够获得的证据相衔接。

对于内部安全团队而言，同样的区别会影响报告工作。审批流程的存在，并不能证明调查人员可以找回与争议行动相关的审批记录。

问责政策仍然有用，因为它定义了预期。其运营价值取决于人们能否将这些预期应用到具体事件中。

该调查并未证明，拥有政策的组织经历了更少的事件。它也没有表明，购买额外监控工具就能消除责任归属的不确定性。

但其更狭义的贡献依然意义重大。企业可以在正式分配责任的同时，缺乏在压力下履行该责任所需的证据。

这正是这则报道不止于又一项 AI 风险调查的原因。该研究质疑的是：一旦软件获得被委派的权限，熟悉的治理措施是否仍能反映真实的准备状态。

被委派的安全工作让买方和运营方承受压力

安全负责人面临压力，是因为智能体运行于本就由不同团队分担责任的系统之中。应用所有者可以授权某个工作流，而另一团队管理其凭证，还有另一团队负责事件响应。

凭证是软件在请求访问时出示的数字证明。当多个工作流共用同一凭证时，识别出账户也未必能确定实际发起者。

一个看似直接的所有权问题，随即会分解为多个问题：谁批准了任务，谁授予了访问权限，谁维护了集成，以及谁能够停止执行？

这些角色不必属于同一个人。当组织无法在调查期间将它们关联起来时，困难便会出现。

委派工作提高了明确授权从何处开始、如何变化以及在何处结束的重要性。 一位被点名的高管仅仅出现在治理文件中，并不能解决事件。

运营影响延伸到安全部门之外。业务负责人需要了解，智能体的行动是否服务于已批准的目标。应用团队则需要足够的上下文，才能区分预期行为与滥用。

法务和风险团队面临不同的担忧：现有记录是否足以支持公司事后作出的解释。当支撑证据仍然支离破碎时，一套自信的叙述价值有限。

供应商同样承受压力，因为客户依赖产品设计来获取其中一部分记录。客户无法独立恢复服务从未暴露或保留的信息。

Microsoft 说明了为何这些问题已变得迫切。该公司在 2025 年 3 月发布的安全智能体公告介绍了用于钓鱼邮件分类等任务的智能体，即对疑似欺诈信息进行整理和评估。

该公司将这些能力定位为减轻防御人员日常工作的方式。这提供了具体的部署背景，但并不能证明 Microsoft 产品存在 SecurityHQ 报告中的缺口。

这种比较关注的是采购主张。Microsoft 描述了智能体可承担的工作；SecurityHQ 则追问组织能否在事后说明被委派的活动。

这些主张应当纳入同一场采购讨论。当买方也能评估调查工作量、干预选项和证据可得性时，效率主张会更有价值。

对于安全运营中心——即负责监控和响应威胁的团队——减少日常工作负荷显然颇具吸引力。但无法解释的行动会在其他地方带来工作。

当情况发生变化时，收到智能体结论的分析师仍需了解其依据。另一位调查人员可能需要在原始任务结束后重新审查该决策。

因此，压力同时影响部署审批和持续运营。买方需要了解系统采用后的行为证据，包括其行动何时需要解释。

这并不意味着自主性天然不适合安全工作。它意味着，被委派权限的范围是判断这种运营交换是否值得的核心。

有用的自动化仍需要可解释的行动轨迹

核心矛盾在于：智能体在日常工作中节省的时间，与解释例外结果所需的投入之间存在张力。更快的执行只有在组织能够维护的边界内才有价值。

以钓鱼邮件分类为例，这只是一个说明性工作流，而非 SecurityHQ 报告的事件。一个智能体审查可疑邮件，查询关联信息，并给出处理结论。

一次有价值的调查应能关联邮件、所查询的信息、智能体身份以及最终行动。如适用审批，调查人员还需要将审批与行动关联起来。

记录某项任务已完成，只回答了一个更狭义的问题。它证明了终点，却未必解释系统如何到达那里。

可问责的行动轨迹必须连接指令、权限、执行和结果。 这种关联至关重要，因为其中任何一个要素都可能成为事件中的争议焦点。

指令可能是恰当的，而权限却过大。权限可能是恰当的，而执行过程中遇到的信息改变了任务方向。

另一种情况是，智能体可能正确遵循了被请求的工作流，但底层业务规则本身是错误的。问责同样必须容纳这种可能性。

完全围绕模型的记录，可能会忽视这些区别。模型只是接收指令、检索信息并调用互联工具的应用程序的一部分。

应用程序编程接口，即 API，是一个系统通过其请求另一个系统功能的软件接口。智能体活动可以跨越这些接口及其各自独立的记录。

每项服务都可以准确描述其本地交互，却仍让整体任务难以重建。缺失的要素是那些本身有效的记录之间的关系。

Salt Security 在 10 月 13 日发布的智能体安全调查结果提供了该问题的另一种视角。其研究结合了 380 多份调查回复与生产遥测数据。

仅 12.5% 的受访者表示，他们能够持续追踪所有智能体的完整路径。Salt 还报告称，17.5% 的受访者可以在生产环境中自动停止行为异常的智能体。

这些数字衡量的能力不同于 SecurityHQ 关于重建行动的问题。它们不应合并为一个共同评分，也不应被视作等同估计。

它们的关联在于概念层面：追踪行动与中断行动是控制的不同组成部分。事件发生后的完整解释，无法逆转其后果。

同样，停止一个工作流并不能解释它为何出现异常行为。买方需要评估两种能力，而不能假定其中一种能保证另一种。

因此，商业比较的范围不止于个别供应商之间的竞争。SecurityHQ 强调运营问责，Microsoft 描述被委派的安全任务，Salt 则突出追踪和遏制能力。

这些视角围绕一个共同的客户问题交汇。企业需要确保被委派的工作在跨产品边界时仍然可理解，而责任往往正是在这些边界上变得更难确定。

人工审批无法承担全部问责负担

人工审查仍是一个颇具吸引力的答案，因为它让人在重大决策附近发挥作用。其有用性取决于该人员能够检查和授权什么。

附着于模糊目标的审批，会为允许采取哪些行动留下争议空间。附着于具体行动的审批，则建立了更清晰的边界。

即便如此，调查人员仍需了解执行是否与获批请求一致。审批和执行描述的是不同的时点，其间的信息或系统条件可能已经发生变化。

当审批记录与实际行使的权限相符时，人工监督才能促进问责。 人的参与并不会自动补足缺失的技术历史。

这一区别对于那些期待最终审核者为整个工作流承担责任的业务领导者尤为重要。审核者无法有效评估系统未提供的信息。

对于决定将审批步骤置于何处的产品团队而言，这同样重要。中断每一项操作会增加摩擦，而审批整个任务则意味着授予更广泛的自主裁量权。

实际的权衡在于：哪些决策需要人工介入，以及哪些边界可以由软件直接执行。不同工作流应有不同答案，因为其潜在后果各不相同。

仅推荐回复的系统，与修改访问权限的系统，所涉及的权限问题并不相同。相关的比较对象是被允许执行的操作，而不是是否带有 AI 标签。

随着智能体跨越组织边界开展行动，身份问题也变得愈发重要。身份验证确认是谁或什么在发起请求；授权则决定该请求方能够做什么。

仅凭其中任一功能，都无法解释请求背后的业务目的。调查工作若能将技术身份与任务，以及委派任务的人员或流程关联起来，将更有助益。

NIST 的智能体身份工作为这一挑战提供了制度层面的参考。9 月，NIST 将软件开发确定为首个实施用例。

这项工作聚焦于在软件开发生命周期内识别、验证和授权智能体。这是一项实施工作，而非企业问责问题已得到解决的证据。

这一方向之所以重要，是因为问责在一定程度上取决于权限如何在软件中传递。标准和演示能够帮助人们以更一致的方式表达这些关系。

然而，技术身份无法决定在存在争议的业务结果中应由谁承担责任。组织仍需要对部署、维护、审查和紧急干预作出明确的责任划分。

清晰的记录与清晰的角色相互强化。记录有助于确定发生了什么，而角色则决定谁必须评估并回应这些证据。

同样的区别也适用于组织知识。可检索的团队知识库可以支持获取政策和职责信息，而执行证据则证明系统实际做了什么。

保持这些功能之间的区分，有助于避免一个常见错误：记录预期工作流，并不能证明某次具体运行遵循了该工作流。

该调查提出了自身无法解决的问题

SecurityHQ 的 AI 智能体研究提供了关于受访者所报告经验和信心的证据。它并未独立衡量这些组织内每个智能体的行为。

自我报告的准备程度可能不同于实际事件中的表现。受访者对重建、问责和智能体活动的理解也可能有所不同。

一位领导者可能描述了强有力的集中监督，但分散式部署仍可能不在其视野之内。另一位受访者即使拥有能力出色、但不熟悉内部流程的团队，也可能报告准备程度有限。

这些可能性并不会使研究结果失效，但会限制由此得出结论的确定性。

该调查支持对企业准备程度进行审视，而非对智能体失效情况作出普遍性估计。 其公开摘要不应取代对个别部署的测试。

公开公告和落地页未提供足够的方法论细节，无法证明样本具有广泛代表性。读者不应假定该样本反映了所有行业或所有规模的企业。

事件问题中将 AI 智能体与自动化结合在一起，也造成了另一项局限。由此无法明确，所报告的不确定性有多少来自较新的智能体，又有多少来自既有的自动化工作流。

在解读新颖性时，这一区别至关重要。长期以来，组织一直难以在软件集成、外包服务和共享运营流程之间分配责任。

智能体部署可能会使这一既有问题更加复杂，但并不会让所有底层弱点都变成新问题。将整个问题视为 AI 独有，可能会掩盖人们熟悉的控制失效。

政策与事件之间的关系也尚无定论。汇总结果无法说明哪些受访者在特定事件发生时已具备相关政策。

因此，这些结果无法证明政策未能阻止事件，也无法证明没有政策的组织表现更差。任何一种说法都需要额外证据。

SecurityHQ 的 AI 智能体研究也来自在安全和监测领域具有商业利益的组织。该背景值得披露，但不应因此自动否定其观察结果。

恰当的审慎态度，是审查定义、方法论和可复现证据。商业赞助与有用发现可以同时存在。

对与 Salt 研究结果的比较也应保持类似审慎。不同的问题、样本群体和测量方法，使得无法对这些研究中的企业准备程度进行直接排名。

在广泛担忧上的一致，并不能证明对测得普遍程度存在一致。各项研究分别就可见性、权限和干预提供了独立观察。

该研究也未证明集中更多记录总能提升安全性。记录可能包含敏感信息，而获取调查证据本身也带来相应责任。

其分析含义更为有限：组织需要为其所委派的决策保留充分证据。何谓充分，取决于相关操作及其后果。

一个有说服力的回应，应展示特定工作流在发生故障时如何仍可追溯责任。若声称某个平台让所有智能体都可问责，则需要规模大得多的证据基础。

关注事件证据、产品控制与身份实施

未来数月，最有价值的发展将表明，组织能否将口头上的问责转化为可证明的运营能力。仅有采用公告，仍无法解决这一问题。

第一个信号，是已发布的事件重建报告和受控演练的质量。有价值的说明应将被委派的任务、相关权限、操作序列和干预措施关联起来。

它们还应说明调查人员无法恢复哪些信息。一份虽不完整但坦诚的重建报告，比声称团队始终保有控制权更能提供证据。

在不同工作流中反复演示，将增强人们对问责实践能够超越预设示例的信心。持续存在的缺口则会强化 SecurityHQ 提出的担忧。

第二个信号，是将智能体执行与调查和遏制相联系的产品证据。采购方应关注供应商向客户实际展示的内容，而不是依赖笼统的治理表述。

有意义的演示应展示调查人员如何跨关联服务追踪一项任务。它还应展示获授权的操作人员中断工作流时会发生什么。

中断的时机和范围至关重要。阻止下一步操作与撤销已完成的变更不同，产品演示应使这种区别易于理解。

当客户能够验证控制措施的行为时，更清晰的控制能力将支持更广泛的委派。本地记录之间无法解释的缺口，则会强化应缩小权限范围的理由。

第三个信号，是围绕智能体身份和授权的实施进展。NIST 公布的软件开发用例提供了一个可关注技术产出的具体方向。

实际示例可能有助于阐明，当软件在服务之间流转时，被委派的权限如何保持可追溯性。其价值取决于组织能否将该方法应用于真实工作流。

进展将减少技术身份方面的模糊性，尽管业务所有权决策仍将由企业承担。延迟则会让客户更加依赖特定产品的方法。

下一个有价值的基准，是组织能否在现实条件下解释并中断被委派的活动。 这一基准将研究发现与采购方已经面临的决策联系起来。

对于评估部署的读者而言，SecurityHQ 的 AI 智能体研究提供了一个理由，促使其审视现有保证背后的证据。可以从一个已有负责人、且影响重大的工作流开始。请该负责人利用目前可获得的记录解释一次已完成的运行过程。追踪指令、权限、操作和结果。然后确认当这些要素不再一致时，谁能够进行干预。缺失的关联会揭示一个比对 AI 安全性的笼统担忧更具体的问题。它们也能让与供应商和内部团队围绕必须改进之处的讨论更加清晰。在授予更广泛权限之前，请求进行一场能使操作历史和干预边界清晰可见的演示。当结果存在争议时，您的组织能否为这一解释辩护？