2026年6月的第1周，一家名为 Reco 的以色列 SaaS 安全公司发布了一份新闻稿，宣称推出”业内首个 AI Agent 安全方案”。在绝大多数安全从业者的信息流中，这条消息的权重大概介于”又一个初创公司的营销噱头”和”值得点开看看”之间。但如果你把这条消息放进一个更大的坐标系——Salesforce Agentforce 在2025年Q4已经部署超过10万个企业 Agent、Microsoft 365 Copilot 的月活用户在2026年Q1突破3000万、Make 和 n8n 这类低代码自动化平台的 Agent 工作流创建量在过去6个月增长了400%以上——你会意识到，Reco 试图解决的问题，不是一个”有没有”的问题，而是一个”已经失控了多久”的问题。

（来源: Reco 官方新闻稿, EIN Presswire, 2026-06）

为什么说这是”Day Zero”？不是因为 Agent 安全问题今天才出现——它至少已经潜伏了18个月。而是因为今天，行业终于有了第一个将”AI Agent 安全”作为独立产品品类推向市场的公司。这意味着从现在开始，企业安全团队不能再假装这个问题不存在，投资人不能再把它归入”未来趋势”，而平台巨头不能再用”我们的内建安全已经够用了”来搪塞客户。时钟开始计时了。

这篇文章要回答3个问题：第1，AI Agent 在 SaaS 环境中的扩散到底有多严重？第2，Reco 的方案是否真正触及了问题的核心？第3，Agent 安全这个赛道的终局形态是什么——它会是一个独立品类，还是会被现有的 CASB/SSPM/CNAPP 巨头吞噬？

一、Agent 扩散：一个被严重低估的攻击面膨胀

1.1 从”影子 IT”到”影子 Agent”

企业安全圈对”影子 IT”（Shadow IT）这个概念已经讨论了超过15年。2012年前后，Gartner 首次警告企业中存在大量未经 IT 部门批准的 SaaS 应用；到2020年，Netskope 的数据显示平均每家大型企业使用的 SaaS 应用数量超过2400个，其中约97%从未经过安全审查。这个问题从未被真正解决，只是被部分管理了——通过 CASB（Cloud Access Security Broker）和 SSPM（SaaS Security Posture Management）工具，企业至少获得了对 SaaS 应用层面的可见性。

但 AI Agent 的扩散正在制造一个量级完全不同的问题。区别在于：一个 SaaS 应用是静态的——它有固定的 API 端点、固定的权限模型、固定的数据流向。一个 AI Agent 是动态的——它可以在运行时决定调用哪些 API、访问哪些数据、执行哪些操作，而且这些决策路径在部署时往往无法完全预见。

具体来说，当一个市场营销团队的实习生在 Make（原 Integromat）上搭建了一个自动化工作流，让 ChatGPT 读取 Salesforce 中的客户数据、生成个性化邮件、通过 Gmail API 发送，并将结果写回 HubSpot——这个工作流在技术上就是一个 AI Agent。它拥有对至少4个 SaaS 系统的读写权限，它的行为由一个外部 LLM 的推理结果驱动，而创建它的人可能从未考虑过数据分类、最小权限原则或合规审计。

这不是假设场景。n8n 在2026年4月的官方博客中披露，其平台上包含 AI 节点的工作流数量在过去12个月增长了超过520%，其中约65%的工作流涉及跨3个以上 SaaS 应用的数据流动。Make 在同期的开发者大会上公布的数据更为惊人：其平台上每天执行的 AI Agent 操作数超过1.2亿次，同比增长超过800%。

（来源: n8n 官方博客, 2026-04; Make Developer Conference Keynote, 2026-05）

1.2 Agent 的权限问题：不是”过度授权”，而是”无法定义授权”

传统的权限管理建立在一个基本假设上：你可以在部署时定义一个实体（用户、服务账户、应用）需要访问什么资源、执行什么操作。RBAC（基于角色的访问控制）和 ABAC（基于属性的访问控制）都依赖这个假设。

AI Agent 打破了这个假设。以 Microsoft 365 Copilot 为例：当一个用户要求 Copilot “帮我准备下周的董事会材料”，Copilot 会在运行时决定搜索哪些 SharePoint 站点、读取哪些 Teams 频道的消息、访问哪些 OneDrive 文件。它的访问范围由用户的权限边界决定——但问题在于，大多数企业中用户的实际权限远远超过其日常工作所需。Microsoft 自己在2025年的 Secure 大会上承认，平均每个 Microsoft 365 用户可以访问的文件数量超过其实际需要访问量的10倍以上。

这意味着 Copilot 的每一次调用，都可能触及用户本人从未主动查看过的敏感数据。而 Copilot 的输出——比如一份自动生成的董事会摘要——可能会将来自不同安全分类级别的信息混合在一起，然后通过邮件发送给一个更大的分发列表。

Salesforce Agentforce 面临类似但更复杂的问题。Agentforce 允许企业构建自定义 Agent，这些 Agent 可以直接操作 Salesforce CRM 中的数据——创建机会、更新客户记录、触发审批流程。Salesforce 在2026年Q1的财报电话会议上披露，Agentforce 已经在超过10万家企业中部署了自定义 Agent，每月执行的自主操作数超过20亿次。CEO Marc Benioff 将其描述为”数字劳动力的崛起”。但从安全角度看，这20亿次自主操作中的每一次，都是一个潜在的未经人工审核的数据访问或业务操作。

（来源: Salesforce FY2027 Q1 Earnings Call, 2026-05; Microsoft Secure 2025 Keynote）

1.3 数字化证据：Agent 扩散的规模

让我们用具体数字来描述这个问题的规模：

  • Microsoft 365 Copilot：2026年Q1月活用户超过3000万，覆盖超过15万家企业。每个用户平均每天触发12-18次 Copilot 操作。（来源: Microsoft FY2026 Q3 Earnings, 2026-04）
  • ChatGPT Enterprise/Team：OpenAI 在2026年5月披露企业版用户数超过200万，其中约45%的用户启用了”Actions”功能（允许 ChatGPT 调用外部 API）。（来源: OpenAI Enterprise Blog, 2026-05）
  • Salesforce Agentforce：如上所述，超过10万家企业，月均20亿次自主操作。
  • Make：每天1.2亿次 AI Agent 操作，平台上活跃的 AI 工作流超过800万个。
  • n8n：开源版本的下载量在2026年上半年突破5000万次，包含 AI 节点的工作流增长520%。
  • Zapier：2026年3月宣布其平台上的 AI Agent 工作流数量突破1500万个，同比增长超过350%。

把这些数字加在一起，你会得到一个令人不安的结论：在一家典型的中大型企业中，AI Agent 的数量可能已经超过了人类员工的数量，而且正在以人类员工增长速度的100倍以上扩张。

二、Reco 的方案：看到了问题，但解决方案可能只是冰山一角

2.1 Reco 做了什么

根据 Reco 的官方发布（来源: Reco 官方新闻稿, EIN Presswire, 2026-06），其 AI Agent Security 方案主要提供以下能力：

  1. Agent 发现与清单：自动识别企业 SaaS 环境中运行的所有 AI Agent，包括 Copilot、ChatGPT、Salesforce Agentforce、Make、n8n 等平台上的自定义自动化工具。
  2. Agent 行为监控：跟踪 Agent 的数据访问模式、API 调用链和跨应用数据流。
  3. 异常检测：基于行为基线识别异常的 Agent 活动——比如一个原本只读取 CRM 数据的 Agent 突然开始访问财务系统。
  4. 策略执行：允许安全团队定义 Agent 行为策略（例如”禁止任何 Agent 将客户 PII 数据发送到非批准的外部 API”），并在违规时自动阻断。

Reco 的定位是 SSPM（SaaS Security Posture Management）的延伸。该公司在2024年获得了由 Insight Partners 领投的3000万美元 B 轮融资，其核心产品一直是 SaaS 安全态势管理——帮助企业发现和管理 SaaS 应用中的配置错误、过度权限和数据暴露。AI Agent Security 是其在这个基础上的自然延伸。

2.2 Reco 的方案为什么重要

Reco 的方案之所以值得关注，不是因为它的技术有多突破性，而是因为它标志着一个新安全品类的正式诞生。在此之前，企业安全团队面对 AI Agent 扩散基本上是”裸奔”状态：

  • CASB 看不到 Agent：传统 CASB（如 Netskope、Zscaler）的可见性建立在网络流量层面——它们可以看到用户访问了哪些 SaaS 应用，但无法区分”用户直接操作”和”Agent 代替用户操作”。
  • SSPM 只管配置：现有的 SSPM 工具（如 Adaptive Shield、AppOmni）关注的是 SaaS 应用的配置错误——比如 Salesforce 中的某个字段权限设置不当。但 Agent 的问题不在于配置，而在于运行时行为。
  • SIEM 淹没在噪音中：将 Agent 活动日志导入 SIEM（如 Splunk、Microsoft Sentinel）在理论上可行，但实际上会产生海量告警。一个 Copilot 用户每天12-18次操作，乘以3万用户，就是每天36-54万条日志——其中99.9%是正常行为。

Reco 试图填补的正是这个空白：Agent 层面的可见性和控制。这是一个真实的、紧迫的需求。

2.3 Reco 的方案为什么不够

但如果我们更深入地思考 Agent 安全的本质，Reco 的方案存在几个结构性局限：

局限1：可见性 ≠ 可控性。 Reco 可以告诉你企业中有多少个 Agent、它们在做什么。但”发现”和”治理”之间存在巨大的鸿沟。当安全团队发现市场部在 Make 上创建了200个 AI 工作流，其中30个存在数据泄露风险时，他们能做什么？直接禁用会中断业务流程；逐一审查需要理解每个工作流的业务逻辑，而安全团队通常不具备这个上下文。

局限2：外部 Agent 的黑盒问题。 Reco 的方案依赖于对 SaaS 平台 API 和日志的访问。但当 Agent 的推理引擎是一个外部 LLM（如 GPT-4o 或 Claude）时，Reco 无法看到 Agent 的”思考过程”——它只能看到输入（Agent 读取了什么数据）和输出（Agent 执行了什么操作），但无法理解 Agent 为什么做出这个决策。这意味着 Reco 的异常检测本质上是基于统计模式的，而不是基于语义理解的。一个 Agent 出于完全合理的业务原因突然访问了财务系统（比如季度末的跨部门报告需求），在统计模型中会被标记为异常；而一个被精心设计的恶意 Agent，如果其行为模式与正常 Agent 足够相似，则可能完全逃过检测。

局限3：Agent-to-Agent 交互的盲区。 当前 Agent 安全讨论的焦点是”人类创建的 Agent 做了什么”。但下一阶段的问题是”Agent 创建的 Agent 做了什么”。Sycamore 在2026年6月获得了6500万美元种子轮融资（据报道由 Coatue 和 Lightspeed 领投，天使投资人包括前 OpenAI 研究副总裁 Bob McGrew 和 Intel CEO Lip-Bu Tan），其核心产品就是企业级 Agent 编排层——允许 Agent 之间相互调用和协作。当 Agent A 调用 Agent B 来完成一个子任务，而 Agent B 又调用 Agent C 时，权限传递和数据流向的复杂性呈指数级增长。Reco 的当前方案似乎还没有覆盖这个场景。

（来源: TechCrunch, 2026-06; Sycamore 官方公告, 2026-06）

局限4：Agent 身份的根本问题。 在传统安全模型中，每个实体都有一个明确的身份——用户有用户名，服务账户有 API Key，应用有 OAuth Client ID。但 AI Agent 的身份模型是模糊的：一个在 Make 上创建的工作流，使用的是创建者的 OAuth 令牌，调用的是 OpenAI 的 API Key，操作的是 Salesforce 中的共享服务账户。当这个 Agent 执行了一个违规操作时，责任归属于谁？创建者？审批者？平台提供商？LLM 提供商？这不仅是技术问题，更是治理和合规问题。

2.4 竞争格局：Reco 不是唯一的玩家

值得注意的是，Agent 安全这个空白并非只有 Reco 一家在填补。至少有三类竞争者值得关注：

  • 同类 SSPM 厂商的横向扩展：Valence Security 在2025年底已经开始在其 SaaS 安全平台中增加”非人类身份”（Non-Human Identity）的发现和管理功能，虽然尚未明确打出”Agent 安全”的旗号，但技术方向高度重合。Nudge Security 则从”影子 SaaS 发现”切入，其产品天然具备追踪员工自行注册的 AI 工具（包括 Agent 平台）的能力。Astrix Security 专注于非人类身份和 API 密钥的生命周期管理，这与 Agent 身份问题直接相关。
  • CNAPP/云安全巨头的降维打击：CrowdStrike 在2024年收购了 Adaptive Shield（SSPM 厂商），Palo Alto Networks 的 Prisma Cloud 已经将 SaaS 安全纳入路线图，而 Wiz 在2025年被 Google 以约320亿美元收购后，正在将 SaaS 和 AI 安全作为其下一阶段扩展的重点方向。对于这些巨头来说，Agent 安全不过是”又一个数据源”和”又一组检测规则”——它们有现成的客户基础、销售渠道和平台架构来快速整合这个功能。
  • 平台原生安全能力：Microsoft 已经在 Purview 中增加了 Copilot 活动的数据分类和 DLP（数据防泄漏）功能。Salesforce 在 Agentforce 中内建了”Einstein Trust Layer”，包括输入/输出审计、PII 检测和权限边界执行。如果每个 SaaS 平台都在自己的产品中内建 Agent 安全功能，第三方工具的价值就会被压缩。

Reco 的差异化在于”跨平台统一视图”——它不绑定任何单一 SaaS 生态，而是试图提供一个覆盖所有 Agent 平台的安全层。但这个差异化能否转化为持久的竞争壁垒，取决于它能否在18-24个月的窗口期内建立足够的市场份额和技术深度。

三、对立视角：Agent 安全是真需求还是制造焦虑？

3.1 看多方：Agent 安全是下一个10亿美元品类

支持 Agent 安全成为独立品类的逻辑链条是清晰的：

  1. Agent 数量正在指数级增长（上述数据已经证明）。
  2. Agent 拥有比人类用户更大的潜在攻击面（因为它们可以自动化地、高速地访问数据和执行操作）。
  3. 现有安全工具无法有效覆盖 Agent 层面的风险。
  4. 监管压力正在增加——欧盟 AI Act 在2026年8月开始全面执行，其中对”高风险 AI 系统”的透明度和可审计性要求直接适用于企业中的 AI Agent。

从市场规模看，如果 SSPM 市场在2025年的规模约为8亿美元（来源: Gartner Market Guide for SaaS Security, 2025），Agent 安全作为 SSPM 的超集，在3-5年内达到20-30亿美元的市场规模是合理的推算。

agnost.ai 在2026年4月发布的一篇分析文章中提出了”Agent Experience (AX)”的概念，认为在12-18个月内，Agent 的可信度、可审计性和可恢复性将成为企业采购 AI 解决方案的核心评估标准——就像”用户体验 (UX)”在2010年代成为 SaaS 采购的核心标准一样。如果 AX 成为行业标配，那么提供 AX 度量和保障的安全工具就会成为刚需。

3.2 看空方：Agent 安全风险被高估，现有架构已经够用

反对 Agent 安全成为独立品类的论点同样有力，而且不止一种：

论点1：Agent 本质上继承用户权限，零信任架构已经覆盖。 一位不愿具名的大型金融机构 CISO 在2026年5月的 RSA Conference 上表达了这样的观点：”Agent 不是一个新的安全主体，它是用户权限的延伸。如果你的零信任架构做得足够好——最小权限、持续验证、微分段——Agent 的风险就已经被控制在可接受范围内了。我们不需要一个新品类，我们需要把现有的东西做好。”这个观点有一定道理：如果企业严格执行最小权限原则，Copilot 能访问的数据就只有用户真正需要的那些，Agent 扩散的风险就会大幅降低。问题在于，正如 Microsoft 自己承认的，大多数企业的权限管理远未达到这个标准——但这是权限管理的问题，不一定需要一个全新的安全品类来解决。

论点2：Agent 的可审计性反而高于人类操作。 这是一个反直觉但值得认真对待的论点。人类用户在 SaaS 应用中的操作往往是零散的、不可预测的，而且很多操作（比如在浏览器中复制粘贴敏感数据）根本不会留下日志。相比之下，Agent 的每一次 API 调用、每一次数据读写都有完整的日志记录。从审计角度看，Agent 实际上比人类更透明。如果安全团队能够有效利用现有的 SIEM 和日志分析工具来处理 Agent 日志，是否真的需要一个专门的”Agent 安全”产品？

论点3：平台内建安全才是正途，第三方工具的空间会被持续压缩。 Microsoft 的 Purview、Salesforce 的 Einstein Trust Layer、Google Workspace 的 AI 安全控制——每个主要 SaaS 平台都在快速增强自己的 Agent 安全能力。历史经验表明，当平台原生安全功能达到”足够好”的水平时，第三方安全工具的市场空间就会急剧萎缩。2010年代的杀毒软件市场就是前车之鉴——当 Windows Defender 变得足够好时，独立杀毒软件厂商的市场份额大幅下降。

论点4：Agent 扩散可能是暂时现象。 当前 Agent 扩散的一个重要驱动力是”新奇效应”——企业中的各个部门都在尝试 AI Agent，但其中很大比例的 Agent 可能在3-6个月后就会被废弃（因为维护成本高于预期、效果不如预期、或者负责人离职）。如果 Agent 的实际存活率只有20-30%，那么”Agent 扩散”的长期严重程度可能被当前的增长数字高估了。

3.3 我的判断

我的判断是：Agent 安全是一个真实且持久的需求，但作为独立品类的窗口期可能只有18-24个月。

原因如下：

第1，Agent 扩散不是暂时现象。与2023-2024年的”AI 试点热潮”不同，当前的 Agent 部署已经深度嵌入业务流程。当一个销售团队的 Pipeline 管理完全依赖 Agentforce Agent 时，你不能简单地”关掉它”。Agent 的粘性远高于独立的 AI 聊天工具。看空方关于”Agent 存活率低”的论点低估了 Agent 与业务流程的耦合深度。

第2，”零信任已经够用”的论点在理论上成立，但在实践中站不住脚。是的，如果每家企业都完美执行了最小权限原则，Agent 风险会大幅降低。但这就像说”如果每个人都不闯红灯，就不需要交通摄像头”——它忽略了现实世界的混乱。Microsoft 自己的数据（用户权限超出实际需求10倍以上）就是最好的反驳。在权限管理达到理想状态之前（这可能永远不会发生），Agent 安全工具提供的额外可见性和控制层是有实际价值的。

第3，Agent 的可审计性确实高于人类操作，但这恰恰是 Agent 安全工具的机会而非威胁。丰富的日志数据意味着安全工具有更多的信号可以分析——前提是有人能够从海量日志中提取有意义的洞察。这正是 Reco 这类专业工具的价值所在：不是替代 SIEM，而是在 SIEM 之上提供 Agent 特定的语义分析和策略执行。

第4，但长期来看，Agent 安全会被整合进更大的安全平台。就像 CASB 最终被 Palo Alto、Zscaler 和 Netskope 整合进了更大的 SASE（安全访问服务边缘）平台一样，Agent 安全最终也会成为 CNAPP 或 SSPM 平台的一个功能模块，而不是一个独立产品。Reco 的最佳退出路径可能是在18-24个月内建立足够的市场份额和技术壁垒，然后被 Wiz、Palo Alto 或 CrowdStrike 收购。

四、大多数人没看到的：Agent 安全的真正战场不在”可见性”，而在”身份与信任”

4.1 Agent 身份危机

这是我认为当前 Agent 安全讨论中最被忽视的维度。

在人类用户的世界里，身份验证和授权已经有了成熟的框架：SAML、OAuth 2.0、OpenID Connect、SCIM。但 AI Agent 的身份模型是一个未解决的根本问题。

考虑以下场景：

  • 一个 Salesforce Agentforce Agent 被配置为”以 Sales VP 的权限运行”。这个 Agent 在凌晨3点自动更新了500条客户记录。在审计日志中，这些操作显示为 Sales VP 的行为。但 Sales VP 此时正在睡觉。
  • 一个 Make 工作流使用了创建者（市场经理）的 OAuth 令牌来访问 Google Analytics，但使用了一个共享的 API Key 来调用 OpenAI 的 GPT-4o。当 GPT-4o 的输出包含幻觉数据并被写入 CRM 时，责任归属于谁？
  • 一个 n8n 工作流被创建者分享给了整个团队。团队中的5个人各自修改了工作流的不同部分。当这个工作流导致数据泄露时，”创建者”这个概念已经失去了意义。

Agent 需要自己的身份。 不是人类用户的代理身份，不是服务账户的复用，而是一种全新的、专为 AI Agent 设计的身份原语。这个身份需要包含：Agent 的创建者、审批者、运行时权限边界、允许调用的外部服务列表、数据访问分类级别、以及行为审计链。

目前，没有任何标准或协议来定义这种 Agent 身份。OAuth 2.0 的 RFC 中没有”Agent”这个概念。SCIM（跨域身份管理系统）的规范中也没有。IETF 和 OpenID Foundation 尚未发布任何关于 AI Agent 身份的草案。这是一个基础设施层面的空白，而不仅仅是一个产品层面的空白。谁能率先定义 Agent 身份标准，谁就能在这个赛道中占据最有利的位置——就像 Okta 通过拥抱 SAML 和 OIDC 标准成为了身份管理领域的领导者一样。

4.2 Agent 信任链的脆弱性

Anthropic 在2026年6月意外泄露了 Claude Code 的源代码——据报道约2000个文件、50万行代码。虽然 Anthropic 声称”未涉及客户数据或模型权重”，但竞争对手获得了 Claude Code 内部架构的详细洞察。更值得关注的是泄露的方式：被描述为”人为失误”。

这个事件揭示了 Agent 信任链中一个被低估的风险：Agent 的安全性不仅取决于 Agent 本身的配置，还取决于 Agent 所依赖的整个供应链的安全性。 当一个企业的 Agent 使用 Claude 作为推理引擎时，Claude 的代码安全性、Anthropic 的运营安全性、以及 Claude API 的可用性，都成为了这个 Agent 安全态势的一部分。这与软件供应链安全（SolarWinds 事件、Log4j 漏洞）的逻辑完全一致，但复杂度更高——因为 Agent 的供应链不仅包括代码依赖，还包括模型依赖和推理服务依赖。

同样值得关注的是 Anthropic 即将发布的下一代模型。根据多方报道，这个模型在推理、编码和网络安全能力上实现了显著提升，Anthropic 自己警告其可能被用于攻击性用途。当 Agent 的推理能力越来越强时，Agent 的潜在危害也在同步增长——一个能够理解和利用网络安全漏洞的 Agent，如果被恶意配置或被攻击者劫持，其破坏力远超传统的自动化脚本。

4.3 地缘政治维度：Agent 安全的国家级博弈

开源 AI Agent 工具在全球范围内的爆发式增长引入了一个额外的维度：Agent 安全不仅是企业安全问题，也是国家安全问题。

当企业使用的 AI Agent 依赖于不同国家开发的 LLM、不同国家运营的 SaaS 平台、以及不同国家托管的数据中心时，数据主权和供应链安全的复杂性呈指数级增长。欧盟 AI Act 对”高风险 AI 系统”的监管要求、美国对中国 AI 技术的出口管制、以及各国对数据本地化的要求，都在为 Agent 安全增加地缘政治维度。

这意味着 Agent 安全工具不仅需要回答”这个 Agent 做了什么”，还需要回答”这个 Agent 的推理引擎在哪里运行？数据流经了哪些司法管辖区？Agent 的行为是否符合所有适用的监管要求？”这些问题的复杂度远超传统的 SaaS 安全。

五、Agent 安全的技术路线图：从可见性到自主治理

5.1 短期（6-12个月）：发现与分类

这是 Reco 当前所处的阶段。核心能力是回答”我们有多少个 Agent？它们在做什么？它们访问了什么数据？”这些基本问题。这个阶段的技术挑战主要在于跨平台集成——需要与数十个 SaaS 平台的 API 和审计日志对接。

这个阶段的竞争者不仅包括 Reco，还包括 Valence Security、Nudge Security、Astrix Security 等非人类身份安全厂商，AppOmni、Obsidian Security 等现有 SSPM 厂商，以及可能从 CNAPP 方向切入的 Wiz 和 Orca Security。

5.2 中期（12-24个月）：Agent 身份与策略引擎

这个阶段的核心挑战是建立 Agent 身份标准和策略执行框架。需要回答的问题包括：

  • 如何为每个 Agent 分配独立的身份标识？
  • 如何定义 Agent 的权限边界——不仅是”它可以访问什么”，还包括”它可以做什么决策”？
  • 如何在 Agent 的运行时行为违反策略时进行实时干预，而不破坏业务流程？

Sycamore 的 Agent 编排层可能在这个阶段扮演关键角色——如果企业通过 Sycamore 来编排和管理 Agent，那么 Sycamore 就天然地成为了 Agent 身份和策略的执行点。这也是为什么 Sycamore 能够以6500万美元的种子轮估值吸引到 Bob McGrew（前 OpenAI 研究副总裁）和 Lip-Bu Tan（Intel CEO）这样级别的天使投资人——他们看到的不仅是编排层的商业价值，还有其作为安全控制点的战略价值。

5.3 长期（24-36个月）：Agent 自主治理与 Agent-to-Agent 安全

这是最具挑战性也最具想象力的阶段。当企业中的 Agent 数量达到数万甚至数十万时，人工审查和管理将变得不可能。安全本身需要被 Agent 化——用安全 Agent 来监控和治理业务 Agent。

这听起来像是一个递归问题（”谁来监控监控者？”），但在实践中，安全 Agent 和业务 Agent 之间的信任关系可以通过密码学手段（如零知识证明、可验证计算）来建立，而不需要依赖人工信任。

这个阶段还需要解决 Agent-to-Agent 通信的安全协议。当 Agent A 需要调用 Agent B 来完成一个子任务时，如何验证 Agent B 的身份？如何确保 Agent B 不会超出 Agent A 授予的权限范围？如何在 Agent B 返回的结果中检测幻觉或恶意数据？这些问题与微服务架构中的服务网格（Service Mesh）安全有相似之处——Istio 和 Envoy 通过 mTLS 和策略引擎解决了微服务间的信任问题，Agent 世界可能需要类似的基础设施。

这些问题目前还没有成熟的解决方案，但它们将在未来24-36个月内成为 Agent 安全领域的核心研究方向。

六、So What：这对你意味着什么

对 CISO 和安全团队

立即行动：在你的企业中进行一次 Agent 普查。你可能会发现 Agent 的数量比你想象的多10倍。重点关注 Make、n8n、Zapier 等低代码平台上的自定义 Agent——它们是最大的盲区。同时审查 Microsoft 365 Copilot 和 Salesforce Agentforce 的部署范围和权限配置。

短期策略：评估 Reco 或类似的 Agent 安全工具（包括 Valence Security、Nudge Security 等）。即使你最终选择等待大平台的内建功能，现在获得 Agent 可见性本身就有巨大价值——你无法保护你看不见的东西。同时，利用这个窗口期清理企业中的过度权限问题——这是降低 Agent 风险最直接、最有效的手段。

中期规划：开始制定 Agent 治理框架。这不仅是技术问题，还涉及组织架构——谁有权创建 Agent？谁负责审批？谁负责持续监控？Agent 的生命周期管理（创建、修改、停用、销毁）需要像人员入离职一样流程化。考虑设立”Agent 治理委员会”，由安全、IT、法务和业务部门共同参与。

对 SaaS 创业者

Agent 安全是一个真实的市场机会，但窗口期有限。如果你要进入这个赛道，不要只做”可见性”——这是最容易被大平台复制的功能。你需要在 Agent 身份、Agent 策略引擎或 Agent-to-Agent 安全协议这些更深层的技术方向上建立壁垒。Reco 的路径（从 SSPM 延伸到 Agent 安全）是一种可行策略，但 Sycamore 的路径（从 Agent 编排切入安全控制点）可能更具防御性。

对投资者

Agent 安全赛道的投资逻辑类似于2019-2021年的云安全赛道：一个新的计算范式（从虚拟机到容器到 Agent）催生了新的安全需求，而现有安全工具无法满足。但要注意两个风险：第1，大平台的内建安全功能可能比预期更快地压缩第三方工具的空间；第2，Agent 安全的最终形态可能不是一个独立品类，而是被整合进更大的安全平台。最佳投资标的可能不是纯粹的 Agent 安全公司，而是那些将 Agent 安全作为核心差异化功能整合进更大产品线的公司——比如 Sycamore 这样的 Agent 编排平台，或者下一代的 SSPM/CNAPP 平台。

对所有人

AI Agent 的扩散正在重塑企业的安全边界。在过去20年里，安全边界从网络（防火墙）扩展到端点（EDR）再扩展到云（CNAPP）再扩展到 SaaS（SSPM）。现在，它正在扩展到 Agent。每一次边界的扩展都催生了价值数十亿美元的新安全品类。Agent 安全可能是下一个。

Reco 的发布不是终点，甚至不是起点——它只是一个信号，表明行业终于开始正视一个已经存在了至少18个月的问题。真正的战斗才刚刚开始。而这场战斗的胜负，不取决于谁能最先”看到” Agent，而取决于谁能最先解决 Agent 身份、Agent 信任链和 Agent 自主治理这些更深层的基础设施问题。

参考资料

  1. Reco Launches Industry-First AI Agent Security to Tackle Agent Sprawl Across SaaS — 来源: Reco 官方新闻稿, EIN Presswire, 2026-06
  2. Sycamore Raises $65M Seed Round for Enterprise AI Agent Orchestration — 来源: TechCrunch, 2026-06
  3. Agent Experience: The New Competitive Moat — Agnost.ai, 2026-04-02
  4. Salesforce FY2027 Q1 Earnings Call Transcript — 来源: Salesforce Investor Relations, 2026-05
  5. Microsoft FY2026 Q3 Earnings Call Transcript — 来源: Microsoft Investor Relations, 2026-04
  6. Gartner Market Guide for SaaS Security Posture Management — Gartner, 2025
  7. EU AI Act: Regulation Overview — European Commission, 2024
  8. n8n AI Workflow Growth Statistics — 来源: n8n 官方博客, 2026-04
  9. Make Developer Conference Keynote: AI Agent Operations Data — 来源: Make, 2026-05
  10. OpenAI Enterprise Adoption Metrics — 来源: OpenAI Enterprise Blog, 2026-05