面向自主编程智能体的身份与吊销控制平面，覆盖 GitHub、云环境及 SaaS 工具。

1. 自主智能体正从只读助手转向触及代码、API、金融工具和客户数据的写入行动者。
2. 企业需要控制层，因为身份、权限范围、凭证认证、委托授权和吊销已成为独立的运营问题。
3. 安全团队不能再把智能体风险视为普通 AppSec 问题——针对智能体专项漏洞的零日跟踪已经在打包交付。
4. 开放 Agent Trust Protocol 和验证计划的出现，标志着一个标准化窗口——控制平面厂商有机会成为默认实现。

催化因素。 智能体专项漏洞跟踪和开放信任协议，正好在智能体获得代码、API、金融工具和客户数据访问权的同一时刻 涌现。安全团队迫切需要一种标准化的方式来验证和吊销非人行动者。

产品嵌入在智能体运行时与高风险工具之间，在任何写入操作执行前为每项智能体任务建立可验证的身份。它将 每一次操作绑定到委托链、策略范围、人类负责人和吊销状态，并生成安全团队无需手工拼接日志即可审查的 审计轨迹。系统将已披露的智能体漏洞映射到受影响的身份、模型、工具和工作流，使暴露的智能体能够被自动 降级、暂停或重新限权。首批集成将优先覆盖 GitHub、AWS、Okta、Jira、Slack 和内部智能体编排器—— 因为早期具有写入能力的智能体在这些位置造成的风险最为尖锐。

差异化。 现有的 IAM、PAM 和密钥管理工具是为人类、服务账号和静态工作负载设计的，不适用于在单个工作流中跨多 个工具委托任务的自主行动者。智能体可观测性产品告诉团队事后发生了什么，而本产品控制的是智能体是否应当 被信任去执行——并能在漏洞条件变化时实时吊销该信任。可防御的切口是三者的组合：智能体原生凭证认证、 漏洞感知吊销，以及深度集成到早期智能体部署风险最集中的写入面。

待完成任务

flowchart LR
  Buyer[安全与平台工程团队] --> Pain[无法验证的智能体操作与缓慢的吊销流程]
  Pain --> Product[智能体凭证认证与委托授权平面]
  Product --> Outcome[更快落地智能体，同时具备可审计的最小权限]

高管要点

• 切口是真实的——具有写入权限的编程和 IT 智能体正在进入生产环境，而企业尚未建立专为智能体设计的身份、委托授权和吊销层。
• 近期市场位于非人身份安全、工作负载身份联邦和 AI 智能体治理三者的交叉地带；品类尚早但已足够拥挤，必须聚焦 GitHub-云-SaaS 写入路径才能突围。
• 买家痛点在密钥扩散、NHI 过度授权和治理盲区上清晰可见：GitGuardian、Entro 和 Veza 各自证明，机器凭据的增生速度已超过团队盘点或轮换的能力。
• 现有厂商已占据相邻管控，初创公司唯有在目标工具上以最快的速度落地任务级凭证认证、委托令牌和漏洞感知吊销，才能赢得市场。

市场定义

智能体信任控制平面软件：在非人行动者执行写入操作前完成验证、跨开发者和管理工具签发任务级委托访问，并在漏洞条件或工作流上下文变化时撤销或重新限权。

用户与买方

主要用户是运行具有 GitHub、云、工单和聊天访问权限的内部编程或 IT 智能体的安全工程师和平台工程师。经济买家通常是首席信息安全官 (CISO) 或平台工程副总裁，因为采购预算横跨身份、AppSec 和开发平台三个口子。

购买触发点

• 团队为仓库或云写入权限启用了异步编程智能体或自动化机器人，立即就需要围绕该上线的人工审批、分支保护和令牌范围护栏。 [30][40]
• 密钥或流水线事件暴露了静态凭据在 runner、机器人或 MCP 风格集成上的风险——一个小范围泄漏足以演变为大规模基础设施入侵。 [115][13][97]
• 身份扩散审查揭示非人身份数量已大幅超过人类账户，而归属人、权限和休眠状态的治理极为薄弱。 [27][111]

支付意愿

当控制平面被定位为扩展智能体开发的前提条件时，预算应当存在：GitHub 已在高级 Copilot 计划中将智能体功能货币化，而 Teleport、Okta 等相邻身份平台则在核心基础设施之上销售经常性访问治理层。合理的付费意愿代理是现有 AI 编程或身份堆栈预算的一部分，而非全新独立的预算线项。 [29][108]

品类动态

增长信号 13.1% CAGR for machine identity management (2025-2033)

验证信号

• GitHub 已推出异步编程智能体，配备明确的人工审批、分支保护和会话日志——证明具有写入权限的智能体工作流已足够主流，需要相应管控。
• GitGuardian 发现 2025 年 GitHub 公开仓库中新增 2865 万个硬编码密钥，并在 MCP 相关配置文件中记录到 24,008 个唯一密钥——展示了智能体时代密钥扩散的速度。
• Entro 和 Veza 的数据均显示 NHI 数量已大幅超过人类账户并集中了高风险权限，支持"非托管非人访问已是企业级问题"的论点。
• Oasis 和 Astrix 围绕 NHI 和 AI 时代身份安全完成大额融资，而 Lyrie 正在明确宣传 Agent Trust Protocol——表明一场真实的但仍在成形中的品类之争正在展开。

监管与技术约束

• MCP 授权是可选且依赖传输层的，买家将面临跨智能体工具不一致的认证模式，除非有中间件统一规范。
• GitHub、AWS、Azure、GCP 和 Vault 都以短期凭证为核心，这意味着产品必须在签发、续期和吊销令牌时高度可靠，不能引入工作流中断。
• 最小权限、提示注入防御和可审计性已是主流 AI 安全框架的核心治理要求。
• SaaS/API 生态暴露了异构的令牌、权限范围和服务账号模型，因此集成广度是技术护城河，同时也是交付负担。

竞争不是一个扁平列表。Aembit 和 Teleport 从工作负载身份和无密钥访问切入，Astrix 和 Oasis 从 NHI 发现/治理切入并向智能体安全靠拢，CyberArk 带来现有厂商的机器身份广度。初创公司唯有拥有具有写入权限的智能体跨工具委托图谱——尤其是 GitHub、云 IAM、Jira/Slack 管理操作和漏洞感知吊销——而不是成为通用 NHI 仪表盘，才能获胜。

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

• 云平台. AWS、Azure 和 Google 已能签发短期工作负载凭证，但它们止步于各自的信任域，无法统一 GitHub-到-云-到-SaaS 的委托链，也不提供跨混合工具链的智能体专项吊销。
• 开发平台. GitHub 可以用分支保护、人工审批和内置验证来保护自己的编程智能体，但跨工具身份、SaaS 管理访问和披露后吊销仍在 GitHub 原生工作流之外。
• IAM/PAM 套件. Okta 和 CyberArk 已销售宽泛的身份控制平面，但其经济重心在劳动力身份、密钥和特权访问上，而非面向在多个服务间自主行动的智能体的任务级委托权限。
• 工作负载身份厂商. Teleport 和 Aembit 证明了买家会采用短期工作负载身份，但它们的核心价值是无密钥访问和 SPIFFE/OIDC 风格的联邦；没有任何一家是编程智能体漏洞情报和委托历史的默认层。

企业正将具有写入权限的编程和 IT 智能体接入 GitHub、云 IAM、Jira、Slack 和财务系统，却仍像管理 长期有效的服务账号那样为其配置凭据——没有任务级委托、没有可验证的凭证认证链、没有漏洞出现时的快速 吊销路径。本产品是一个专为智能体身份设计的中间件，嵌入在智能体运行时与高风险写入面之间，签发短期 任务凭证、执行策略绑定的委托授权，并在漏洞条件或工作流上下文变化时自动触发吊销。滩头市场是已有 100–1,000 名工程师、运行具有 GitHub 和云写入权限的内部编程或 IT 自动化智能体的 B 轮至 E 轮软件 公司；安全审查或漏洞披露是最直接的购买触发器。SAM 估算为 $300M（5,000 个符合条件的账户 × 约 $60k ACV），第三年可触达市场约为 $6M（80 家共创客户 × 约 $75k ACV）；研究阶段无独立客户案例 可参考，这些估算均为需通过共创客户试点验证的自下而上推算。

问题

• 自主编程和 IT 智能体获得了对 GitHub、云控制台、Jira、Slack 和 SaaS 管理工具的写入访问权，却以共享长期有效的服务账号形式配置——没有可验证的委托链。
• 安全团队无法证明是哪个智能体执行了操作、哪个人批准了委托、当时生效的权限范围是什么——审计、合规和事件响应全靠手工，既慢又容易出错。
• 当智能体专项漏洞被披露时，唯一的封控手段是全面停机，因为根本没有精细化吊销的控制平面。
• 现有 IAM、PAM 和密钥管理工具是为人类和静态工作负载设计的，既无法建模任务级凭证认证，也不支持自主委托图谱或针对智能体的漏洞感知吊销。

解决方案

• 一个智能体身份中间件：拦截每一次具有写入权限的智能体操作，签发将该操作绑定到委托链、策略范围和人类负责人的短期任务凭证，然后放行或阻断执行。
• 漏洞感知吊销：系统将已披露的智能体漏洞（MCP 配置错误、密钥泄漏、运行时缺陷）映射到活跃身份，自动降级、暂停或重新限权受影响的智能体。
• 无需手工拼日志即可按操作生成审计轨迹——可对接 SIEM，涵盖智能体身份、工具、操作、结果和吊销状态。
• 首批集成覆盖 GitHub、AWS IAM、Okta、Jira、Slack 和常见智能体编排器；基于 OIDC/SPIFFE/工作负载联邦等现有基础设施原语构建，而非自研运行时。

为什么我们会赢

• 现有厂商（Okta、CyberArk、Teleport、Aembit）只能在各自的信任域或宽泛的工作负载身份范围内停步——没有任何一家能提供统一的跨 GitHub-云-SaaS 委托图谱，加上针对编程智能体的漏洞感知吊销。
• 态势类厂商（Astrix、Oasis）提供资产清点和发现能力；本产品在写入操作发生的瞬间实施内联执行——这是唯一能阻止而非仅报告未授权智能体行为的管控手段。
• 委托图谱（人类负责人 → 智能体运行时 → 仓库/任务 → 已签发令牌 → 下游操作 → 吊销结果）随每个集成工作流不断增值，替换成本随之递增，形成数据护城河。
• 标准友好架构（OAuth/OIDC、SPIFFE、MCP 授权）避免了专有运行时锁定，降低了买家对架构死胡同的顾虑。
• 早期共创客户聚焦 GitHub 到云的写入路径，在现有厂商以同等深度跟进之前，先交付可量化的价值证明（上线审批耗时和吊销耗时指标）。

里程碑

flowchart LR
  Beachhead["B 轮至 E 轮编程智能体团队\n（GitHub + 云写入权限）"] --> Pilot["共创客户试点\n（GitHub 到 AWS 凭证认证 + 吊销）"]
  Pilot --> Proof["价值证明\n（上线审批耗时、吊销耗时）"]
  Proof --> Expand["集成扩展\n（Okta、Jira、Slack、GCP）"]
  Expand --> Graph["委托图谱护城河\n（跨工具身份数据集）"]
  Graph --> Platform["信任平台\n（财务、HR、合作伙伴智能体）"]

创始团队

实验路线图

风险评估

必须成立的条件

• 2026 年，具有写入权限的编程和 IT 智能体已在足够多的 B 轮至 E 轮软件公司的生产环境中运行，足以产生对内联身份管控的主动预算——而不只是认知层面的关注。
• 安全和平台工程团队会为第三方中间件付费，而不是扩展现有 IAM/PAM 或等待云原生捆绑——因为集成广度和漏洞感知吊销不在任何厂商的 12–18 个月路线图上。
• 委托图谱和漏洞-身份数据集随使用时间复利式地形成切换成本，使单厂商捆绑式替代在 12–18 个月生产使用后在经济上不再具有吸引力。
• 吊销耗时可以从数小时/数天（电子表格加全局熔断）压缩到 30 分钟以内，且客户会将这一指标视为 RFP 资格标准。
• 公司能在产品上线 12 个月内以直接外呼方式签下 5+ 家付费共创客户——在需要规模化销售团队之前完成。

待尽调问题

• 你们是否已与 10+ 位 B 轮至 E 轮软件公司的平台安全负责人沟通，确认 2026 年有独立于现有 IAM/PAM 支出的智能体身份管控预算？
• 在竞争评估中，对阵 Aembit、Oasis 和 Astrix 的胜负比例如何？各结果背后的核心决策标准是什么？
• 买家更倾向于内联令牌中间件，还是先从态势/发现层开始？这一偏好如何影响成交周期和初始 ACV？
• GitHub 到 AWS 委托路径今天的技术成熟度如何：演示可用、试点可用，还是生产就绪？各阶段之间差多少工程月？
• 漏洞-身份映射数据集是否已生成任何客户可证明的、优于基础 vault 或 PAM 工作流的更快分类或吊销案例？
• 创始团队在身份、安全基础设施或企业 SaaS 方面的既往经验如何？这对第一年内拿下 CISO 级别合同的能力有何影响？

模型合理性

• 收入引擎. 基准情景收入由 Y2 第四季度达到 20 家生产客户、Y3 第四季度以约 $75K ACV 扩展到 80 家客户驱动。
• 必须走对的事. GitHub 到 AWS 切口必须在第二位客户主管及后续招聘全面拉高 P&L 之前，将共创客户转化为年度合同。
• 模型崩塌临界点. 如果销售周期延长到 9 个月，或成熟期 ACV 停滞在约 $65K，下行情景现金在公司建立强势下轮融资叙事之前会转为负值。
• 下轮融资证明点. 下轮融资的核心证明是：20 家生产客户、约 $1.2M ARR 跑率，以及已上线的漏洞感知吊销——证明产品不只是试点工具。

情景

敏感性

flowchart LR
  Leads["目标客户"] --> Pilots["付费试点"]
  Pilots --> Customers["生产客户"]
  Customers --> Expansion["更多身份 + 集成"]
  Customers --> Revenue["订阅收入"]
  Expansion --> Revenue
  Revenue --> GrossProfit["毛利润"]
  GrossProfit --> Cash["现金 / 资金跑道"]

警示项: 从 Y2 第四季度 20 家客户跳升到 Y3 第四季度 80 家，需要比模型目前证明的更具可重复性的销售动作。 · 毛利率改善依赖于在扩大连接器广度的同时减少高触达集成和 onboarding 的人工工作量。 · 在 Y2 年度收入超过 $1M 之前，Rule of 40 不是有效的质量信号。 · 基准情景现金始终不为负，是因为假设种子轮在模型起点完成交割；任何融资延迟都会实质性地压缩资金跑道。

• 协议碎片化. 多种智能体框架和信任标准可能并行涌现，让单一控制平面接口难以通用化。 缓解措施: 早期支持多个运行时，并将产品锚定在策略执行和吊销结果上，而不是依附某一特定协议。
• 现有厂商扩张. 大型 IAM、PAM 或云安全厂商可能将现有产品延伸到智能体身份领域，压缩切入点空间。 缓解措施: 凭借更快的集成、更丰富的委托上下文和漏洞感知管控，率先拿下最早的具有写入权限的编程智能体工作流——这些是现有厂商尚未具备的能力。
• 市场时机. 部分企业可能仍处于智能体试点阶段，推迟预算投入，直到具有写入能力的部署成为普遍现象。 缓解措施: 瞄准已在生产环境运行内部编程或 IT 智能体的共创客户，将产品定位为扫清安全审批障碍的加速器。