管控平面——在员工自建 AI 智能体对 Salesforce、Jira、GitHub 和 Google Workspace 采取行动之前完成审批。

1. 65% 的 AI 智能体事故率意味着企业已经积累了足够多的失败，足以为专项管控预算提供正当理由。
2. 风险面正在向智能体如何连接内部系统转移，这为围绕权限和操作的安全切口创造了明确的着力点。
3. 智能体已嵌入员工工作流，治理必须面向分散的业务团队，而非只服务中央 AI 实验室。
4. Willow 的种子融资表明投资人相信管控层正在成为独立品类，而在位企业尚未完全吃掉这个空间。

催化因素。 Willow 的融资和所援引的 AI 智能体事故率表明，企业已经面临智能体驱动的工作流风险； 而智能体直接连接内部系统，让部署前审批和快速撤权变得比以往更加紧迫。

产品接入主流智能体构建平台、身份提供商和 SaaS 管理 API， 为每个内部 AI 智能体建立实时注册表，记录创建者、可触达工具和可执行操作。 新智能体上线前，平台生成审批包——展示其关联系统、申请的权限范围、高风险写入操作和必须指定的责任人。 平台可拦截未经审批的智能体、设置有时限的访问权限，并在出现事故、策略违规或责任人空缺时触发终止开关。 安全团队获得一个贴近工作流的管控平面，而非分散的 OAuth 日志和手动应用审查； 业务团队则保留自助式智能体部署的速度。 随着时间推移，注册表成为企业内每个智能体的权威清单和策略引擎。

差异化。 现有的 IAM 和 SaaS 安全工具可以按用户或应用展示权限， 但它们并非围绕员工创建、绑定工作流、能跨多系统串联操作的智能体设计的。 AI 可观测性工具聚焦于事后的提示词、模型和输出， 而这个产品拥有部署前后的审批、责任人和撤权闭环。 护城河来自不断壮大的智能体身份、操作范围、高风险工作流模式和策略模板图谱—— 这些数据专门针对员工自建智能体，而非人类用户。

待完成任务

flowchart LR
  Buyer[CISO or Head of Enterprise AI] --> Pain[Unapproved agents acting in core SaaS systems]
  Pain --> Product[Employee agent change-control plane]
  Product --> Outcome[Safer self-serve agent rollout with instant revocation]

高管要点

• 真正的切口不是通用 AI 安全，而是针对能在业务 SaaS 中执行操作的员工自建智能体的跨平台变更管控。
• 原生平台治理正在快速落地，但依然局限于各自的厂商生态；混合技术栈企业仍缺乏一套跨智能体构建平台、连接器和外部 SaaS 操作的统一审批路径、责任人记录和快速撤权工作流。
• 买家的紧迫性是被真实事故率、影子智能体发现和治理成熟度滞后推动的，而非单纯由抽象的未来监管驱动。
• 最具防御性的产品层将权限模拟、责任人指定和快速撤权与涵盖智能体、工具和委托操作的清单图谱结合在一起。
• GTM 应从业务团队已在无集中审查的情况下推送智能体的地方切入：Microsoft、Google 和 Salesforce 重度技术栈服务企业中的客服、营收运营和内部 IT。

市场定义

面向员工自建和业务部署 AI 智能体的跨平台治理软件——这些智能体可以读写或触发企业 SaaS 系统中的操作。

用户与买方

主要用户是必须审批和追踪智能体访问权限的企业 AI 平台或安全团队；经济买家通常是 CISO、CIO 或企业 AI 平台负责人。

购买触发点

• 一次安全事故、权限范围违规或影子智能体发现，立即催生对统一责任人注册表和快速撤权工作流的需求。 [17][18][19]
• 更大规模地推广 Copilot Studio、Agentforce、Gemini 或类似构建平台，迫使中央团队用明确的审批管控取代工单审查。 [2][3][5][6][7]
• 当企业意识到治理成熟度远落后于采用率，且即将面临监管预期时，合规项目的紧迫性便会凸显。 [9][10][13][14][15]

支付意愿

企业已经在按用量和按用户模式为智能体能力付费，而事故和可见性缺口又创造了独立的安全预算理由。管控层可以对标避免的审查人力和更快的事故遏制来定价，而非仅仅对标原始模型支出。 [7][13][17][18][19]

品类动态

增长信号 KPMG 调查显示，约两年内运营级 AI 智能体采用率从 33% 增长至 54%

验证信号

• Willow 的融资和 Wix 共创客户背书验证了企业已将智能体治理视为独立问题。
• CSA 调查表明未知智能体、权限范围违规和事故已普遍存在，支持了紧迫管控平面切口的论点。
• Gravitee 的报告显示安全审批覆盖率仍远落后于生产部署，留下了清晰的运营空白。
• 主要平台正在竞相增加自己的治理面板和策略面，确认了买家需求，即便解决方案仍局限于各自的生态系统。

监管与技术约束

• 该品类中的任何产品都必须将委托智能体权限映射到跨关联工具的明确最小权限管控、审批证据和审计日志。
• 提示词注入和工具滥用风险意味着仅审批的产品最终需要运行时钩子或快速撤权路径。
• 企业需要可追溯的人类所有权和文档化监督，才能与不断演进的 AI 治理预期保持一致。
• 服务账号复用和凭证共享破坏了归因，因此身份层集成是技术必需而非可选项。

竞争格局正在分化为三个阵营：主要云平台和 SaaS 套件内的原生平台治理、延伸至智能体的身份/NHI 厂商，以及专注于态势管理和运行时检测的 AI 安全厂商。空白地带是一个能横跨三者的工作流原生审批平面。

为什么现有厂商不会默认胜出

• 云平台. Microsoft、Google 和 Salesforce 能在各自的技术栈内增加强管控，但混合技术栈企业仍需要一套跨构建平台、连接器和外部 SaaS 操作的统一清单和审批层。
• 身份与 NHI 厂商. 身份优先的厂商在凭证、服务账号和最小权限方面实力强，但它们并不自然地拥有上线前审批、责任人指定和委托操作签字的业务工作流。
• SaaS 安全厂商. 发现导向的 SaaS 安全工具能暴露影子 AI 和应用蔓延，但它们不是安全团队和业务团队在上线前联合模拟和审批智能体覆盖范围的默认场所。
• 通用 AI 安全平台. 运行时监控很重要，但买家在高风险智能体触及生产数据之前，仍然需要部署前护栏和责任归属系统记录。

员工智能体变更管控应当以跨平台审批平面起步，服务于拥有 1,000–5,000 名员工的 数字产品和服务企业——而非定位成又一个通用 AI 安全仪表盘、智能体运行时， 或单一厂商的管理附加组件。首批客户是约 2,000 人规模的服务或软件密集型运营商， 其中客服、营收运营和内部 IT 团队已将 Copilot Studio、Agentforce 或 Gemini 类智能体 接入 Salesforce、Zendesk、Jira、GitHub 和 Google Workspace，却没有集中审查路径。 触发购买的是事故、审计发现，或迫使 CISO 或 CIO 证明哪些员工自建智能体 可以在核心系统中执行操作的企业推广决策。研究支持一个可观的市场： 估计 TAM 为 $2.5B，SAM 为 $360.0M，若公司专注于混合技术栈企业而非追逐 单一平台部署，第三年 SOM 建模值为 $6.0M。MVP 应从 智能体清单、权限模拟、责任人指定、审批包和跨少数构建平台及 SaaS 系统的 快速终止开关起步。公司能赢的条件是：成为 Microsoft、Google 和 Salesforce 重度混合技术栈企业中已批准智能体覆盖范围的工作流原生系统记录， 而原生管控工具无法跨厂商统一。主要风险在于平台、身份和 AI 安全在位企业 比初创公司建立发行渠道的速度更快地推出"足够好"的治理功能。 第二个重大缺口是独立定价证据和共享服务账号背后的发现完整性仍未经验证， 因此前 12 个月必须测试买家是否愿意为中立审批覆盖层付费， 以及清单是否足够完整以赢得信任。

问题

• 安全和企业 AI 平台团队一旦业务团队把智能体接入 Salesforce、Jira、GitHub、Google Workspace、Zendesk 等核心 SaaS 系统，就无法一致地查看、审批和撤销员工自建的智能体。
• 现有的 IAM、SaaS 管理、DLP 和 AI 可观测性工具分别管理人类、应用或运行时行为，却无法提供一套跨平台的审批工作流——包含指定责任人、界定权限范围和上线前即时撤权。

解决方案

• 构建一个管控平面：盘点每个内部智能体，梳理创建者和责任人，模拟可触达的系统和高风险操作，并在高权限连接上线前生成审批包。
• 以只读审批、有时限访问和一键撤权为起点，覆盖最常用的构建平台和 SaaS 系统；只有在审批工作流采用得到验证之后，才增加运行时偏差检测和执行功能。

为什么我们会赢

• 产品解决的是混合技术栈问题——Microsoft、Google 和 Salesforce 只在各自的生态系统内覆盖。
• 审批包、责任人指定和快速撤权，比广泛的 AI 安全态势或可观测性产品更精准地对应买家的推广受阻问题。
• 跨客户积累的智能体、权限范围、责任人、下游操作和偏差事件图谱，可以形成差异化的风险与策略数据集。

里程碑

flowchart LR
  Wedge[Mixed-stack agent approval wedge] --> MVP[Inventory plus approval packet MVP]
  MVP --> Proof[Named owners, faster approvals, and rapid revocation]
  Proof --> Expansion[Drift monitoring and broader control plane]

创始团队

实验路线图

风险评估

必须成立的条件

• 混合技术栈企业必须将跨平台智能体审批视为有预算支撑的问题，而非手动审查的临时延伸。
• 初始构建平台和 SaaS 连接器组合必须覆盖滩头市场内大多数高风险的业务主导智能体部署。
• 发现完整率必须足以暴露影子智能体并支持责任人指定，而无需大量手动清理工作。
• 买家必须在第一份合同中先采用审批工作流和终止开关管控，再要求完整运行时执行。
• 首次生产部署必须能支撑约 $45k+ 年度价值，同时保持可产品化的入驻流程。

待尽调问题

• 混合技术栈客户实际上多久会跨越一个原生管控停止生效的厂商边界？
• 在涉及服务账号和通用 OAuth 应用的早期试点中，产品能发现多大比例的高风险智能体？
• 清单、权限模拟、责任人记录还是终止开关——哪个审批材料才是改变购买决策的关键？
• 一旦问题从事故响应升级到规模化推广，预算实际归属于安全、身份还是企业 AI 平台？
• 什么样的试点打包和定价能实现最佳转化，同时不让入驻变成咨询项目？

模型合理性

• 收入引擎. 年度订阅以 $50K ARPU 为基础，通过 60% 试点转生产漏斗扩张， 从第一年 4 个客户复利增长至第三年末 110 个； 从第二年第一季度起，销售 AE 和合作伙伴渠道补充创始人主导销售。
• 必须走对的事. 前 3–5 个付费试点必须在第 8 个月前签署，并以 50%+ 转化率完成， 才能支撑第二年第三季度 18+ 客户的 A 轮里程碑； 一个季度的试点签约停滞会延迟所有后续的融资和招聘里程碑。
• 模型失效条件. 若 Microsoft、Google 或 Salesforce 在 18 个月内推出可信的跨厂商智能体治理， ARPU 将被压缩至 $35K 以下，按 ARPU 敏感性分析行，第三年收入减少约 $990K， 在现有成本结构下 A 轮里程碑将无法达成。
• 下一轮证明. 第二年第三季度的 A 轮要求 18 个生产客户和 $850K 以上的 ARR 运转率， 且须通过直销和至少一个合作伙伴渠道共同验证， 与基准情景现金低点 $1,875.8K 和第三年消耗倍数 0.29x 一致。

情景

敏感性

flowchart LR
  Leads --> Pilots
  Pilots --> Production
  Production --> ARR
  ARR --> GrossProfit
  GrossProfit --> EBITDA
  EBITDA --> Cash
  Partners --> Pilots
  Churn --> Production

警示项: 第二年第三季度 A 轮关闭是关键节点：$8M 融资在该季度体现为 $9,875.8K 的现金跳升；若未完成，公司在第二年第二季度之前就会耗尽种子资金 · 试点转生产转化率假设为 60%；若连续两个季度低于 40%，A 轮里程碑将无法达成，模型需要过桥资金或立即降低消耗 · 发现完整性尚未经过验证——BP 运营假设要求 80%+ 的智能体可被发现；不完整的清单会降低试点信心，并威胁 $50K ACV 锚定 · 平台原生治理风险在 BP 风险登记簿中被评为高可能性、高影响；ARPU 从 $50K 压缩至 $35K 将使第三年收入减少约 $990K，如敏感性分析所示

• 在位企业捆绑销售. 身份管理、SaaS 管理或智能体平台厂商可能在初创公司建立发行渠道之前就推出部分审批和清单功能。 缓解措施: 以跨平台深度、工作流专属策略模板和在混合智能体栈（而非单一厂商环境）中更快的事故撤权来赢得竞争。
• 发现盲区. 如果大量员工自建智能体在已支持的构建平台之外创建，或藏匿于通用服务账号之后，清单可能显得不完整。 缓解措施: 先从涵盖大多数业务主导部署的少数构建平台和 SaaS 系统起步，再通过身份、OAuth 和管理日志集成扩展发现能力。
• 安全审批阻力反弹. 业务团队可能将产品视为新的审批瓶颈，转而用影子自动化绕过治理。 缓解措施: 以快速审批、清晰的责任归属和一键模板为主打——让安全智能体快速上线，只对高风险范围升级处理。