Sean Roche，Obsidian Security 高级产品营销与价值工程总监——访谈系列

Sean Roche, Obsidian Security 的高级产品营销和价值工程总监，领导跨职能项目，专注于 SaaS 安全、AI 安全和市场推广策略。他在开发公司的第一个统一用例框架中发挥了关键作用，以可衡量的业务成果为目标，协调销售、营销和客户成功团队，同时还监督了 GenAI 和 AI 智能体安全解决方案的发布。在加入 Obsidian Security 之前，Roche 曾在包括 Forter、Aviatrix 和 Okta 在内的公司担任领导职务，专注于业务价值咨询、定价策略、客户价值工程和面向高管的投资回报分析。他的背景结合了网络安全、企业软件策略和金融研究，给他带来了丰富的经验，将技术能力转化为企业客户的可衡量业务影响。

Obsidian Security 是一家网络安全公司，专注于保护 SaaS 应用程序、AI 智能体、身份和企业集成，跨越现代云环境。该公司提供一个统一的平台，旨在帮助组织检测威胁、管理 SaaS 安全态势、管理数据访问并监控业务关键应用程序（如 Microsoft 365、Salesforce (CRM ) 、Slack 和其他云服务）中的风险活动。近年来，Obsidian 扩展到 AI 智能体安全，帮助企业实时了解自主 AI 系统如何与 SaaS 平台、数据和工作流交互。由来自 CrowdStrike (CRWD ) 、Okta、Cylance 和 Carbon Black 等公司的安全领导者创立，Obsidian 将自己定位为一个端到端的 SaaS 和 AI 安全平台，旨在解决云和智能体 AI 环境日益增长的复杂性。

您的职业生涯始终围绕业务价值、风险策略和 SaaS 安全的交汇领域展开，现在您领导 Obsidian Security 的价值工程和产品营销。是什么吸引您关注 AI 驱动的 SaaS 生态系统的安全，在应对 OpenClaws 等新兴智能体技术时，Obsidian 的方法与其他方法有何不同？

在我的整个职业生涯中，最大差距始终是安全无法看到的东西，因为这就是真正发生安全入侵的地方。我们在事件中看到这一点，断开或未管理的系统会造成暴露，传统控制措施根本无法捕获。并且我亲眼见证了现代桥梁被人们用来连接到主要平台，或者连接在正常安全可见性之外，甚至在 IT 团队认为已经禁用它们之后。这些经历使我清楚地认识到风险有多少存在于系统之间的缝隙中，而不仅仅是在我们认为已经保护的系统内。

这种现实正在从影子 IT 转变为影子 AI，新的工具和智能体驱动的工作流程可以以治理策略难以跟上的速度出现和传播。许多安全方法试图将所有内容集中到同一个控制平面下来管理。但这种模型在分布式环境中会崩溃，尤其是在关键数据和活动发生在您不拥有和无法完全控制的第三方应用程序中时。

这就是吸引我关注 AI 驱动的 SaaS 生态系统的安全的原因，也是我认为 Obsidian 的方法如此引人注目的原因。SaaS 安全入侵的数量已经增加了 300%，然而，大多数组织仍然缺乏对这些应用程序如何使用的适当可见性。这就是我们关注的差距，因此您可以了解企业内部实际发生了什么以及暴露在哪里。随着 OpenClaws 等智能体技术的成熟，这种方法变得更加重要，因为风险不仅仅在于智能体是否可以访问某些数据，还在于它可以访问什么以及可以多快地采取行动。

智能体 AI 系统（如 OpenClaws）在 NVIDIA (NVDA ) GTC 之后引起了显著关注。从您的角度来看，它们与早期 AI 工具相比，在安全风险方面有什么根本区别？

了解非人类身份是什么以及如何保护它们已经成为安全团队的关键任务，因为 68% 的 IT 安全事件现在涉及机器身份，半数被调查的企业由于未管理的非人类身份而经历了安全入侵。安全行业主要专注于 SaaS 安全态势管理和人类身份管理，而非人类身份在后台大量增加。现在，随着组织大规模部署具有管理权限的 AI 智能体，治理缺口已成为严峻问题。

OpenClaws 等智能体系统展示了真正智能体 AI 的前景和风险。这是我们最早见到的几个案例之一：AI 以真正的自主性在现实环境中运行，超出了狭窄的、受监督的工作流程。

当这些能力变得更加普遍时，安全风险迅速变化，降低了非专家与这些关键系统交互和潜在利用的门槛。人们已经将 AI 智能体连接到他们的 SaaS 环境中，并通过 API 密钥、原生集成和第三方应用程序以多种方式扩展威胁格局。然而，每个新智能体启用的工作流程都会将访问路径的数量乘以倍数。

最近的 Vercel 安全入侵事件 说明了安全团队面临的日益增长的威胁。当您授权第三方应用程序时，您实际上默认信任所有接触该应用基础设施的参与方，包括云服务商、开发者，以及他们自己连接的服务。大多数组织不知道他们实际上同意了什么，这个问题因智能体 AI 的无序扩散而被放大。

许多 AI 智能体在没有真正的控制装置的情况下运行。当您没有能够识别智能体活动的痕迹，或只有薄弱的安全边界时，很难知道智能体做了什么，涉及了什么，改变了什么，直到事后。这种组合就是使风险状况与早期 AI 工具根本不同的地方。

您将 OpenClaws 描述为由于其广泛的权限和自主性而可能暴露新的攻击面。您能否带我们了解一个真实的场景，在这个场景中，这种风险对企业来说是有形的？

像 OpenClaws 这样的风险变得有形的那一刻是，当这些智能体从孤立的任务转移到真正的生产环境中，这已经开始发生了。

大多数组织专注于确保正确的人可以访问智能体以及智能体按预期行为。然而，很少有组织思考当智能体开始与另一个智能体交互时会发生什么。

这就是攻击面扩大的地方。一旦一个系统的输出（如 Slack 消息或 Jira 工单）成为另一个系统的触发器，领导者就会失去对交互的控制，并且无法保持一致的可见性和审计跟踪。这些智能体同时也正在通过 SaaS API 连接，许多 API 仍然缺乏适当的网关或安全保护。

平均而言，企业已经运行了数百个智能体，这个数字在过去一年中几乎增加了 100 倍。当团队实际查看时，38% 的智能体具有中等、高度或危急风险，大多数智能体没有登记负责人，其中一些由已不存在的账户创建，却仍与生产系统保持有效连接，而且没有任何执行历史。

弥合这个缺口需要在应用程序本身内部具有深入的可见性，以更好地了解这些凭证实际上可以做什么，在每个系统中，对每个数据集，对每个潜在调用者。没有这种适当的上下文，您就只能掌握一半情况。领导者还需要从检测转向运行时强制控制，在动作执行时就将其拦截，确保在动作完成之前阻止它，而不是等到损害已经造成之后。

许多组织认为他们已经具备了足够的 SaaS 安全性。这些假设在智能体 AI 出现时会在哪里破裂？

许多组织认为他们已经“解决”了 SaaS 安全问题，但这种假设正在被智能体 AI 的采用加速所挑战。SaaS 安全通常被视为一个需要勾选的框：预算被批准，工具被部署，问题被认为已经处理。但在实践中，SaaS 环境的底层 SaaS API 从未被完全纳入控制，主要是因为企业对 API 层发生了什么以及哪些 SaaS 资产相互交互几乎没有可见性。

这在企业中创建了一个结构性的盲点，即他们可能会保护身份和端点，但往往缺乏对 SaaS 数据如何被访问以及如何对其执行操作的清晰视图。一旦 API 发挥作用，许多组织仍然直接通过开放的互联网访问关键系统，而不知道 API 驱动的交互的规模或行为。

智能体 AI 正在暴露这个差距，产生挑战的速度超过团队解决问题的速度，并因此成为 API 对话的催化剂。

当处理自主 AI 智能体时，智能体可以跨多个系统访问和移动数据，并对数据执行操作，企业应该如何重新思考治理？

没有领导者希望此时放慢 AI 的采用速度，尤其是在加快推进和展示可衡量成果的压力不断上升、甚至连 token 消耗量都被纳入评估的情况下。许多情况下，AI 的要求直接来自顶层，CEO 向董事会或甚至公众利益相关者报告进展，这只会加剧快速采用 AI 的压力。在这种环境中，“以任何代价实现 AI”成为默认的态度，配置错误和过度授权的访问无法通过传统治理周期在现实条件下足够快地纠正。

问题在于智能体系统不会等待补救。它们可以发现系统，链接操作，并跨多个 SaaS 应用程序执行工作流程，所有这些都可以在几秒钟内完成，往往在人类察觉之前、更不用说介入之前，就已经完成了 十个或更多步骤。

这就是治理不再仅仅关乎在开发生命周期的早期捕获问题，而是越来越多地关乎智能体实际采取行动时的控制。安全领导者无法有效地治理智能体，如果控制仅在滥用之后发生。

在一个智能体在 SaaS 系统上做出自主决策的世界中，唯一可行的方法是运行时治理。这需要超越事后检测，检测和阻止权限升级、过度数据访问和违反策略，在它们影响组织之前。这些控制必须与 OWASP 标准和行业最佳实践保持一致，确保智能体在明确和可执行的界限内运行，以便团队可以跟上智能体 AI 的采用速度，而不会损害创新。

从技术角度来看，智能体 AI 在 SaaS 环境中引入的最常被忽视的漏洞是什么？

当组织采用一个全新的 SaaS 工具时，他们越来越多地发现 AI 功能被默默地添加或默认启用。问题在于这些功能通常不具有与安全团队依赖的传统 SaaS 功能相同的配置控制或可审计性。因此，当采取行动时，很难区分是人类用户还是自主智能体发起的。在许多情况下，企业没有禁用 AI 功能的选项，因为这些功能嵌入在 SaaS 应用程序本身中。

这种模糊性为安全和治理创造了一个巨大的盲点。如果嵌入式 AI 功能代表用户做出决定，组织通常没有明确的方法来跟踪意图、理解决策逻辑，甚至确认是什么触发了某个操作。

风险变得更加明显，当您考虑 SaaS 内部的 AI 供应链时。这些嵌入式 AI 功能通常依赖于上游模型、服务和第三方集成。如果供应链的任何部分都被破坏、降级或操纵，SaaS 应用程序中的 AI 就可以将可信的业务应用程序转变为攻击路径的积极参与者。

SaaS 内部的 AI 层已经形成独立的供应链，并带来了一类需要单独监控和治理的新风险。没有对这些嵌入式 AI 系统的行为和所依赖的数据的可见性，组织就会对其 SaaS 攻击面的日益增长的部分视而不见。

您曾广泛地量化了业务价值和风险。组织应该如何衡量与不安全的 AI 智能体相关的财务和声誉风险？

如果 AI 智能体遭到滥用或引发安全入侵，立即的影响不仅仅是事件本身，还有随之而来的组织响应。这种事件将减慢公司采用和扩大 AI 的速度，因为领导者变得更加谨慎。一旦信任被打破，就会更加困难地重新启动驱动价值的创新引擎。

这种动态不仅限于内部团队，还扩展到外部利益相关者，包括董事会、客户和股东，他们都期望负责任的部署。任何与自主智能体有关的失败都会迅速演变为受托责任和声誉问题。当安全性不是设计的一部分时，组织就会被迫进行关于控制和安全性的反应性对话，这不可避免地会减慢整个业务的决策速度。

还存在一个经常被忽视的结构性财务风险。当人们感知到的智能体 AI 潜在损害范围扩大时，公司往往会变得更加保守地分配资本。在某些情况下，这意味着保留资金或延迟投资，以保护自己免受潜在的事件的影响。

在这种意义上，保护 AI 智能体不再仅仅是纯粹的风险缓解练习，而更像是收入和增长的对话。能够有信心地部署 AI 的组织（知道智能体是受治理和控制的），就能更快地推进，而那些没有这种信心的组织则会自然地减慢自己的速度。在 2026 年，这种将速度与信任相结合的能力正在成为一种超能力。

在快速 AI 采用和负责任的部署之间显然存在紧张关系。对于希望创新而不增加风险的公司来说，应当采取怎样的平衡策略？

目前，AI 采用和负责任的部署之间最大的差距之一是沟通。许多企业正在积极地跨 SaaS 环境使用 AI，但他们并没有始终如一地就其使用情况以及实施的保障措施进行明确的外部对话。这种缺乏透明度实际上会增加风险，因为它让客户和合作伙伴假设最坏的情况，而不是了解实际的控制措施。

更平衡的方法将负责任的 AI 使用视为价值主张的一部分，而不仅仅是内部的合规性练习。企业有机会更明确地说明如何在环境中治理 AI，包括它可以和不能做什么以及与敏感系统交互时存在什么保护措施。这种清晰度有助于建立信任，以便安全地扩大 AI。

能够清晰地表达如何在其 SaaS 环境中使用 AI 以及展示其被结构化和可观察地控制的公司，将能够在不增加感知风险的情况下更快地创新。

随着更多企业尝试智能体 AI，安全团队今天应立即采取哪些措施，避免遭遇下一起登上头条的安全入侵？

智能体 AI 不仅引入了一种新的风险类别，还加速了组织无法看到的风险。事实上，影子 AI 使平均安全入侵成本额外增加了 $670K。然而，根本问题是可见性。当组织不知道 AI 在哪里被使用或如何与系统交互时，检测和遏制事件需要更长时间，直接增加了财务和监管影响。

第一步是建立整个业务的可见性。安全团队需要对批准和未批准的 AI 使用情况有一个清晰的图景，不仅是在应用程序级别，还要覆盖 AI 主动做出决策或影响决策的工作流程。

一旦可见性存在，重点就会转移到将其转化为能够强制落实的策略，并将其嵌入实际开展工作的系统中。这意味着与业务团队就 AI 的使用方式达成一致，然后从文档转移到在端点、SaaS 平台和智能体系统中运行的技术控制。控制措施越早引入执行路径，高成本和难以遏制的事件出现的可能性就越小，这些事件可能源于影子 AI 和自主智能体。

展望未来，随着智能体 AI 系统深入嵌入企业基础设施，安全格局将如何演变？

组织需要原生 AI 安全来应对 AI 驱动的威胁。这些系统必须以机器速度运行，基本上重塑安全运营。人类仍将参与其中，但将转向战略监督，应用上下文和判断，AI 尚未具备这些能力。

这种转变还改变了安全团队的构成。团队可能不会缩小，但他们的范围将扩大，单个安全专业人员将通过自动化和 AI 驱动的工具负责更广泛的安全范围。

此外，在智能体环境中，监控和检测是不够的。组织需要实施真正的强制控制机制。这意味着需要建立像开关一样的机制：开启或关闭功能、实时限制行为，并隔离行为异常或可能危及企业其他部分的系统。AI 中的供应链风险太大了，不能不在架构中嵌入紧急停止控制。

展望未来，AI 将继续加速，可能超越人类的速度和能力。但对话不能仅仅关注风险；它还必须包括机会。就像养育孩子一样，AI 将成长和犯错，但它也有超越我们的能力。赢家将是那些大规模采用 AI，同时建立必要控制系统、确保安全且可信地部署 AI 的组织。

感谢您带来这次精彩的采访。希望进一步了解的读者可以访问 Obsidian Security 。