Building an AI Guardian for Enterprise with Onyx Security CEO Maxim Bar Kogan

随着你通过“眼睛”以指数级方式做越来越多的事情，真的会开始出现非常糟糕的动作。最近我们已经看到了一些这类情况：agent 会意外发布它们本不该发布的代码和 token。可以说，enterprise（企业）现在开始意识到，风险已经指数级增长，而且他们没有任何办法阻止这种采用。现在他们只能想办法降低这些 agent 动作不合法或不正确的概率。我们当然可以去看大量关于这些 agent 过去如何行为的历史数据，但如今企业并不愿意让 Anthropic 或 OpenAI 获取这些历史数据，因为他们知道这些公司非常“饥渴”于数据，而且会想用这些数据来训练模型。

各位听众，大家好。欢迎回到 KnowPriars。今天和我一起的是 Maxim Bar Kogan，他是 Onyx Security 的联合创始人兼 CEO。Onyx Security 是一家位于 Israel 的 startup（初创公司），由研究人员、数学家和工程师组成，专门构建用来监视 AI agents 的 agents。我们聊了专用模型训练、mythos、alignment research，以及 Israel 在 security 以及如今 AI 领域的生态。欢迎。

Maxim，非常感谢你来参加。

谢谢，很高兴来到这里。

现在，大家对 security，以及 AI 对 security 的影响，显然比几个月前担心得多得多。两年前你们创办公司时，关于风险的主流叙事基本还是“给 chatbot 做 DLP”——比如员工往 ChatGPT 里输入了什么。现在我们显然面对的局面还不算彻底恐慌，但已经接近全市场范围的恐慌了。你们当初创业时，是怎么决定把赌注押在 agent actions 上的？

你看，我觉得对我们来说，关键转折点是 AutoGPT。我觉得 AutoGPT 某种程度上让所有人——也包括我们——的想象力彻底放飞了，因为它是一个

你能提醒一下听众那是什么吗？

当然。AutoGPT——如果我不知道背后那个人是谁，还请见谅，但我是他的超级粉丝——据我所知，他们做出了第一个真正运行在 LLMs 之上的自主 agent。也就是说，这种 agent 不只是让 LLM 生成文本，而是让它决定要做什么，然后再给这个 agent 相应的 API 访问权限去执行那件事，也就是给它一个完成该事的工具。接着它会在一个循环里反复这么做。所以从理论上说，它基本可以让 agents 去完成非常复杂的事情，任何一个人能在电脑上完成的事都可以。

当然，先说明一下，当时它并没有真正运作得那么好；时机太早了，models（模型）也还不够好，GPT-four 也还不够好。但我觉得，它确实让所有人瞥见了未来的一角：如果 models 足够好了，会怎样？然后基本上沿用同样的结构，我们就能拥有非常强大的 agents（智能体）替我们做事。我觉得从很多方面看，今天的 cloud code 和当年的 AutoGPT 并没有那么不同。我认为他们又一次有点太早了，早于 models 准备好的时间，但概念是对的。而当时一直留在我脑海里的想法是，我那时就已经非常 eye pilled 了。所以我当时在想，天哪，models 会变得比我们聪明得多。

当这种情况发生时，我们该如何监督这些比我们更聪明、能力又非常强的 agents？我们怎么才能安心让它们替我们做事，尤其是当它们开始管理真正重要的事情时？总有一天，它们会管理你的供水、你的电力、你的 power grid（电网）。对吧？你要怎么控制它们？

这几乎就是那个让我有点着迷、反复琢磨的核心问题。只是我也同样太早了。所以我觉得，在那个时候，enterprise（企业）还根本没有在使用任何 agents，市面上也几乎没有什么 agents。那时我和很多 security（安全）采购方聊，他们都说，哦，兄弟，你这也太超前了。

就像，这种事根本不会发生。我还问过

你同样的问题。我说，在你把钱烧光之前，真的会有人做这个吗？

我觉得我在那之前很有可能真的会把钱花光，因为我认为你当时是对的。就是说，我觉得这里面确实有运气成分。但后来我认为市场确实发生了。于是我们突然有了 reasoning models（推理模型），它们可以处理 long horizon tasks（长周期任务）。我们有了 Cloud Code，它成了第一个被广泛使用的 autonomous agent（自主智能体）；然后我们又有了 Cowork 和 OpenCLO。我觉得我们现在开始看到，这类高度 autonomous 的 agents，尽管之前所有人都害怕去构建它们，大家还是都转而去做那些 low code（低代码）平台，那些平台受限得多，更依赖 connectors（连接器）；结果这些平台最终都相当受限，所以我们并没有从这些受限的平台中获得多少生产力提升。

但当我们开始从这些几乎“放开手脚”的 agents 身上获得惊人的收益时——它们几乎什么都能做，内置在其中的 controls（控制机制）也少得多——甚至非常大型的 enterprise 都决定采用它。你知道的，比如 Anthropix 的 revenue（营收）就来自这些 enterprise：它们付费让 cloud code 去完成许多原本由开发者来做的工作。这大概就是我们起步的方式，而我们也确实很幸运：高度 autonomous 的 agents 在一切还没来不及之前就出现了。

所以你能不能稍微描述一下——因为我觉得在当前这个 AI 阶段，这件事既几乎不可能说清，又非常有用——所谓 deployment（部署）现在到底意味着什么，以及 capability（能力）正在发生什么变化？如果用一句话概括，Onyxx 这个产品今天到底是做什么的？然后，再说说你如何看待它的长期愿景？

如今，Onyxx 实际上主要做两件事。第一，我们训练模型并构建能够监督其他 agent 的 agent。其目标是：我们需要有人——或者说某种机制——能够判断，现在这些被我们采用的 AI 所执行的所有动作是否合规，因为这类动作的数量正在指数级增长。因此，过去我们以为可能有用的做法，比如 human in the loop（人类参与闭环），在未来这些动作变成 100 倍、1000 倍、100 万倍之后，就不再可行了。接着，我们把这种能力产品化，做成一个我们称为 AI control plane，或者 secure AI control plane 的产品。我们会对 Enterprise 说，来吧，让我们找出你们所有的 AI 和 autonomous agents，把它们接入 Onyx，接入这个系统，这样我们就能监督你们的 AI 在做什么，避免你们在用 AI 指数级扩大工作量时，开始出现一些非常糟糕的行为。

而且我们最近已经看到一些这样的情况发生了：比如 agent 各行其是导致的 downtime（停机），agent 意外发布了本不该发布的代码和 token，等等。所以很明显，enterprise 现在开始意识到，这种风险也在指数级增长，而他们又没有办法阻止 AI 的采用。因此，他们现在只能采取措施，尽量降低这些 agent 行为不合规或不正确的概率。

是的。我认为其中一个核心原因，显然是 foundation model labs 正在攻代码这个方向，因为代码总体上非常强大，而且理论上，随着时间推移，它可以完成 software 能做的所有事情。问题的另一面在于，它也确实可以完成 software 能做的所有事情，对吧？所以我自己其实已经属于那种——曾经给我的 agent 放权过多，结果它永久删除了数据，还造成了返工——的阵营了。

所以我就想，

哦，明白了。

我觉得我需要在它周围放一些“guardian spirits（守护机制）”。结合你们现在的部署情况，以及你们和大型 enterprise 的交流，目前的部署状态到底是什么样？比如说，你们看到的更多是在这些范围更受限、类似 studio 的平台里，还是那种更自由发挥的 coding agents？在大型 enterprise 以及不同垂直行业里，你们实际看到的比例分别有多少？

是的。所以我觉得，目前在我们接触的典型 enterprise 里，我们会把它分成三类。第一类是各种 SaaS 平台，通常更偏 low code，人们用拖拽式的方法在上面构建 agent，但它们其实不算真正的 autonomous agents。我更愿意把它们看成 AI automations。第二类是 first party agents。

也就是人们在自己的 cloud 里构建的 agent，可能因为这是他们希望在公司内部使用的应用，或者甚至是他们计划发布给客户、并且带有 agentic 特性的产品。第三类则是高度 autonomous 的 coding agents 和 assistants。在这些类别中，我会说，现阶段平均来看，超过 50% 是 autonomous coding agents 和 assistants；大概 45% 是那些 low code automations；最后大约 2% 才是真正由他们自己构建的 first party agent，因为显然，构建有效的 agent 要困难得多，而直接采用现成的 agent 或者用 low code 去搭建则容易得多。我们现在看到的情况就是这样。

我们确实认为，automations 也是增长最快的类别。过去，只有 developers 会看到 cloud code 在我们的客户群中像野火一样增长，而现在我们看到一种 cloud co worker 增长得更快。实际上，连我们自己都有些惊讶：因为 CEO 非常积极地推动采用 AI，人们开始把 OpenCloud 当作公司里一种正式获批的工具来采用。所以我认为，今天 autonomous Azure 绝对是增长最快的类别，而且目前通常是在几乎没有任何控制措施的情况下被引入的。

比如说，企业今天已经购买了 100,000,000,000 规模的安全产品。他们在 endpoint、network、cloud 和 identity 等不同领域都有很多不同的防护措施。这里真正相关的问题是：这些现有东西对保护 agents（智能体）有帮助吗，还是说基本都没用？你会如何看待这套现有的防护体系？

安全领域里，不同工具之间总是会有一些重叠。在这个场景下也是如此，而且你还会面对 defensive debt（防御债务）这个概念。所以，你会希望在技术栈的不同层级都部署防御措施来解决问题。话虽如此，我认为在这个领域里，很多企业其实有点束手无策。我举个例子，比如 identity 这条思路。传统上，如果公司里运行着一个软件系统，我们第一也是最重要的控制手段，就是限制它拥有哪些权限。

这样一来，无论发生什么情况，即使它出错了，即使它被攻破了，通常它也做不了那些原本没有被允许做的事。但对于这些 autonomous AIs（自主 AI）、这些 assistants（助手）、这些 coding agents（编码智能体），我们某种程度上又希望它们拥有我们的权限，因为我们想告诉 Cloud Code 去做某件事，或者让 Cloud Code work 去做某件事，然后我们就可以去吃午饭，回来时希望它已经完成了。而且我们还希望它承担很多种不同的任务，以至于我们几乎找不到一组合适的权限来覆盖这些需求。于是，我们原有的 identity security software（身份安全软件）突然就不那么有用了。再比如 endpoint security 或 API security，如果我们告诉 Cloud Code，我们想重建一个数据库，它应该先删除再重建，那当然很好。

这会为我们的 DevOps 团队和 platform 团队节省大量时间。这正是 Cloud Code 的一个很大价值。但如果 Cloud Code 明明在处理一个无关任务，却突然觉得“也许正确的做法是删除我们的数据库并重新创建它”，那这种事我们可能并不希望发生。遗憾的是，我们的 endpoint providers 或 API security tools 并不知道 cloud 当时在想什么，也不知道它为什么要这么做，对吧？

所以，很多现有工具都缺乏足够的上下文，无法理解这些高度灵活、不可预测的系统到底在做什么。如果你不构建某种专门面向这类系统设计的控制机制，那你最后要么会把它们限制得很死，让它们对企业几乎失去大部分价值；要么就会漏掉很多它们可能正在做的、相当危险的事情。

作为一个在安全领域工作了很久的人，我面对这类问题时，第一反应是非常传统的：这听起来像是一个应该交给 proxy（代理）加上 policy engine（策略引擎）去解决的问题。我们制定一些规则，再把规则做得更智能一些。为什么这条路行不通，还是说你们已经试过了？

这里面有几件事，我会说首先是 proxy 的 integration method（集成方式）问题。的确，有些 AI 系统里，如果通过 proxy 集成是最简单的方法，那你会想这么做。但第一，有很多系统在技术上根本不可行，因为今天的 AI 既可能运行在 cloud 上、运行在别人的基础设施上，也可能运行在你的 endpoint 上，所以 proxy 并不总是一个可选项。第二个问题是：好，就算你做了 proxying（代理转发），你因此看到了数据。你是看到了，但这并不是最难的问题。

真正难的问题，是理解我现在应该做什么。结果发现，在 AI system（人工智能系统）的场景里，这恰恰就是最难的问题。比如说，到底需要一个怎样的 engine（引擎）来为这些不同的行动提供底层支撑，并判断它们是否可以接受？因为我们需要能够理解另一个 AI system 在想什么、它打算做什么，然后再对此形成我们自己的判断。再想想看，我们现在试图理解的，还是世界上一些最聪明的 model（模型）是否在做正确的事。

所以，我们凭什么来做这件事？我们又要怎样才能把它做对？对吧？而这最终就变成了一个非常困难的技术问题。

对 Onyx 来说，解决方案的一部分是训练自己的 model（模型）。这一点你可以谈谈吗？

如果放在今天来尝试，比方说我们想构建一个 solution（解决方案），去监督并某种程度上控制其他 agent 的运行方式。也许很多听众首先会想到的是：那我直接让 Cloud Code 来做不就行了。某种意义上，他们也没错，因为 Cloud Code 很强。也许我们可以让它为我们拥有的每个 agent 都 spawn（生成）一个自己的版本，然后持续监控那个 agent 开始做的每一件事。一旦你觉得有问题，就进行干预。

这种方法显然相当 naive（朴素），而且它在某些方面会彻底失效，这些我们可以展开讲，但它也确实有一定道理。直觉上看，让有能力的 agent 去审查其他 agent 在做什么，确实是个好主意，就像我们会让有能力的人去审查其他人在做什么一样。但接下来你会遇到的问题是：从 cost（成本）、latency（延迟）、reliability（可靠性）这些角度看，我要怎样才能让它真正可行？因为如果作为你的 security vendor（安全供应商），我需要为你运行的每一个 agent 再运行一个 agent，那你付给我的钱可能会比你为自己的 AI 付的钱还多，对吧？所以这基本上就是个 dealbreaker（无法接受的问题）。

而且它还会非常慢，所以你肯定不会满意最终得到的 latency（延迟）。于是挑战就变成了：我怎么知道，在哪些时刻我需要插入这些聪明的 agent，去查看正在发生什么？这时候你真正想做的，其实是训练一些非常聪明的 model（模型）——不过让我纠正一下，不是非常聪明的模型，而是只擅长一件事的模型。它们非常小，几乎什么别的事都做不了，唯一擅长的就是判断：这件事是否应该交给一个更聪明的 agent 来看一眼？

如果你能把这种直觉很好地 bake in（固化）到那些小模型里，也就是说，它们不会漏掉太多东西，也不会过于频繁地去调用另一个 agent，那你就能实现一个非常好的平衡：我们的 performance（性能）很高，需要时有聪明的 agent 负责监督，同时成本低、延迟也低。接着这又带来了新的挑战，因为随着 frontier models（前沿模型）越来越聪明，问题的难度也会不断演化，你就必须拥有站在你这边的模型——它们小而高效，并且能够持续判断：现在就是该介入的时候了，这个 action（动作）是我认为应该让人更仔细看一看的。也正因为如此，我们才想为这个目的去打磨模型，而这也是我们在这个领域所做的大多数困难工作的核心。

对。你我其实都很喜欢下 blitz chess（快棋），而我看 Guardian 这个系统时，会觉得它有点类似这种情况。比如说，在一盘真正的对局里，我们俩谁都未必能和 Magnus 竞争，这一点并不明确。但如果你在拥有合适数据的前提下进行足够多次训练，而且你要做的只是要在时间压力下非常、非常快地做出直觉判断，那它其实就变成了另一种游戏。对吧？

你觉得这说得通吗，还是我这是在过度联想？

对。其实我之前没这么想过，不过，确实有很多类比，因为如果你看世界顶尖的 chess（国际象棋）选手，比如说，他们下的大多数步其实都是直觉性的。他们不会一路往前计算。他们看过太多对局，也下过太多对局，所以他们已经对什么是正确的一步有很强的感觉，也知道在不做计算的情况下走这一步并没有承担太大风险。然后如果你去看那些对局，时不时他们也会突然停下来很长一段时间，去大量向前计算各种选择，因为他们知道这是棋局中的关键一步。

这里是有风险的。你需要把自己在做什么想清楚，而且你需要做出正确决策。我觉得这非常相似。这其实是运行 computation（计算）的一种高效方式，对吧？你不想在不必要的地方投入过多 intelligence（智能/算力），而你会希望在高风险情境下投入大量的 intelligence，压倒性地大量投入。

你们团队现在主要是在 Israel。我觉得全世界都已经接受这样一个事实：Israel 有一批非常出色的 security（安全）人才，来自军方、offensive security（攻防安全），以及像你们这样的连续创业者。我觉得 Onyx 的 DNA 在这方面又有点不一样。你的联合创始人 Gil 是做 synthetic data（合成数据）出身，也在 NVIDIA 工作过。那么，你会怎么概括 Onyx 特别擅长的人才类型？

还有，现在真的有人在 Israel 训练有意思的 frontier models（前沿模型）吗？

所以，我觉得 Israel 可能起步稍微晚了一点，但它追赶得很快。所以我认为，现在 Israel 已经有一些很棒的公司在构建 world models（世界模型）、构建顶级的 AI infrastructure（AI 基础设施）、以及造芯片。所以我觉得，总体上 Israel 正在变得非常强于 AI，而我们也很自豪能成为这股浪潮的一部分。而且我觉得你说得对，我们公司的 DNA 确实是 cyber（网络安全）和 AI 的混合体，这某种程度上也反映了我和 Gil 的背景。我们公司里的大多数人，尤其是大多数 research engineering（研究工程）人员，都来自 Israel intelligence（以色列情报部门）的一个单位，在那里我们实际处理的是数学、cyber，以及两者的交叉领域。

所以，我觉得这也反映在我们吸纳的人才类型上。我认为这之所以重要，有几个原因。首先也是最重要的一点是，从长期来看，我们想做的不只是一个 security company（安全公司）。我们认为，要把这个问题真正解决好，将需要非常深厚的 AI 专业能力，但这个问题又不只是 cybersecurity（网络安全）问题。真正的问题是：从长期来看，我们该如何控制 advanced AI（高级 AI）？

而这个问题，即便你先不去考虑 enterprise security（企业安全），也不去考虑他们当前各种控制手段中的不同缺口，从第一性原理来看，这本身就是一个对我而言非常重要的问题。所以，我认为它会变得至关重要。如果未来出现的是市值 $10,000,000,000,000 的 AI 公司，我们认为你会希望有一家公司——不是 AI 本身的 vendor（供应商）——来监督并帮助你控制 AI 在做什么。我们认为，这会是一个价值超过 $100,000,000,000 的机会窗口，足以诞生一家非常重要的公司。然后，如果你去想，从长期来看，要控制 advanced AI 需要什么，那么我们现在其实才刚刚触及表面，因为从长期看，你还必须更好地理解 models（模型）在“思考”什么，这些模型在运行时其内部到底发生了什么。

这也是我们研究重点所在的很大一部分。

所以，行业内部在这个问题上的分歧相当大。我的意思是，在那些思考“mechanistic interpretability（机制可解释性）”是否可行、或者研究是否有可能更好地理解模型的人当中，这本身就是一个问题。所以，这是你所相信的一件事。

我们相信，朝这个方向已经取得了很多强有力的进展。我们相信，理解内部的 weights（权重）和 activations（激活），理解这些系统的内部结构、数学结构，至少会是解决方案的一部分。而且在很多方面，我们认为——当然这也许只有到那时才能真正知道——以我们这个 intelligence（智能）水平来说，要非常快速地理解 large language model 的内部结构，其实是相当困难的。它的内部结构到底是什么——

——这个 level（层级），比如说，人类智能，还是你们模型的……可以吗？好，人类智能。

哦，是的。对。我觉得，没错，确实如此。我认为，作为人类，我们可能仍然很难理解这些 weights 和 activations 到底意味着什么，而 mechanistic interpretability 也许看起来会像是——哦，也许那太难了，或者根本不应该是可能的。

但随着我们开始拥有在某些重要方面比我们聪明得多的模型，我们认为，我们将能够更有效地开始追踪 mechanistic capability（机制层面的能力）。而且我认为，顺便说一句，从长期来看，这对于理解 intelligence 本身也会极其有价值——不只是为了监督，而是为了理解 intelligence 到底是什么、它如何运作。更聪明的模型和没那么聪明的模型之间，差别到底在哪里？

我完全同意，去理解、信任、保护并治理这些 super intelligent AIs，确实是一个非常巨大的机会。如果我们先回到今天，作为一个做 security（安全）的人，我会说，那我就必须把我给这些公司的所有权限和信任，也都给你们。比如，你们现在要怎么让客户信任你们——或者说，像你们已经在合作的 Fortune 100 公司，或者 tech natives（原生技术公司），每个人都关心自己的安全和业务——他们为什么现在就要信任你们？你们还不到 100 个人，对吧？

对。我觉得这就是那种按理说不应该可能的事。所以，从理论上讲，一个 Fortune 10 或 20 的公司没有理由会跟我们合作，因为我们是谁呢？我们只是一家成立两年的公司。我们不过是几个做过 math 和 cyber 的人。

但我认为，这种机会窗口只会在他们的痛点非常强烈时出现。也就是说，他们的痛苦强到会说，天哪，我刚看到这家公司刚刚结束 stealth（隐身开发期）公开亮相，但它解决的正是我每天都会遇到的问题。所以，我要给他们打个电话。于是你就会突然收到这些大客户的 inbound（主动上门咨询），而这当然是作为创业者所能期待的最好情况。我认为，这反映了他们的判断：这个领域里的很多 startup（初创公司）仍然规模小、资历浅，但这里面一定会诞生一家巨头，而他们想找到那匹值得下注的“赛马”。

所以，我们会去看看这些公司。第二点是，如果我们什么都不做，那么很短时间内，这件事就会让我们的业务失去运转能力。归根结底，security（安全）团队做的是 revenue preservation（收入保全）这门生意。他们明白这是在两种风险之间做权衡。比起什么都不做，他们更愿意尽早与一家有前景、还处于早期阶段的公司合作。

除了 agent（智能体）会在他们的整个 surface area（攻击面/资产暴露面）上执行动作之外，我认识的每一位 CSO 以及每一位 engineering leader（工程负责人）都在为另一件事抓狂：我会把它描述为，借助这些 coding tools（编码工具），漏洞发现的成本正在断崖式下跌。

是的。Mythos。

而这已经给那些被攻破的 vendors（供应商）带来了不少问题。你觉得，人们应该如何应对这个另一个问题？

我认为，mythos 真的是这样一种变化：如果你把我放回十年前，automated vulnerability research（自动化漏洞研究）看起来像是一个要在二十年、五十年后才会实现的梦想。也许是因为我们当时在 Israeli intelligence（以色列情报机构）里做了很多这类工作，而且我们也喜欢拍拍自己的肩膀，强调我们所做工作的难度有多高。但它当时看起来确实非常遥远，而现在却突然一下子全都来了。所以我认为，首先，市场并没有反应过度。我觉得，这对 security teams（安全团队）意味着一种巨大的变化。

如果你今天是一个务实的 security（安全）从业者，你会明白自己必须行动得非常快。你的策略可能大致会是这样：我需要先做我能做的最快速的 quick fixes（快速修补），来缓解眼前的风险。所以，也许我会针对那些已经被发现的漏洞进行投入，尽量去缓解它们，不管是通过 patching（打补丁）还是通过 mitigating controls（缓解性控制措施）。但真正的解决方案——每一家大型企业的每位 security leader（安全负责人）都知道这一点——是我们必须把基础性的能力建设好，才能避免这些风险。而这些基础能力之一，就是我们必须把 identity（身份体系）锁死。

我们需要 firewall（防火墙）。我们需要 endpoint detection（终端检测）。而且，对于企业内部不同的 asset classes（资产类别）、你技术栈中的不同部分，你都需要部署不同的基础性安全机制。对于你现在拥有的 AI attack surface（AI 攻击面），或者对于你公司里的 AIs（AI 系统），你同样也需要一种基础性的安全解决方案。这大致就是我们在这个领域所扮演的角色。

所以，作为你们为 Mythos 级别模型及更强模型做准备的一部分，你们会需要大量基础性的安全工具，来加固企业中不同的环节，而我们在 AI 领域扮演的就是这个角色。

对于在这个领域里，Ant 和 OpenAI 推出的 Glasswing 与 Daybreak 采取分阶段 rollout（部署）或受控 rollout（部署）的做法，你有怎样的看法？

我没有特别强烈的看法，但我觉得这件事有两面性。一方面，如果我们知道近期不会有人发布 Mythos 级别的模型，我认为那会很好，因为这能给我足够时间去准备、去建立 know-how（实践知识）、去制定 playbook（操作预案），并在社区中分享这些经验，同时确保我们不会开始看到航空公司系统瘫痪、电厂停摆，以及那些确实可能发生的灾难性后果。问题在于，如果有人更早做出了 Mythos 级别模型，那么事后看，这就会像是一个巨大的错误，因为我们本来至少可以让企业有选择权，提前非常快速地行动起来，让更多公司获得 Mythos 的使用权限；而现在它们全都变得脆弱了，因为已经有一个达到 Mythos 级别的 Chinese model（中国模型），而且它们对此无能为力。所以，我希望我们能把渐进式 rollout（部署）做好。我会非常鼓励扩大获得这项能力的公司数量，并让人们更容易拿到它。我会建议所有人都假设：这些模型无论如何都会到来。

你现在唯一能做的，就是投资这些基础性控制措施，来阻止那些将在其系统中被发现的漏洞所带来的下游影响。

你在大型企业里还会看到一些 holdouts（持保留态度者）吗？对吧？我得说，其实我最近没有花很多时间和别人讨论这个问题。但我记得在一年半到两年前，确实有一些大公司会直接说：在这东西足够安全之前，我们要把这一切全部禁掉。

是的，我现在几乎已经看不到那种情况了。我觉得在金融行业，有些公司对“允许什么”这件事仍然更有明确立场。它们依然允许 agent（智能体），但可能会更细化一些，比如也许我们只允许这两种工具。就我个人而言，我认为最终会做得好的公司，会是那些允许很多不同工具进入的公司，因为这个格局变化得太快了。如果你一年前押注 OpenAI，那看起来会是世界上最稳妥的下注，但突然之间 Anthropic 已经有了更好的模型和更好的工具，而也许一年之后，又会有别人拿出更好的工具。

所以，我认为这确实是有代价的，但我也认为，如果你是一家大公司，你的 risk profile（风险画像）本来就应该、也确实应该有所不同。你是 startup（初创公司）时，你会希望让自己的 agents（智能体）替你做所有事情，因为你有一切可得，而几乎没什么可失去的。可当你是一家大公司——比如说，我们谈的是 JPMorgan——你有太多东西可能失去，因此你也许可以花更多一点时间，去获取 AI 能带来的那些收益。顺便说一句，JPMorgan 在采用这类东西方面其实已经算是非常快的了。

我认为，公司规模越大，它们在如何采用 AI 这件事上持有一种更细致、更有分寸的看法，是完全可以接受的。

你会怎么为自己思考这个问题？风险画像、节奏、环境变化得非常快；然后，你也会看到很多问题在扩大产品范围，而这里的研究 thesis（研究主张）本身已经相当庞大了。

在 AI security（AI 安全）这个领域，我们某种程度上算是运气不错，因为，没错，市场上有很多 vendors（供应商），也不断有很多新技术冒出来，但构成 2026 年 AI 运作方式的两个核心支柱，在过去几年里其实并没有改变。所以，我们仍然主要在使用 LLM foundation models（大语言模型基础模型），它们和几年前的形态并没有本质上的不同。我们也仍然基本上以同样的方式构建 agents（智能体）：让一个 LLM 来决定我们要调用哪些工具，并生成这些调用。因此，这确实让像我们这样的公司，今天可以扩展到很多不同的应用场景——只要它们都在使用这两个 primitives（基础构件）——同时还能让我们正在开发的核心技术保持相当精简和聚焦。

当然，始终存在这样一种风险：明天就出现一个全新的 LLM 范式，或者一个全新的 edge（边缘）范式。这也是为什么我们会努力去做——我们对 2027 年的 AI 会是什么样子，有比较明确的看法，但这种看法并不是僵化的。对于 2026 年，我们也许已经有了相当清晰的图景；但对于 2027 年，我们保持非常开放的心态。我们认为，在接下来两年里，在我们看清 AGI、ASI 会呈现什么样子之前，这才是正确的姿态。

你觉得你们正在解决的这组问题——对模型的信任，以及对它们的治理——是 labs（实验室）将来自己也可能做的事情，还是说这本身是一个结构性问题？我这么问，是因为今天在 Bay Area 的 startup（初创公司）生态里，大家最常问的问题就是：如果你假设 capability（能力）会继续提升，或者说，当这些 labs 在本来就已经很有野心的立场上变得更加“饥饿”时，他们为什么不会也来做这件事？所以，我也把同样的问题问给你。

如今，如果你是个人用户，或者你是 security buyer（安全采购方），有些场合下你并不希望去信任那个同时把东西卖给你的人。比如说，如果你买一辆车，你通常不会让卖你车的那个人来认证这辆车没问题；你大概会找别人来做这件事。如果你是一个安全团队，你也不会相信某个产品的 vendor（供应商）来告诉你，这个产品不会把你的环境搞乱。你会希望有一个独立的第三方，它的整个业务都建立在两件事上：告诉你这东西是正确的，并且判断正确；告诉你这东西是合法可信的，并且判断正确。

所以，这个领域里有一种 biorep psychology，我认为这对我们非常有利。然后，我觉得还有一些核心问题，比如：模型为什么会犯错？agents（智能体）为什么会犯错？大体上我会把它分成两类。第一类是，这些模型存在 jagged intelligence（参差不齐的智能），因此它们有时会犯一些非常愚蠢的错误。

我认为这个问题会消失。我觉得我们正在走向更聪明的模型，它们会犯更少那种愚蠢的错误，而我们的角色并不是去阻止这种愚蠢错误；这会由模型 vendors（供应商）自己来解决，因为他们有很强的动力去这么做。我认为，另一类正在快速增长、而且我们看到恶意行为会出问题的地方，并不是它们犯了某种“愚蠢错误”，而更像是——我会说——它们形成了一种独立的、甚至可以说是半自觉或半有意识的对于“应该发生什么”的视角，而这种视角未必总是与你的视角一致。我认为，这个问题是随着模型变得更聪明而同步增长的。