近日，RSA Conference 正式公布 RSAC 2026 创新沙盒竞赛的10名决赛入围者，分别为 Charm Security、Clearly AI,Inc.、Crashoverride、Fig Security、Geordie AI、Glide Identity、Humanix、Realm Labs、Token Security、ZeroPath。聚焦网络安全新热点，洞悉安全发展新趋势。与绿盟君一道，走进——Token Security。
Token Security[1]（见图1）是一家聚焦Agentic AI（智能体化人工智能）与非人类身份（Non‑Human Identities, NHI）安全的网络安全公司，致力于打造让Agentic AI能够安全落地的“身份层”。随着AI智能体从助手演进为可独立执行任务的行动者，Token Security提供覆盖身份生命周期管理与基于意图的访问管理能力，帮助企业在获得完整可见性、治理与控制的同时，加速AI应用规模化并降低身份与权限风险。
Token Security成立于2023年，联合创始人有两位（见图2），Itamar Apelblat（左）、Ido Shlomo（右）：
Itamar Apelblat是Token Security的联合创始人兼首席执行官，在网络安全领域拥有超过15年的技术积淀与领导经验。他曾在以色列精英部队8200部队担任军官及研发团队负责人，主导多个先进网络安全项目[2]。Ido Shlomo是Token Security的联合创始人兼首席技术官，他在以色列精英网络情报单位8200部队服役期间积累的深厚经验，Ido Shlomo 将进攻与防御领域的独特专长融入企业安全的最前沿[3]。
NHI 让传统应用与 AI 应用、各类服务及自动化流程，能够在产品与 IT 环境内部以及与第三方之间，完成身份验证、安全通信与操作执行。NHI包括服务账户、API密钥、云角色、容器工作负载、CI/CD流水线以及机器生成的凭证，这些要素有助于实现对系统和数据的安全访问（见图3）。作为数字化转型的一部分，组织持续采用云技术、自动化和人工智能驱动的基础设施。因此，NHI呈现指数级增长，在数量上远超人类身份[4]。
更关键的变化来自生成式AI在企业内的落地。AI Agent 表面上是助手、工具，但在组织内部要完成检索数据、调用SaaS、执行工单、触达生产资源等动作，往往必须借助Token、集成账号或服务账号来获得权限。因此，AI Agent 更像一种“混合身份主体”：既具备一定的自主决策与自动执行能力，又通过程序化凭证继承并放大既有权限。一旦缺少清晰的身份边界、责任与权限围栏，AI Agent 不仅会放大原本就复杂的NHI风险，还会因为渗透进更多业务流程而让风险扩散得更快、更难追溯。具体体现在以下几个方面：（1）身份主体扩张风险：从Human到NHI
- 关键操作越来越多由服务、脚本、流水线与系统集成完成，而非人类直接登录完成。
- AI Agent 的引入使“自动化执行者”从固定脚本升级为更动态的代理；但权限载体仍是 Token/服务账号，导致身份边界更模糊、授权更难约束。
（2）规模与生命周期风险：数量爆炸导致清查失效
- NHI 的数量往往远超人类账号，且包含大量短生命周期、按任务临时生成的凭证与身份。
- 创建入口高度分散（开发、平台、数据、业务集成各自生成凭证），登记不全、更新不及时，盘点很快失真。
（3）可见性缺失风险：看不见就谈不上控制
- 许多 NHI/Agent 不会完整出现在传统IAM清单里，线索分散在密钥库、代码仓库、CI/CD 配置、云与 SaaS 审计日志、运行时遥测，以及第三方/AI 提供商调用记录中。
- 结果是组织难以回答最基础的问题：到底有哪些Token/Agent在使用、在哪里用、在访问什么资源。
（4）上下文与责任断裂风险：发现了也理不清、追不了责
- 即便发现了Token/服务账号，也常缺少关键上下文：属于哪个应用/工作负载、实际使用频率与行为、关联哪些资源与权限、对应的责任人是谁。
- 在 AI Agent 场景中，问题更尖锐：它代表谁行动、以谁的权限访问、出了问题谁负责，缺乏可执行的归因与责任机制。
（5）治理落地阻力风险：管不动会催生更隐蔽的绕行
- 风险形态趋于常态化：过度授权、共享凭证、硬编码密钥、跨环境访问、离职残留集成、孤儿身份长期存在。
- “一刀切禁用AI/自动化”通常不可行：业务会通过Shadow IT / Shadow AI 绕开控制，反而让风险更隐蔽、更难监管。
Token Security以 NHI治理为主线，把企业中分散在云、SaaS、CI/CD、Vault、IdP/SSO 以及 GenAI 相关环境里的身份与凭证统一纳管，并延伸覆盖 AI Agent 与 MCP Server 等新型自动化主体。Token Security通过日志接入与 API 形成统一Agent/MCP与NHI视图，再利用算法对身份、权限与使用关系进行关联分析与风险排序，最后把发现的问题通过工单/流程/集成能力推动整改落地[5]（见图4）。
图4 Token Security NHI治理方案
整体采用“多源接入 → 实时库存 → 风险引擎 → 风险图谱”的分层设计[6]（见图5）：底层广泛接入企业技术栈信号，中间形成可持续更新的 NHI 资产视图，上层把权限与依赖关系转化为可计算、可解释的风险与治理优先级。数据源接入层：连接 Cloud、CI/CD、IAM、GenAI、数据库、On-Prem、Vault/Secrets、SaaS 等域，持续采集 NHI 对象、凭据形态、权限配置与使用线索，为跨系统关联提供原始事实。实时上下文化 NHI 库存层：将多源信号汇聚、去重与统一建模，生成实时 NHI 清单，并为每个 NHI 补齐上下文，作为后续风险计算的底座。
NHI 风险引擎层：在库存之上计算与排序风险，聚焦过度授权、长期有效凭据、影子/未联邦账号、第三方连接暴露、敏感系统访问路径等，输出可执行的优先级与证据链，支持按风险推进治理。
NHI 风险图谱层：以图谱方式呈现“NHI—权限—资源—依赖/调用链”的关系，把点状发现提升为路径级洞察，便于定位风险来源与最短修复路径（收敛权限、替换凭据、断开高风险链路等）。
Token Security能够持续发现企业环境中的Agent、MCP Server，并同步盘点其实际使用的NHI。其次，Token Security通过对归属、访问链路、权限与凭据等统一建模，形成可解释的上下文风险评估，用于定位过度授权、闲置权限、影子资产与意图偏离；通过意图驱动的权限控制，结合策略与持续合规审计，联动权限撤权、轮换与隔离等处置，确保整改可执行、可验证、可追溯[7]（见图6）。
（1）持续发现：Agent/MCP 资产与 NHI 依赖的持续盘点Token Security能够发现 Agent/MCP 资产间的关系，并把其配置中的鉴权材料（API key、Token、OAuth 等）抽取为 NHI，再与人类身份进行关联，最终落到可执行的库存与风险图谱。
- 端点侧（MCP / Claude Code / IDE）：通过“EDR 日志定位连接关系 + 远程取配置”做取证解析。Token Security 深度集成终端与身份生态（如 CrowdStrike），能够持续扫描环境并做取证分析。具体来说，Token Security能够通过 CrowdStrike 日志，分析 IDE 与 Claude Code 实例信息，并定位这些进程在和哪些 MCP 通信，实现MCP盘点。另外，当环境里出现新的 MCP，Token Security基于也几乎能够做到接近实时的发现与盘点[8]（见图7）。
图7 基于CrowdStrike日志的MCP服务盘点
平台侧（Custom GPT / 托管型 Agent）：Token Security 开源了一款GPT合规审查命令行工具—— GPTs-Compliance-Insight[9]。该工具利用 OpenAI 的合规 API，能自动生成关于 GPT 配置、共享用户以及关联文件的清晰、简洁且结构化的报告，从而实现高效的审计与风险评估（见图8）。需要注意的是，GCI需要使用具备合规 API 访问权限的 OpenAI 企业版账户，标准版 OpenAI 账户无法使用该 API。
（2）风险识别：面向 Agent/MCP 的“上下文风险评分”与归因Token Security 能够通过 CrowdStrike RTR （Real Time Response）远程拉取claude_desktop_config.json、 mcp.json 等配置（见图9），形成“日志发现→配置取证→解析分析”的证据链。
图9 Agent/MCP 配置文件中硬编码的凭证信息
上下文建模的数据结构： Token Security会对 MCP Server 基于认证方式进行分类，输出运行位置、连接方式、可访问系统/数据等的上下文信息。并通过风险图谱表达“它连到哪、权限触达面多大”，把评分对象从某个 MCP Server具体到“某端点上的某实例→某系统”的边与节点。过度授权/闲置权限：Token Security通过对“静态权限配置”与“运行时”进行交叉关联分析，得到授权缺口，（如“90天只读但仍保留写权限”），进而移除过度授权与闲置权限（见图10）。
图10 MCP/Agent访问权限分析
归因链路：Token Security提出用“Chain Of Custody Logs”方法，把每个产物（Artifact）和每次关键动作的“来龙去脉”记录成可追溯、可问责、可复盘的时间线：谁在什么时间、以什么输入/上下文、调用了什么工具/权限、对哪个资源做了什么操作、产生了什么输出，并能一路追到人类身份（见图11）。
图11 MCP/Agent 归因链路分析
（3）响应治理：意图驱动最小权限+策略化合规+自动化修复闭环在Token Security的治理链路中，“响应”不是在发现风险后发工单，而是把身份与权限做成可运行的控制面。Token Security能够对每次Agent/MCP触发访问结合上下文与风险阈值做决策，并把决策结果（放行、降权、撤销、修复）回写到权限与配置源头，形成闭环。意图驱动最小权限：治理点放在“动作发生的当下”。系统将 Agent 的意图与当前风险上下文一起用于授权判断，避免“上线时一次性授予、之后不再复核”的静态授权模型；当风险上升或行为偏离时，控制面需要具备“自动收缩权限”的能力，而不仅仅是扩权。
策略化合规：把合规要求落实为可执行策略，并通过不可篡改的审计日志记录“身份相关事件与审批链”，将跨账户/跨系统的权限生命周期汇聚为可检索证据，支撑事后追溯与持续合规校验。
自动化修复闭环：当风险超过阈值，系统可自动把告警路由给责任人并附带可执行修复指令，生成处置步骤，把修复从“建议”推进到“可落地变更”（见图12）。
图 12 NHI 安全治理与响应修复
Token Security 围绕 AI Agent 与 MCP Server 等新型自动化主体场景下的 NHI治理，构建“发现—治理—检测响应”的端到端闭环的产品解决方案：Agent/MCP 一体化纳管对象：在传统 NHI（key/secret/service account）之外，覆盖 AI Agent、MCP Server、Tools/Actions 的发现与盘点，建立统一关系链路与可见性。面向调用链的治理落地：以调用依赖为上下文做最小权限收敛、配置基线与漂移治理，并将归属、轮换/短期化、闲置回收等生命周期动作落实到具体 Agent/MCP 资产与变更流程。
检测响应更贴近 Agent 行为语义：结合运行态信号对 Tool 调用与跨系统访问做异常检测与风险排序，支持一键联动，对接工单、SOAR等自动化修复，形成闭环并可验证整改效果。
在云安全治理里，CSPM主要解决“云资源是否按最佳实践/合规基线配置”，CIEM主要解决“云上身份与权限是否过度、是否满足最小权限”。但当企业引入 AI agent / MCP 这类“自动化执行者”后，风险往往不再只来自云资源误配或 IAM 角色设计，而是来自凭证/Token 的分发与使用、非人身份的权限边界以及跨 Agent 的调用链路是否可追溯、可约束。Token Security 更像是围绕“Agent/MCP—NHI”的访问面治理与审计溯源，与 CSPM、CIEM 形成互补（见表1）。
表1 Token Security方案与CSPM、CIEM方案对比
总体来看，Token Security更像是一套Agentic AI时代下，面向NHI的身份安全治理与检测响应平台。它把关注点从传统的“人如何登录与鉴权”，转向“Agent/MCP如何获得访问能力、实际访问了什么、风险暴露在哪里，以及如何以工程化方式可控修复”。从产品能力结构上，它的路线清晰地遵循“三步走”：第一步解决“看见”——通过持续发现与盘点，将Agent/MCP及其可调用的NHI 资产化、可追踪，明确它们的分布、用途与使用场景；第二步解决“看懂”——用Identity Graph把“身份—凭证—权限—资源—依赖—归属—行为”串成证据链，输出可解释的影响面，让风险不再停留在清单层面；第三步解决“改掉并持续防”——把风险项转化为可执行的治理任务，并以运行时检测与响应缩短攻击窗口，将事件结论反向喂给治理策略，形成持续收敛的闭环。
