Devvret Rishi：AI Agent 最大风险在访问权限

图集导读

1. 封面：本期问题从「模型安全」转到「访问权限安全」。
2. 嘉宾背景：Devvret Rishi 从 Google / Uber AI 基础设施经验走到 Predibase，再进入 Rubrik 负责 AI。3
3. 核心定义：agent 是有访问权限的模型，能调用工具、API、数据库、邮箱和文件系统。2
4. 企业两难：不开放访问权，agent 做不出 ROI；开放访问权，又只能祈祷它不出错。1
5. SAGE：Rubrik 的 Semantic AI Governance Engine 允许企业用自然语言写策略，再用小模型检查每一次输入、输出和工具调用。2
6. 下一层风险：当 agent 开始互相调用，人类不再看得见每条链路，安全层必须看见每个节点和每条边。2

按节目顺序整理

1. 为什么 agent 风险不是「模型会说什么」

2. Predibase 被 Rubrik 收购的逻辑

3. 企业真正卡在两难之间

4. SAGE 的思路：用 AI 管 AI

5. 为什么 orchestration 不够

6. 谁会买这种治理层

7. 本期最值得记住的几句话

• 「agent 就是有访问权限的模型。」2
• 「AI 本身未必取代你，但会用 AI 的人可能会。」2
• 「如果 agent 不能访问任何内部工具，它当然交付不了 ROI。」2
• 「用 AI 治理 AI，是 Rubrik 对这个市场的核心判断。」2

对 AI builder 和投资人的启发

逐句全文翻译

1. Devvret：我们把 agent 定义得很简单，就是有访问权限的模型。它可以访问工具或 API，可以在组织内部开始做事。
2. Craig：一旦这些 agent 变成看不见的层，在人类看不到的地方互相对话、互相传数据，企业就会变得很脆弱，因为你不知道数据正在流向哪里。除了 agent 访问工具和数据库之外，它们也在彼此交谈。你怎么看这个 agent 经济的发展？
3. Devvret：大家经常问 AI agent 会不会造成岗位替代。我听到的说法是，AI 本身未必会，但真正会用 AI 的人可能会。
4. Craig：我们会聊 Rubrik，也会聊 Rubrik Agent Cloud。你能先向听众介绍一下自己吗？讲讲你的背景，尤其是你的教育经历，以及加入 Rubrik 之前在做什么。
5. Craig：也请讲讲你在 Rubrik 之前做过的事情。
6. Devvret：可以。我从头说起。我叫 Devvret。
7. Devvret：我是 Predibase 的联合创始人兼 CEO。Predibase 是一家生成式 AI 基础设施公司，我们在 2021 年、也就是这波生成式 AI 浪潮刚开始前创办它。当时我们主要帮助组织构建并部署大型语言模型之前的那类系统，也就是预训练深度学习模型。这件事来自我和联合创始人在 Uber 与 Google 的经验。
8. Devvret：创业前，我在 Google 工作了大约五年。再往前，我一直在 AI 领域，读硕士时做的是核心计算机科学和统计。我的公司去年夏天被 Rubrik 收购。我们带着核心机器学习和 LLM 基础设施平台加入 Rubrik，也就是驱动财富 500 强和技术前沿企业部署 AI 的模型骨干。加入 Rubrik 后，核心想法是把我们搭建的平台与 Rubrik 擅长的东西结合起来。Rubrik 是一家数据与网络韧性公司，最早的核心业务是确保企业能从宕机和数据风险中恢复，后来又增加了安全能力。收购 Predibase 后，我们正在把 AI 平台、数据安全和身份安全结合成一个新产品，叫 Rubrik Agent Cloud。我们的观察是，AI 来得很快，AI 工具和模型也变好得很快，人们正在大规模采用这些工具。但真正拖慢 ROI 的，是企业缺少一套管理 agent 在组织内部能做什么的风险框架。这就是 Rubrik Agent Cloud 想解决的问题。
9. Devvret：Rubrik 最早的思路是「假设已经被攻破」。很多方案想做的是把门锁好，但真正需要的是当攻击穿过防线、真的成功时，企业业务有没有恢复能力。过去，企业停摆更多来自自然灾害、火灾、水灾；后来越来越多来自勒索软件和网络攻击。Rubrik 的问题是，不管威胁来自旧的自然灾害，还是新的网络攻击，怎样让企业能恢复。后来它再逐步增加预防和检测能力，形成分层防御。
10. Devvret：Rubrik 看到的下一个威胁向量，是 AI，尤其是组织内部部署的 agent。我们把 agent 定义成有访问权限的模型，也就是能够访问工具或 API，并在组织内部开始执行工作的模型。
11. Devvret：这也是 Rubrik 收购 Predibase 的动机。我们一开始做的就是人们构建模型并开始部署 agent 的核心基础设施平台。Rubrik 想说，我们已经帮助你应对自然灾害、火灾、水灾、网络攻击和安全问题，现在也要帮助你应对下一波 agent 风险。
12. Craig：你的背景是什么？你在 Google 做什么？是 agentic AI 还是安全？
13. Devvret：挺有意思。我在 Google 之前，本科和硕士基本同步读，学的是计算机科学和统计，关注隐私保护场景下的稳健机器学习算法。后来我去了 Google，在多个团队工作过，包括 Google Research。我当时参与的东西，如果你记得早期 agent 的样子，它们很像 Google Assistant，嵌在不同设备里。我们做的是 Assistant 里的深度学习用例，这是我十多年前第一次接触 agent。第二块是 Google Cloud 的 AI 平台。那时还没把它命名为 Vertex AI。我们在搭建早期基础，让更多人能在云上运行机器学习和 AI 工作负载。到 2020 年疫情时，我遇到了后来几位联合创始人，他们在 Uber 搭了内部机器学习框架，让应用开发更容易。这些框架开源后在外部也流行起来，于是我们决定一起围绕它创业，这就是 2021 年初的 Predibase。
14. Devvret：为什么叫 Rubrik Agent Cloud？老实说，Rubrik 在 Agent Cloud 之前的主产品叫 Rubrik Security Cloud。Security Cloud 的直觉是，组织从本地系统迁移到云时，需要保护这个转型过程。我们推出 Agent Cloud 时意识到，AI 是一个全新的系统，传统安全原则不再完全适用，所以我们需要一种新方法。Agent Cloud 这个名字是在呼应 Security Cloud。Agent Cloud 的核心是，agent 可以出现在生态里的任何地方：你的笔记本电脑上，本地的 Claude Code 或 OpenAI Codex 里，你管理的云环境里，或其他很多地方。企业需要的是一个统一控制面，能看见这些 agent 在做什么，并对它们有一定控制。
15. Craig：我和很多 agent 编排公司聊过。底层有 LLM 基础模型，有构建和部署 agent 的平台，也有人在做编排层，帮助追踪 agent 正在做什么。你们是编排层，还是在它之上？
16. Devvret：我们在它之上。我认为市场上已经有很多不错的编排工具，也有很多不错的 agent 构建平台。每个 hyperscaler 都有自己的 agent 平台和编排方案，Google 有 Vertex AI 和 ADK，AWS Bedrock 有 AgentCore，Azure 有一套工具，Salesforce 有 Agentforce，ServiceNow 也是 agent 平台。现在有很多构建 agent 的好办法。真正难的是，不管 agent 在哪里构建，怎样在运行时给它们设置一致的护栏，确保它们知道能做什么、不能做什么。这个问题很棘手，因为 agent 不太像传统软件，更像你我在 IT 组织里能做的事情。
17. Devvret：举个例子，我个人最常用的 agent 是 Claude Code。我的 agent 有 Salesforce 权限，也有邮箱权限，因为我用它写邮件，也用它总结 Salesforce 里的机会。但我不希望它把 Salesforce 里的敏感信息拿出来，自动发到邮件里。这是 Claude Code 或类似工具需要保护的一类场景。如果你用的是别的 agent harness，比如 OpenAI Codex，同样会有这个问题。
18. Devvret：所以市场上有很多系统，擅长集成不同环境，有好的 harness、好的编排框架，也有云上运行方案。Anthropic 刚发布了管理 agent 的方案。但问题是，怎样用一种一致的方式监控、观察，并在运行时给这些 agent 的动作加护栏。我们就在这里。底层是模型和 MCP 工具或其他 API 工具；再上一层是 agent 平台和编排器；我们把 Agent Cloud 看成覆盖这些层的安全伞。
19. Devvret：这在企业同时使用多个 agent 平台时最有价值。事实上，大多数企业都会这样。就像云时代企业会采用多云，AI 时代会更明显，因为这些工具出现得太快。Rubrik 内部自己也有多个 agent 平台，包括不同 coding agent，也有基于 Vertex AI 构建的 agent，还有一些第三方工具。问题是如何统一保护它们。Agent Cloud 可以插进去，自动发现和扫描 inventory，然后建立控制系统。
20. Craig：关于 agentic 系统的安全风险，外界已经说了很多。像 Rubrik Agent Cloud 这样的产品，是不是有点像保险带和背带，也就是多一层保险？还是说已经有真实的 agent 失控案例？
21. Craig：你们现在有一个活动或项目，我之前没看过。
22. Craig：我们刚才还聊过，这些风险到底有多真实。我在主力电脑上用 OpenAI Codex，有人会说你疯了，但我也想知道到底风险是什么。
23. Devvret：九个月前我们开始讨论这件事时，可能只有一两个值得拿出来说明风险的案例。现在我觉得企业真的卡在两难之间。一种做法是觉得太危险，于是彻底禁止访问。那就会出现另一个问题：为什么 AI 没有带来 ROI？答案是，因为你说有 agent，却不让它访问任何内部工具，它当然交付不了 ROI。第二种做法是咬紧牙关说，放开吧，希望不要出问题。作为这些工具的用户，我也会看到 agent 不断请求权限。它每 20 秒、30 秒就问我一次。我很坦白地说，到某个点我就会一直点接受。
24. Devvret：并不是每个请求都危险，但它可能在请求某些文件夹的 root 权限。我遇到过一个例子，我让 agent 创建一个文档。
25. Devvret：agent 发现我的 Google Drive 连接器被禁用了，所以它本不该通过 Google Drive。它做了什么？它打开浏览器窗口，输入 drive.google.com，点击上传，然后打开我的文件导航。那很吓人。那次没有造成坏结果，因为本地没有相关凭证。但过去九个月里，我们看到一个又一个出问题的事件。小例子包括 coding agent 删除生产数据库。现在公开帖子里至少有两个案例，agent 因为用户不停点 yes 或类似原因拿到了生产数据库权限，然后数据库就被删了。对任何组织来说这都是噩梦。AWS 也发过帖子，说 coding agent 推出后，大约 90 天内出现了四次 Sev1 级别事故，可能还更短。AWS 是大家购买稳定性、云韧性和 SLA 的代表，这很惊人。它有流程，但 agent 执行得太快。
26. Devvret：Meta 也有自己的事件。我记得是某个 OpenAI Codex 实例拿到了某人的邮箱权限，然后大量删除邮件。
27. Craig：是的。
28. Devvret：我们也分享过一篇博客，讲 Rubrik 内部有限发布 Claude Code 时看到的情况。即使在我们自己的组织里，也看到了三类我们知道不该发生的事情。我们能抓到，是因为 Agent Cloud 已经接入。Agent Cloud 用 AI 来保护和治理这些行为。比如有人连接 GitHub 写 gist，结果 gist 被意外分享到公共域，而不是私有 GitHub。
29. Craig：听起来像 Anthropic 那类案例。
30. Devvret：不完全是。过去一两周市场上也有不少泄露可以讨论。我的观点是，九个月前这件事可能还像多加一层保险。但现在，企业面对的是两种选择：要么完全阻止访问，然后董事会或 CEO 会问，为什么 AI 没有 ROI；要么开放访问，然后如果没有一个真正监控所有 agent 行为并执行策略的方案，就只能部署它，再咬牙希望不要出事。这些 agent 对它们能访问的东西非常不挑。
31. Craig：我读过一些案例，但没看到很好的复盘。比如那个邮箱删除案例，对方疯狂输入 stop deleting my inbox，agent 还是继续删。我觉得常见问题很简单：agent 90% 的时间都在做正确的事，然后突然做了一个错误动作，而错误动作发生得很快。它一小时能做完人一周做的事，这很好；但当它做错时，原本也许要一周才会造成的后果，也可能很快发生。Rubrik Agent Cloud 怎么部署？如果企业有 Claude Code、OpenAI Codex、Copilot，还有 Azure 订阅里的 agent，怎么处理？
32. Craig：也许有人还在用 OpenAI Codex 或类似工具。
33. Devvret：我通常看到三类 agent。第一类是在客户端或桌面上运行的 agent，比如 Claude Code、OpenAI Codex、Claude Code Work，它们是本地的。第二类是在云里构建的 agent，比如 Microsoft Copilot Studio 或 hyperscaler 的托管服务。第三类是真正自建的 agent，企业拿 OpenAI API key 或 Anthropic API key，通过某个编排框架接起来。Rubrik Agent Cloud 对这些生态都有 hook：直接 API 集成、移动设备管理系统集成，也有 AI gateway。它能接入这些系统，拿到日志、监控和可观测性，再下发控制。我们的产品可以作为 Rubrik 管理的 SaaS 部署，也可以部署在客户自己的 VPC 里。
34. Craig：你说 hook，是指有人启用一个 API 吗？
35. Devvret：是的。
36. Craig：明白。
37. Devvret：我们有多种接入方式。最简单的情况是，如果你在 Copilot 或 Copilot Studio 里构建 agent，可以提供 Azure API 凭证，Agent Cloud 会自动接入后端合适的东西。如果你在端点上运行 agent，我们可以与已有的移动设备管理工具，也就是 MDM 集成。如果你使用自己的 API，也可以使用 Rubrik Agent Cloud 提供的 API。所以路径比较灵活，可以 API 集成、给你可用的 API，或与 MDM 集成。我还想谈谈 OpenAI Codex。你对它的工作方式和安全漏洞了解多少？
38. Craig：部分原因是我自己也在用。
39. Devvret：我可能算是懂到足够危险的程度。OpenAI Codex 和传统桌面 agent 有很多相同的安全问题，而且因为它不一定被中心化管理或联合身份管理，担忧会更强。像 Claude Code 这种由中心方分发的工具，可能内置一些护栏。很多组织会采取几种姿态：一种是直接禁止 OpenAI Codex。那你马上会遇到一个问题：我怎么知道组织里有没有人在运行它？这就是我们开箱要解决的问题之一，监控和检测。另一个问题是它能做什么，我们也会帮忙。
40. Craig：产品长什么样？是一个人类监控的仪表盘，还是全自动的 agentic 系统，出问题时只给你告警？
41. Devvret：有仪表盘，人可以访问和监控。产品大概有三条主要旅程。第一条是仪表盘显示 inventory：哪些 agent 在运行，每个 agent 可以调用哪些工具，这些 agent 关联了哪些身份，调用哪些模型。这些都集中在一个地方，而且会自动发现和扫描，不需要你手工注册。第二条是更强大的部分，我们叫 SAGE，也就是 Semantic AI Governance Engine。它来自一个观察：客户通常有一些希望 agent 一致遵守的策略。比如昨天我和一个医疗客户聊，他们说 agent 不应给出临床诊断。但你很难写一个静态规则，用字符串匹配判断 agent 说的是不是临床诊断。我们的想法是，不可能让人类判断每个 agent 输出，那太慢了。应该用可以微调和部署的小语言模型，在每一次 agent 输入和输出上运行，判断它是否违反你定义的策略。你可以在平台里用自然语言输入，比如「agent 不应给出临床诊断」。系统会扩展这条规则，补充例子，展示哪些会被拦、哪些是边界案例，然后把它部署为自动运行的护栏，出问题时触发告警。第三条是，你可以深入某个 agent，看到它的动作地图：它做了什么，什么时候做的。如果需要，还可以用 Rubrik 备份把某个动作回滚到之前的快照。
42. Craig：你们之前有一个广告，Ludacris 播 rewind 或 wind it back。
43. Devvret：对。你问怎么回滚一个动作。这件事很复杂，但核心是 Rubrik 已经保护了很多大客户的数据，所以我们会维护底层数据源的迭代快照，比如 Azure SQL 数据库或 Salesforce 实例。如果 agent 对 Salesforce 或 Azure SQL 做了破坏性动作，我们首先通过可观测性知道它做了这件事。用户如果判断这是错误动作，想回滚到上一个快照，我们就可以用 Rubrik 的备份能力恢复。
44. Craig：这是 SaaS 产品。它怎么定价？按席位，还是企业订阅？
45. Devvret：我们会根据公司和用例做 right sizing。产品很新，今年早些时候刚 GA，所以我们还在和早期客户一起迭代更合适的定价方式。现在会有一个 license fee，包含一定层级的使用量。
46. Craig：个人使用 agent 也在爆发。企业很重要，但个人使用最终也可能成为同样大的市场。你们有面向消费者或个人用户、小公司的订阅吗？
47. Devvret：这是个好问题。我们今天没有面向个人或消费者的订阅。如果你是中小企业，也欢迎联系，我们有一些 starter plans。但我们最关注的机会，是企业要么没有采用 AI，要么因为缺少企业级方案而采用得很担心。我们现在最关注 Global 2000 企业、早期大规模 AI 采用者。个人用户也会出现在这些市场里，比如 Claude Code Work 可能用企业订阅处理业务和一些个人任务。凡是在业务上下文里运行、使用业务订阅、访问 IT 基础设施的东西，都是我们想保护的。
48. Craig：外界一直在谈 agentic enterprise。
49. Devvret：是的。
50. Craig：还有 agentic native startup，它们正在挑战传统企业。
51. Craig：我猜这些公司也会需要它。尤其是如果它们从一开始就围绕 agent 建业务。除了 agent 访问工具和数据库之外，agent 还会互相对话。
52. Craig：当这层结构扩张时，人类不会知道 agent 之间发生了什么。
53. Craig：这是你们在看的方向吗？
54. Craig：你怎么看这个 agent 经济的发展？
55. Devvret：你的问题有两部分。一部分是 agentic native 组织，另一部分是 agent-to-agent 通信。第一部分，我会说，任何觉得自己有东西可失去、又想加速 AI 价值的人都会需要这类保护。即便是较小的组织，只要有需要保护的 IP、敏感数据库，都会相关。组织越大、越受监管、越接近上市公司，这个需求越明显。关键是，如果你要把 agent 放到那些敏感而有价值的系统里，确实有充分理由，因为那是 agent 最终产生生产力和 ROI 的方式。第二部分是 agent fabric 怎么演化。我们在 Rubrik 内部已经看到，很多 agent 会去调用另一个 agent。比如一线 triage agent 接入支持请求，再由下一层 agent 做解决或调查。我认为保护单个 agent 和保护多 agent 工作流的基本原则一样：你要能检查每个 agent 的输入，也要能检查它输出给另一个 agent 的内容。这样才能确保图里的每个节点、连接节点的每条边都安全。
56. Devvret：典型错误场景是，agent A 没有敏感数据权限，agent B 有敏感数据权限。你要确保 A 不能通过 B 间接拿到并返回敏感数据。只要你在 A 被调用时、A 收到输出时都运行护栏，并在它调用 B 的路径上拦截，就能识别敏感内容。
57. Craig：这个场景我和别人讨论过好几年，从 agentic movement 开始就这样。一旦这些 agent 变成看不见的层，在人类看不到的地方互相对话、互相传数据，企业就很脆弱，因为不知道数据正在流向哪里。
58. Craig：这就是控制权丢失。
59. Devvret：对，完全是。
60. Craig：编排层本来应该处理这个。
61. Devvret：编排层负责确保调用链按正确顺序发生。它很擅长说，agent A 需要某个信息来完成请求，所以去找 agent B。但它往往缺少组织层面的策略判断：这个请求应不应该被满足？拿来满足这个请求的上下文，对 agent A 来说是否合适？这就是上面那一层要做的事。
62. Craig：组织里的最终用户是谁？是 IT 部门在应用它？是 C-suite？还是有 agentic 平台访问权的个人用户？
63. Devvret：AI 在企业里移动太快，所以有几个团队都会感兴趣，但最突出的有两个。第一是 IT 里的 AI 平台团队，可能叫 AI enterprise architects 或类似名称，他们思考的是如何给员工启用的平台建立信任和治理。第二是安全团队。安全里也有不同利益相关方，比如 SOC ops，过去关心员工是否意外外泄敏感数据，现在这个担忧被 agentic future 放大。GRC 也会有大量监督需求，CTO 或 VP Engineering 组织也会需要 guardrails。但我们最常看到的，是企业 IT、AI architects，以及安全和安全架构团队。
64. Craig：明白。
65. Craig：这些安全层最终会不会和编排层合并？会不会被折进编排里？可能是 Rubrik 构建在某个编排层上，也可能有人收购 Rubrik。我想象这些东西最后会收敛成一个东西。
66. Devvret：我的观点可能不太一样。我认为会有很多优秀方案帮助人们构建和部署 agent。我们 CEO 的说法是，你会需要一个像瑞士一样中立的玩家，来保护和治理不同地方构建的 agent。你大概不会希望模型公司同时负责监管它自己放出去的模型。它可能做得不错，但企业和 IT 语境需要一套在其之上的控制系统。所以 Rubrik Agent Cloud 会尽量保持对编排和平台中立。我不想对你用哪个模型、哪个平台持强观点；我们只是提供一致的治理和安全体验。
67. Craig：竞争格局怎样？已经有很多安全公司在往这个方向走。agent 显然是未来。你们怎么保持竞争力？
68. Devvret：Rubrik 做了一件很独特的事。它本来是数据安全公司，安全是 DNA，又收购了 Predibase 这样的模型基础设施公司。很多安全公司会用传统安全方式处理这个挑战，而我们决定用 AI 来保护和治理 AI。SAGE 和建立在 Predibase 平台上的小语言模型，是我们相对其他公司的重要差异。选择我们，某种程度上就是接受一个 thesis：我需要用 AI 帮我保护和治理 agent，而且需要小语言模型，否则延迟和成本无法承受。再加上 Rubrik 内部的数据和身份信号，这是我们的核心差异。市场上肯定会有竞争，也会有互补产品，但我们会继续强调两点：一是用 AI 保护和治理 agent，二是 Rubrik 的数据与身份上下文。
69. Craig：你说主要目标是 Global 2000 企业。
70. Craig：过去一年有很多 pilot，生产部署也在加速。
71. Devvret：是的。
72. Craig：但很多公司不想冒险，还在观察市场。你怎么看 Global 2000 里 agent 工作流的渗透？
73. Devvret：我和很多高管聊下来，感受到的是采用 AI 的压力非常大。
74. Devvret：我最近和一位 CISO 聊过，他在一个 panel 上说，感觉所有 CEO 都去参加了同一个为期一周的 retreat，董事会在那里告诉他们必须更快采用 AI。
75. Craig：是的。
76. Devvret：然后他们撞上现实：AI 要做有用的事，就必须有访问权；但他们现有架构不是为 agent 安全访问而建的。我反复听到的就是这个故事。Global 2000 里，我看到很多压力、很多项目和很多 funded pilots。但这些项目在早期就开始疼：大家说先慢一点，开会，写设计文档，走委员会审批。委员会自己其实也还没搞清楚要什么控制。Rubrik 内部也遇到过同样问题。我们意识到，要从人、纸面和流程，转到软件产品和平台方案，所以才做了这个产品。
77. Devvret：我看到很多兴趣和资金支持的试点，但 AI 风险和风险管理方式，仍然是拖慢进度的大问题。
78. Craig：所以你们增长一定很快。
79. Devvret：收购后在 Rubrik 里面看到增长，确实很有意思。
80. Craig：我是说可触达市场。你的市场是正在实施 agent 工作流的人。
81. Craig：这其实才刚开始，还在早期慢阶段。
82. Devvret：对很多组织来说可能还是早期采用者阶段，但它从早期采用走向主流中间层的速度，是我见过所有技术趋势里最快的。推动力来自自上而下，也来自自下而上，压力正在积累。
83. Craig：Rubrik Agent Cloud 下一步是什么？除了扩张客户群，你们往哪里走？
84. Devvret：我们的使命是帮助保护并加速全球 AI 转型。降低风险是其中很大一部分。Agent Cloud 的方法是更重地使用 AI。现在用户可以直接用自然语言定义 guardrails，接下来我们会构建更多 agentic workflows，帮助治理本身减负。今天还很 human-in-the-loop，未来能不能降低这部分负担，是一个自然方向。第二，我们还有很多 agent 出现的表面积要覆盖，包括新的测试和使用场景。我们还有很多工作要做，但最让我有动力的是，市场确实有明确需求。我也能感受到客户的痛点：你让我把 agent 接到客户数据这类系统 of record 上，可如果它不能访问客户，它又怎么做有意义的工作？
85. Craig：你出去和公司聊的时候，会不会像 agent evangelist 一样说，你们害怕在企业部署 agent，是因为安全风险；但只要解决这个问题，就能开始旅程？
86. Devvret：有意思的是，我不把自己看成 agent evangelist。但我确实认为，大家应该以更高频率采用这项技术，因为它有巨大的上行潜力。关于 AI 和 agent 是否会带来岗位替代，我听到的说法是，AI 可能不会，但掌握 AI 的人可能会。我认为组织层面也一样。未来五年，谁最会用 AI，会决定很多事情。
87. Devvret：如果有人不相信 AI 是适合他们的方案，我觉得那也是合理结论。最有共鸣的是，有人知道 AI 是正确方向，但因为卡在两难之间，不知道怎么开始。你问 adoption 是来自我们出去教育市场，还是企业自己已经试点后意识到需要安全方案。两者都有。
88. Devvret：我做 pipeline building 已经五六年了，这个市场感觉不一样。我们尽量不强推产品，而是描述痛点。有时在 webinar 或营销活动里，有时在直接客户对话里。我们会很透明地说，方案可能不适合你现在的位置；如果适合，我们很愿意聊。幸运的是，市场兴趣很强。
89. Devvret：我们不需要太用力 pitch。我们讲的是：这里是痛点，我们知道痛点，因为 Rubrik 自己遇到过；这里是我们的 solution architecture；这里是产品大概长什么样。如果你相信这些 thesis：需要 AI 来保护和治理 agent，数据与身份上下文重要，需要运行时保护，agent 会分布在很多地方，而且这个问题对你现在很及时，那我们就应该继续聊。如果不是，也可以六到九个月后再看。现在 inbound 和 outbound 都很健康，但核心是市场自己已经感到这个问题。
90. Craig：能不能讲讲底层发生了什么？Rubrik Agent Cloud 接进去之后，设置界面是什么样？
91. Craig：它会扫描系统，很多设置是自动的。
92. Craig：这到底怎么发生？有没有对话式界面？
93. Devvret：Rubrik 有一个叫 Ruby 的对话式界面，可以面向 Rubrik 平台交互。至于设置和底层机制，可以分成三步。第一步是连接 runtime，拿到 agent runtime 的暴露能力，包括提示词、响应、工具调用等日志，让它们进入我们的可见范围。我们接入三个主要表面积，让 prompts、responses 和 tool calls 流进系统。然后我们用这些信息填充图谱：这是一个 agent，这是它的 graph。第二步是定义策略。我们有很多一键启用的策略，比如防 prompt injection，或默认让 agent 只读。但也允许你用英文定义自定义策略。你输入一段文本，我们用最佳实践扩展定义，给出参考定义和例子，让你确认。后端会把它蒸馏成小模型，部署在高效基础设施上，并与第一步看到的 prompts 和 responses 放到同一条链路里。第三步是告警和控制。只要 SAGE 发现错误，就弹出告警，说明哪里出错；如果你这样配置，它也可以直接阻断。
94. Craig：所以 Rubrik Agent Cloud 本身也是一个 agentic 系统？
95. Devvret：我会说 Rubrik Agent Cloud 是一个平台，里面有一些 agentic workflows 在运行。
96. Devvret：随着时间推移，里面会有越来越多 agentic workloads。
97. Craig：明白。
98. Craig：最后你想补充什么？
99. Devvret：从我创办 Predibase 到今天，模型聪明了很多，harness 和编排框架也成熟了很多。现在的瓶颈变成：怎样安全管理这些 agent 正在增长的风险。我认为这是最大的开放机会。缺少这层能力，是很多组织仍在问 ROI 的原因。让我最有热情解决的事，就是通过让企业真正信任 agent 正在做的事情，安全地加速全球 AI 转型。
100. Craig：好的。

来源