审计级身份图谱，在上线扩容卡住前证明哪些 AI agent 碰过敏感的 M365 和 ServiceNow 数据。

1. 如今企业面对的已经不是模糊的担心，而是可以量化的归因问题，因为很多组织在生产系统里根本分不清 agent 行为和人工行为。
2. 治理重心正在往数据和权限层迁移，所以只盯网络边界或模型输出的产品，会错过真正卡审批的地方。
3. 投资人已经按核心基础设施的逻辑在给可信 AI 数据访问打钱，这意味着企业买方会把它当成独立预算科目，而不是塞进泛安全开支里。
4. 市场正在把 DSPM、身份、DLP 和 agentic security 收拢到一起，这给了一个机会：先把 agent 归因这个具体问题解决，再往更宽的栈扩。

催化因素。 Cyera 把数据访问定义成 AI 新边界，再叠加 68% 的归因盲区，让 agent 上线审批立刻变成治理瓶颈。

产品接入 Entra ID、Microsoft 365、SharePoint、OneDrive、Teams、ServiceNow 以及现有 SIEM 或 DSPM 工具，搭出一张实时图谱，把用户、service principal、agent、数据存储和继承权限放到一处。针对每条拟上线或已上线的 agent 工作流，它会模拟能触达哪些敏感数据，标出访问路径里哪些靠用户委托、哪些靠常驻机器身份，再把运行时真正碰过什么记下来。安全团队最终拿到的是一份能直接给审批人看的视图，一次回答三个问题：这个 agent 能看什么、它实际看了什么、哪些权限链该先清。第一版的赢法很直接——把原本靠表格做的访问分析，从几个月压到几天。

差异化。 大多数 AI 治理产品从模型策略或泛化的数据分类切入，这家公司则从一个一直没被解开的身份问题切进去：当 agent 真正碰到企业数据时，到底是谁在行动。也因此，它在上线前后都能派上用场：先做新 agent 的审批引擎，再做审计和事故调查时的运行证据系统。这个切口在重 Microsoft 的环境里尤其强，因为群组继承、委托权限和协作内容蔓延会藏出一大片隐形影响半径，而泛 IAM 或 DSPM 工具很难用 agent 原生的语言把它讲清。

待完成任务

flowchart LR
  Buyer[CISO / AI Security Team] --> Pain[Cannot separate human vs agent data access]
  Pain --> Product[Agent attribution graph]
  Product --> Outcome[Faster rollout approval and audit-ready evidence]

高管要点

• 最锋利的切口不是泛泛的 AI 治理，而是替那些要碰复杂 Microsoft 365 和 ServiceNow 权限体系的 agent，先做上线前审批证据。
• 买方的紧迫感很真，因为连 Microsoft 都把 oversharing 视为 Copilot 最大的数据风险，而多项调查也显示，生产环境里未知 agent、越权范围和审批覆盖不足已经很常见。
• 现有厂商已经占住了 DSPM、Microsoft 数据治理、身份治理和 agent 安全这些相邻预算位，所以这家初创公司必须靠跨系统归因和能直接拿给审批人的审计证据赢，而不是只做发现。
• 金融服务和 pharma 依然很适合作为首站，因为这些行业本来就对可审计性、访问治理和受控 AI rollout 有更高要求。
• 只要它能把 rollout review 从权限清理项目压缩成和具体 agent 运行绑定的证据化签字流程，这家公司就站得住。

市场定义

这个市场处在 Microsoft 365 数据安全、身份治理和 agent 安全的交叉口：它卖的是一类软件，能在生产扩容前证明内部 AI agent 究竟能触达协作与工作流系统里的什么内容，并在事后记下它实际碰过什么。

用户与买方

日常使用者是负责 Microsoft 365 Copilot、Copilot Studio 和 ServiceNow agent rollout 的 AI 安全、数据安全或身份治理团队。真正拍板预算的通常是 CISO 或信息安全副总裁；次级 champion 往往是 SharePoint、Entra 和 ServiceNow 平台负责人。

购买触发点

• 当 Copilot 或内部 agent rollout 要从试点扩大时，安全团队必须先证明 oversharing 和 least-privilege 问题已经被控住，企业才敢把访问权限放给更多员工。 [5][7][38]
• 一旦出现 shadow agent、越界使用，或安全审批覆盖不完整，采用速度和治理成熟度之间的缺口就会立刻暴露。 [15][16][17]
• 在受监管企业里，上线 ServiceNow 和 Copilot agent 时，买方需要比原生日志更强的身份、审计和人工监督控制。 [10][9][32][34]

支付意愿

付费意愿应该来自已经存在的 Microsoft 安全、数据治理和身份预算。这个痛点并不虚：安全团队已经在做 oversharing 清理、agent 审批 review 和 agent 事故响应。只要产品能把这些周期压短、减少 rollout 延误，就足以支撑一个六位数年合同，而不用逼客户新开一个预算类目。 [5][7][14][15][17]

品类动态

增长信号 34.27% CAGR

验证信号

• Cyera 最近的大额融资和 trust-layer framing，说明投资人相信：面向 agentic AI 的数据访问治理会长成基础设施。
• 多项调查已经显示，企业环境里未知 agent、范围越界、事故和审批覆盖不足并不罕见。
• 连 Microsoft 自己的 rollout 指南，都把 oversharing 整改和治理护栏当成 Copilot 大规模部署前的基础前提。

监管与技术约束

• Copilot 会继承用户现有权限，所以 SharePoint 或 OneDrive 里的过度共享和陈旧访问不会被助手抹平，只会被放大。
• Entra 已经把 agent 身份和委托权限当成一等治理对象，这直接抬高了生命周期管理和归属追踪的要求。
• 当个人数据或敏感数据卷进来时，欧盟和英国的指导都在把企业往“可问责、可审计、有人监督”的 AI 部署方式上推。
• 医疗和 pharma 买方即便首个用例是运营类而非临床类，也会更在意治理和文档要求。

这个赛道正在快速收敛。Microsoft 掌着 Copilot、Entra、Purview 和 Copilot Studio 的原生控制面；Cyera 和 Varonis 从 DSPM 与 M365 安全切数据权限问题；SailPoint 从身份和文件访问治理切入；Zenity 和周边 AI 安全初创公司更聚焦 posture 与运行时行为。真正空着的位置，是一张为 rollout 审批包和按运行批次证据而生的跨系统归因图谱，尤其适合一条 agent 流程同时横跨 M365 与 ServiceNow 的场景。

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

• Microsoft 平台栈. 如果 agent 只在 Entra、Purview、Copilot 和 Copilot Studio 里打转，Microsoft 完全有能力把它看住；但一旦工作流同时跨到 ServiceNow 和其他非原生工具，跨系统审批和独立运行证据就没那么好做了。
• DSPM 与数据安全厂商. Cyera 和 Varonis 的强项在于，它们本来就能把敏感数据、访问和暴露面画清楚；但默认叙事还是更偏广义数据安全，而不是专门替跨 M365 与 ServiceNow 的单次 agent 运行产出审批包。
• 身份治理厂商. SailPoint 和买方画像、控制模型都很贴，尤其适合处理 agent 身份和 SharePoint 文件访问；但它还不是那个一提到单次 agent 执行的运行归因，大家就默认会去看的系统。
• Agent 安全初创公司. Zenity 这类公司在发现、posture 和运行时护栏上很强；如果这家初创公司能把图谱数据真正变成帮助受监管 rollout committee 更快签字的工件，就能把自己拉开。

这家公司卖的是一层 agent 归因信任层，面向那些正把 Microsoft 365 Copilot、Copilot Studio 和 ServiceNow agent 推进到受监管企业里的团队，而这些企业本身就背着一套混乱的权限体系。第一款产品是一张只读图谱：在扩容前先告诉你某个 agent 能碰到 Entra ID、SharePoint、OneDrive、Teams 和 ServiceNow 里的什么；上线后再把它实际碰了什么记下来。首个买方是银行或 pharma 里由 CISO 牵头的安全团队，他们拥有 15,000+ Microsoft 365 席位，而且 rollout review 已经被卡住，因为这正是 oversharing 和归因风险已经升到管理层视野的地方。这个切口比泛 AI 治理更窄：卖的是审批包和修复优先级，把原本靠人工表格推进的 rollout signoff 压到几天。研究证明紧迫性是真的：Microsoft 一直在强调 oversharing readiness，多项调查也显示未知 agent、范围越界和审批覆盖不足已经发生；但真实转化率，以及买方究竟愿意为哪一套最小证据包掏钱，还要继续验证。TAM、SAM 和 SOM 都是基于装机盘子与 ACV 假设推出来的模型，不是已经锁定的需求。公司应当刻意避开泛模型治理、面向外部客户的 agent 用例，以及默认内联执行，先把“上线前审批 + 审计证据”这条落地路径跑通。如果团队能拿下 3 个付费共创客户，并把试点转成 $250k–$400k 的生产首单，就有机会在现有厂商把赛道压平之前，先占住 agent 专属证据系统的位置。

问题

• Copilot 和 ServiceNow agent 的 rollout 会继承陈旧的 Microsoft 365 权限，以及 SharePoint / OneDrive 里过度共享的内容，所以安全团队在更大范围部署前，根本证明不了这个 agent 的影响半径。
• 现有 SIEM、DSPM 和身份工具各自只能看见问题的一部分，没法把人工、委托和 agent 行为收成一份能直接交给审批人的记录。
• 手工访问审查和审计准备会把 rollout 审批拖到数周甚至数个季度，结果就是：明明 AI 项目预算已经批了，安全团队反而成了总闸门。

解决方案

• 在 Entra ID、Microsoft 365、SharePoint、OneDrive、Teams 和 ServiceNow 之上搭一张只读归因图谱，在生产扩容前先模拟每个 agent 能触达什么。
• 采集运行证据，标明敏感访问究竟来自人工、委托用户上下文，还是常驻机器身份，再把这些证据挂回已批准的工作流。
• 自动生成审批包并按优先级排出权限清理动作，让 rollout committee 不用先做完整 least-privilege 重建，也能更快签字。

为什么我们会赢

• 产品直接钉在一个具体审批工作流上，而不是做一个泛 AI 治理仪表盘，所以第一性 ROI 指标不是抽象的合规 posture，而是 rollout review 周期能缩短多少。
• 这个切口在同一套证据模型里把 Microsoft 365 和 ServiceNow 连起来，而原生控制和现有厂商工具通常只盯单一栈，或停留在更宽的数据安全叙事。
• 先聚焦受监管银行和 pharma，能更快打磨审计证据质量、修复模式和伙伴要求；如果一开始横着铺开，反馈回路反而会更松。

里程碑

flowchart LR
  Wedge[Blocked Copilot expansion review] --> MVP[Read-only attribution graph]
  MVP --> Proof[Approval packets and runtime evidence]
  Proof --> Expansion[Multi-workflow expansion and recertification]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少一半目标共创客户今天确实因为无法快速证明 agent 专属数据触达，而推迟 rollout 扩容。
• 在买方要求内联阻断之前，只读证据加修复优先级本身就足以构成一个值得单独买的首款产品。
• Microsoft 和 ServiceNow 暴露出来的身份与运行时遥测，已经足够区分初始工作流里的 agent、委托用户和 service principal 行为。
• 一份中立审批包，比现有厂商工具拼装或纯人工 review 更能加快试点转化。
• 公司能以 $250k+ ACV 拿下首单，并靠更多工作流做扩张，而不会滑成服务密集型业务。

待尽调问题

• 到底哪些审批工件，最能让 rollout committee 缩短签字时间？
• 早期客户有多常要求文件级或记录级的运行证据，而不是工作流级摘要？
• Onboarding 里哪些部分是可复用软件，哪些仍然是定制化权限清理？
• 如果 Microsoft 在未来 12 个月补强原生跨应用归因，产品还剩下多大差异化？
• 对买方来说，最容易直接扩展的是哪家现有厂商，而不是再引入新供应商？

模型合理性

• 收入引擎. 基础情景收入由 Q4Y3 的 16 家受监管企业付费账户驱动；随着付费试点转化，以及老客户叠加更多受治理工作流和留存模块，blended annual ARPU 到 Y3 做到 $330K。
• 必须跑对什么. 公司必须证明：审批包能把 rollout signoff 明显压短，这样在 Y2 期间，即便不太早扩销售，也能靠伙伴引来的账户持续做到每季度至少净增 1 个付费 logo。
• 模型会在哪坏掉. 如果销售周期拖向 9 个月，或 ARPU 卡在 $280K 左右，下行情景会在公司形成可复制生产首单前先把现金打穿。
• 下一轮融资凭证. 只要公司在 Y2 结束时做到 9 个付费账户、2+ 个有伙伴背书的生产胜利案例，并明确证明这个切口能支撑 $250K+ 首单而不滑成服务型业务，就足以支持下一轮融资。

情景

敏感性

flowchart LR
  Leads --> PaidPilots
  PaidPilots --> ProductionAccounts
  ProductionAccounts --> WorkflowExpansion
  WorkflowExpansion --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

警示项: 模型假设：重 Microsoft 与 ServiceNow 的 rollout review 足够紧迫，因此即便赛道尚未完全成熟，净新增 logo 也能持续走高。 · ARPU 依赖于把付费价值验证转成 $250K-$400K 年订阅，再叠加第二条工作流或留存 upsell；如果扩张更弱，Y3 收入会明显下修。 · 模型把现金直接近似成 EBITDA，没有建营运资金时点、capex 或融资延迟；现实里若回款偏慢或 seed close 更晚，跑道会比基础情景更紧。

• 平台依赖. Microsoft 或 ServiceNow 可能补齐原生归因能力，削弱第三方信任层的必要性。 缓解措施: 先从原生日志做不到统一的跨系统证据、权限链分析和修复工作流切进去，再尽快建立深生态合作。
• 现有厂商挤压. Cyera、Varonis 或其他 DSPM 厂商可能很快补到 agent 归因，把赛道挤满。 缓解措施: 先赢下狭窄的 rollout 审批切口，在重 Microsoft 的环境里更快交付，并在赛道变宽前先占住 agent 专属证据系统的位置。
• 扩容闸门之外紧迫感不够. 如果潜在客户还停在小规模试点，问题未必痛到现在就买。 缓解措施: 只卖给正处在扩容、审计或事故复盘触发点上的客户，因为这些场景里审批延迟已经有明确负责人和可见成本。