Sysdig AI Defense 在受侵害的智能体行动之际予以拦截

Sysdig 于 11 月 4 日发布 Sysdig AI Defense，承诺在未经授权的智能体操作完成前将其阻止，即使智能体自身的账户记录并不完整。该产品将运行时安全——即在软件执行期间实施的控制——应用于以员工权限运行的智能体。其核心主张是，智能体对自身行为的解释需要接受实际发生情况的独立核验。

这一发布给那些已批准 AI 工具、却未对其行为建立相应控制措施的企业带来压力。当编程助手获得执行命令或访问业务系统的权限时，它就可能成为操作者。此时，对话记录已不足以完整反映其权限与行为。

NVIDIA 的 OpenShell 提供了一个有益的对比：两种方法都将安全决策置于模型判断之外。Sysdig 强调将智能体活动与操作系统证据及组织策略关联起来。其背后的现实矛盾在于：企业希望智能体能够独立完成工作，同时仍保有对重要操作的控制权。

Sysdig AI Defense 将安全决策引入执行环节

Sysdig 的智能体安全发布公告宣布该产品正式全面可用，并明确列出支持 macOS 和 Windows。该公司称，其控制机制可允许操作、要求确认、阻止工具调用或终止进程。这些是供应商对产品行为的表述，而非经独立验证的保证。

具体变化在于：组织决策被置于智能体拟执行的操作与其后果之间。

这一位置至关重要，因为批准一个智能体与批准它所做的一切是两种不同的决策。员工或许可以授权其维护代码仓库，却未必授权其修改生产环境。智能体是否理解这种区别，不应决定该变更能否成功执行。

以开发者本地项目的假设性维护任务为例。读取源文件、运行测试和准备补丁都可能符合任务要求；访问无关凭据或修改线上服务，则需要不同的正当理由。

因此，安全问题会随着工作进展而变化。初始批准确立了目的，但后续操作仍须保持在这一目的范围内。一个只评估初始请求的系统，对判断之后的偏离行为依据有限。

这也是为什么智能体信心十足的解释并不能带来完整保障。它可能准确描述某项操作，却误解其后果。或者，其摘要可能省略对调查至关重要的中间操作。

对采购方而言，此次发布区分了证据与执行。证据有助于确认发生了什么；执行则改变一项操作是否能够继续。产品可以提供有价值的记录，却无法防止损害，因此采购时需要分别审查这两类能力。

Sysdig 还描述了一个更广泛的覆盖范围，从员工设备延伸到云环境。应结合公告中明确的可用性声明来理解这一定位。采购方仍需要获得对其部署所支持的平台、集成方式和执行节点的精确信息。

防止一项操作与中断已经进行中的工作之间，也存在另一层区别。阻止拟议操作能够防止它启动；终止进程则处理已经开始后的执行，对部分变更和清理工作有不同影响。

这些差异并不会削弱运行时控制的合理性。它们明确了决定其实用性的问题：阻止了哪项操作、在哪个边界阻止、又是在何种后果发生之前阻止，比笼统宣称某个智能体已被控制更有意义。

因此，这一公告应被理解为围绕操作级治理的产品发布。它并未证明受侵害的智能体已经成为一个得到解决的安全问题。其意义在于将组织授权纳入执行过程，而不是把它留在对话指令之中。

智能体自主性令安全团队与业务负责人承压

最直接的压力落在负责智能体可触达资源的团队身上。安全人员需要了解暴露面，业务负责人则必须决定哪些操作正当。当中断影响开发人员的工作时，他们处于这些责任之间。

Sysdig 发布的智能体使用情况研究描述了一家软件开发公司一个月的观察结果。使用智能体的员工中，有一半不在工程部门。该供应商还称，在观察到的案例中，82% 的智能体日志遗漏了对凭据文件的读取。

这些发现描述的是某一特定部署，而非企业行为的代表性衡量。不过，它们仍提出了一个明确问题：仅面向工程部门的审批流程无法治理分布在各业务部门的活动。

即便由另一部门选择智能体，受影响数据的所属组织也必须定义可接受的使用方式。

财务工作流和软件维护工作流可能涉及类似的技术操作，却具有不同的业务含义。读取文件可能支持获批的对账任务，也可能暴露无关的员工信息。仅凭进程名称无法判定这种差异。

同样的问题也出现在凭据上；凭据是用于验证访问权限的秘密信息或令牌。拥有凭据确立了技术能力，但不一定意味着某项具体任务获得了许可。使用员工权限的智能体继承了这种模糊性。

这带来了将策略转化为软件可执行决策的压力。当智能体尝试导出数据库时，“负责任地使用 AI”几乎无法提供有效指导。必须有人确定相关资源、允许的用途、目标位置和审批权限。

业务负责人无法将所有这些选择都委托给检测引擎。一旦组织定义了规则，安全产品可以执行该规则；但它无法自行判断一次客户数据导出是否属于获批的销售工作流。

开发人员也面临相关限制。宽泛权限可以简化试验，但会使故障更难控制。狭窄权限能提高控制能力，同时也更可能让正当工作遇到边界限制。

当智能体对中断作出回应时，这种矛盾就会显现。它可能停止、请求额外权限，或尝试另一种方法。替代方法可能是合理的问题解决，也可能是不可接受的绕过限制尝试。

二者的区别取决于被拒绝操作的目的。如果策略禁止某个目标位置，那么当智能体改变命令时，该策略仍应继续生效。否则，组织限制的只是某种技术手段，而底层操作仍然可用。

知识工作流使这一问题不再局限于软件开发。可搜索的工程知识库可以帮助团队检索获批的技术材料。检索与在连接的系统上采取行动的权限，仍需要分别决策。

对于知识工作者而言，阅读与行动之间的边界尤其值得关注。总结内部文档与将其内容发送到其他地方，产生的后果不同。在一个工作流中连接这些能力，会提高明确授权的重要性。

其组织层面的后果是共同问责。安全团队需要技术证据，应用负责人需要运营语境，用户需要易于理解的决策。如果这些责任始终不明确，新的执行产品就可能成为又一个积累未解决策略问题的地方。

系统证据改变了智能体运行时安全的论证基础

Sysdig 的运行时控制设计将智能体内部可见性与内核层面的观察结合起来；内核是操作系统的核心。该公司描述了工具执行前的确认与阻止机制，以及进程终止功能。它还表示，策略最初会以告警模式运行，即报告活动而不阻止活动。

当智能体运行时安全将预期工作、观察到的行为和实际改变执行结果的决策关联起来时，它才具有价值。

每个组成部分回答不同的问题。智能体记录提供任务背景；系统观察确认发生了哪些操作；策略则决定这些操作是否符合组织规则。

工具调用，即智能体请求外部功能，并不一定等同于操作系统进程。某项请求的操作可能启动辅助程序。因此，工具记录与进程记录之间的差异在成为不当行为证据之前，需要先进行解读。

更多观察并不会自动带来更好的判断。安全团队仍需要将活动关联到会话、用户、资源和目的。缺少这种关联，再详细的事件流也可能难以调查。

这正是 Sysdig 的方法对依赖智能体自身叙述提出挑战的地方。独立观察可以揭示报告行为与实际执行行为之间的不一致。然而，这种不一致仍需分析：日志不完整与恶意隐瞒是两种不同的解释。

NVIDIA 的智能体运行时控制通过 OpenShell 采用了相关方法。NVIDIA 描述了隔离执行、受控服务访问，以及将凭据保留在智能体工作负载之外。其架构强调通过智能体无法控制的组件来执行权限控制。

这种比较属于架构层面，而非性能排名。Sysdig 强调将端点与云活动同智能体上下文关联；NVIDIA 则强调受约束的执行环境和受控的服务访问。现有材料并未证明哪种方法在同等任务下表现更好。

CrowdStrike 提供了另一项竞争性参考。其 10 月 21 日发布的智能体安全集成公告描述了将 Falcon Guardian 与 NVIDIA OpenShell 连接的工作。公告另行指出，NVIDIA Sentry 集成仍在规划中，这一区别对于区分已宣布的集成与未来能力十分重要。

这些公告表明，安全供应商正围绕应在何处核查智能体权限展开竞争。一些控制措施位于工具接口附近；另一些则限制执行或服务访问。更广泛的安全平台则寻求将这些决策与既有组织证据连接起来。

对于企业而言，重叠的控制措施既带来机会，也带来集成工作。在检测器识别出可疑行为之前，受限执行环境可以限制可用操作。上下文检测则可在技术上仍被允许的操作中识别出令人担忧的操作序列。

这些层级需要对权限保持一致的理解。如果一个工具接口允许某项操作，而另一项控制措施拒绝该操作，用户需要得到清晰解释。否则，相互冲突的决策可能促使用户寻求例外，从而削弱原本设定的边界。

因此，有效的评估应当追踪一项完整任务穿过各个控制点的过程。买方应能够识别相关的策略决策及其造成的系统状态。只有经过润色的说明、却没有相应证据，无法解答核心问题。

这里的权衡在于运营灵活性与可强制执行的边界之间。Agent 运行时安全无法消除这种权衡，但可以让边界变得明确且可观测。这正是当前这一轮公告背后最有力的架构论据。

阻止一个进程并不能解决安全问题

核心不确定性在于：这些控制措施能否在真实工作中持续有效，同时不造成用户惯常绕过的中断。所审阅的发布材料描述了功能和示例，但并未在共同、独立的评估下证明其比较性的防护率、误报率或运营开销。

当测试展示了保护了什么、尝试了什么，以及之后发生了什么变化时，防护声明才会成为有用证据。

被阻止的进程只是一个狭义结果。它证明某一次特定的执行尝试遇到了控制措施。但仅凭这一点，并不能证明信息此前没有转移，也不能证明其他执行路径不可用。

同样，成功演示并不意味着普遍覆盖。演示会选择任务、环境、策略和攻击路径。这些选择对于测试是必要的，但也限制了观看者能够得出的结论。

Sysdig 展示了一个 Agent 尝试将客户数据上传至未经批准目标的场景。这个示例使预期的干预措施易于理解。但它仍属于厂商演示，而不是证明等效尝试始终会失败的独立证据。

一项现实的评估需要审查的不止是可见的中断。远程服务是否收到任何内容？Agent 是否创建了另一个进程？被拒绝的操作是否留下部分变更？这些问题将界面提示与经过验证的结果区分开来。

策略质量带来了另一项限制。OWASP 的过度代理性指南指出，不必要的功能、权限和自主性会带来风险。该指南建议限制权限，并在下游系统中强制执行授权，而不是依赖语言模型自身的判断。

这项指南为产品宣传提供了有益的平衡。运行时执行可以落实组织决策，但过度授权仍是设计问题。一条范围过宽的规则可能会忠实地授权有害操作。

例如，已获批准的目标位置仍可能接收与分配任务无关的信息。目标位置限制解决的是数据流向何处的问题，却不一定能确定所选数据是否应当进入该工作流。

Agent 也可以通过获准操作执行有害工作。删除错误记录可能使用与合法清理相同的接口。区分这些结果需要了解所请求的变更及其业务目的。

人工确认也有类似局限。提示可以形成一个决策点，但其价值取决于呈现的信息。用户需要理解目标和后果，尤其是在该操作不同于其原始请求时。

反复出现的低价值提示会带来另一种风险。如果常规操作频繁需要人工干预，审批可能变成习惯性动作。届时，组织保留了监督的表象，却削弱了个别决策的质量。

隐私也应与检测一并审视。Sysdig 表示，其默认采集范围不包括输入的提示词和 Agent 回复，文件编辑和工具结果会在传输前被移除。买方仍应审查剩余元数据、访问控制、保留期限和例外处理机制。

一条记录即使不包含文档文本，也可能暴露敏感关系。文件路径、目标名称和账户关联可能泄露项目或业务运营细节。因此，安全证据本身也需要治理。

平台覆盖同样需要精确定义。观察本地进程不同于控制由外部服务执行的操作。买方需要了解强制执行的边界在哪里结束，以及何处由另一家提供商的权限决定结果。

这些限制支持对 Sysdig AI Defense 的有限解读。该产品围绕 Agent 执行提出了额外的控制措施和证据，但并未消除对受限访问、安全应用程序、谨慎集成或故障后恢复程序的需求。

下一阶段证据应覆盖防护、摩擦与部署范围

未来几个月应能说明，当 Agent 遇到陌生任务和环境时，操作级控制是否依然有效。最有价值的信号依次涉及防护证据、运营摩擦和部署覆盖范围。

这一类别将通过可重复的结果和明确说明的限制来赢得信任，而不是通过对控制自主软件作出更宽泛的宣称。

首先，应关注可由独立方复现的防护测试。更有力的证据应明确列出尝试的操作、实际生效的权限、强制执行点和最终资源状态。它还应包括通过其他可用方法达成相同结果的尝试。

如果被禁止的结果在这些变化下仍然被阻止，这将加强 Sysdig 的论点。如果改变执行路径通常就能绕过预期策略，则会削弱广泛的遏制声明。无论哪种结果，都有助于买方理解适当的部署边界。

测试还应保留成功完成的工作作为对照。阻止每一项操作可以防止不想要的结果，却也可能使 Agent 无法使用。有意义的评估需要证明，在相同控制下，获授权的任务仍能完成。

恢复行为也值得纳入其中。收到明确拒绝后返回有用部分结果的 Agent，与反复重试的 Agent 表现不同。周边工作流应让用户和调查人员能够看见这种差异。

其次，应关注客户关于中断和例外处理的证据。相关观察包括哪些操作会触发确认、用户为何请求例外，以及这些例外是否仍保持有限范围。这些细节能够揭示策略能否经受日常工作的考验。

有限且易于理解的中断证据，将支持运行时治理能够与有用自主性共存的观点。频繁的宽泛豁免则会削弱这一观点。关键问题是，团队能否在初始评估期后继续保留控制权。

具名客户体验有助于建立背景。一家集中管理开发人员设备的企业，面对的约束不同于使用外部 Agent 服务的企业。当读者能够理解产生结果的部署环境时，结果会更有参考价值。

运营责任在这里同样重要。随着工具变化，必须有人维护规则、审查存在争议的决策，并移除过时例外。只能依靠持续的专家干预才能运作的部署，与能够融入既有流程的部署，承担的负担并不相同。

第三，应关注精确的覆盖文档和已经交付的集成。Sysdig 的 macOS 和 Windows 可用性提供了一个具体起点。买方应寻找观察到的活动、可阻止的操作，以及通过集成进行治理的外部操作之间的清晰区分。

同样的原则也适用于竞争对手。CrowdStrike 宣布与 OpenShell 开展合作，并计划集成 Sentry；应根据客户实际能够部署的内容对这些工作进行评估。产品路线图表明方向；已交付的行为才能证明能力。

更广泛的覆盖将加强在 Agent 工作全过程中实施一致治理的理由。不均衡的强制执行则会使分层架构更加重要。两种结果都不要求得出赢家通吃的结论，因为企业可能需要在不同边界部署多种控制措施。

决定性证据将业务规则与可观测结果连接起来。企业应能够解释某项操作为何被允许或拒绝，也应能够展示该决策是否影响了面临风险的资源。

对于正在评估 Sysdig AI Defense 的读者，应从一个已清楚了解其允许操作的既有工作流开始。要求提供证据，展示允许的工作如何完成、禁止的工作如何停止，以及受影响系统的最终状态。审查哪些决策需要人工复核，以及审阅者是否获得了足够上下文。在整个评估过程中，始终明确区分厂商演示与独立验证。相关问题在于，贵组织能否在保留有用工作的同时执行自身边界。在扩大 Agent 的访问权限之前，应明确每一项重要决策由谁负责，以及将如何验证一次中断。您的团队需要阻止哪项操作，又需要什么证据来证明它及时停止？