上周帮一家 SaaS 客户做安全盘点我在生产环境里数出了 4,800 多个数字身份——API 密钥、服务账号、机器人凭证、CI/CD 令牌、云服务角色而这家公司的人类员工只有 300 人。最吓人的是其中 200 多个身份拥有管理员权限包括一个负责自动回复客服邮件的 AI Agent正用根账号访问生产数据库。这不是孤例而是 AI Agent 大规模落地后每家企业的必经之路当 AI 也开始“上岗”企业首先要解决的不是让 AI 做什么而是怎么给这些“非人类员工”发身份证、管好它们的权限。这篇文章我想聊聊非人类身份Non-Human IdentityNHI管理这件事。不管你是运维、安全工程师、平台开发还是技术管理者只要你的公司开始用 AI Agent、RPA 机器人、自动化流水线就一定绕不开这个问题。下面会从 NHI 的定义、与传统身份管理的差异、核心治理方法、真实事故复盘到落地路线图全部展开来讲。1. 先看清战场企业里到底有多少“非人类员工”在干活1.1 非人类身份到底指什么很多人一听“非人类身份”就以为只有 AI 机器人其实 NHI 的范围宽得多。只要不是以人类个体为载体、却在系统里拥有访问权限的凭证都算非人类身份。我列一下最常见的几类API 密钥和访问令牌程序调用接口时用的 key、token服务账号微服务、后端进程、数据库应用账号机器人账号RPA 流程机器人、客服 Chatbot、AI Agent 的专属账号云服务角色比如 AWS IAM Role、临时安全凭证CI/CD 流水线凭证构建、部署、发布流程里用的部署密钥证书mTLS 双向认证证书、代码签名证书。以前这些身份零零散散分布在各个系统里运维心里大概有数。但现在情况变了因为 AI Agent 的部署速度实在太快——上个季度客户公司里只有 10 个 Agent这个季度可能就变成 100 个。每个 Agent 为了干活都要去读知识库、调内部 API、访问数据库、操作云资源这就意味着每一个 Agent 都要分配身份凭证。NHI 数量的增长速度已经不是线性增长而是指数级的。1.2 为什么说 AI Agent 把 NHI 数量推向失控传统 IT 时代一个企业的 NHI 数量通常是员工数的 2 到 5 倍。到了 DevOps 普及之后这个比例能到 10 倍。而现在的 AI Agent 时代我见过不少企业NHI 数量已经是人类员工数的 50 倍以上。原因其实很好理解。以前一个服务账号可能对应一套后端系统系统上线之后就稳定了。但 AI Agent 不一样它天生就是“动态工作负载”——一个 Agent 可能被拆成规划、调用工具、总结输出多个环节每个环节都可能有独立的身份一个 Agent 要对接多种工具每种工具都有自己的凭证Agent 版本升级、实验性跑批任务、临时数据分析任务又会创建新的临时身份。我记得有一次陪客户排查问题发现他们给一个 AI 数据分析助手分配了数据库的普通账号结果 Agent 内部为了实现“自主规划”自己去申请了更高权限的凭证。也就是说AI Agent 不仅自己占用身份它还会自己“申请身份”这让传统的静态身份管理完全招架不住。1.3 一个最简单的存量盘点方法很多团队会说“我们也不知道自己有多少 NHI”这个说法我很理解因为 NHI 不像人类员工有 HR 系统记录它们散落在代码仓库、配置文件、云平台、CI 工具、容器平台里。但盘点其实有办法不需要什么都做先跑一遍基础扫描在云平台控制台导出所有 IAM 用户、角色、服务账号列表用 secret scanning 工具比如 trufflehog、gitleaks扫描代码仓库里的密钥和令牌检查 CI/CD 系统里配置的部署凭证和凭据库梳理数据库、内部系统里的应用账号和机器人账号把这些信息统一拉到一个表格里按系统、权限、负责人、最后使用时间归档。我第一次帮客户做盘点的时候光是整理清单就花了两天但做完之后所有人都沉默了——没人想到“看不见的员工”有这么多。所以如果你还没盘点过建议立刻做一次先知道敌情后面的一切治理才有基础。2. 给 AI 发“身份证”之前先理解 NHI 与人类身份的三个本质差异2.1 信任模型不同人可以被教育NHI 只能被约束管理人类员工的时候我们依赖一套软性的信任体系入职签保密协议、定期做安全培训、离职做访谈、出了问题可以追究责任。你可以“信任”一个有经验的员工让他根据具体情况做判断。但 NHI 本质上就是一段代码、一个自动化流程它没有道德观念也不会因为公司制度而自我约束。它只能按照你给它的权限边界行动——给多少权限就能做到什么程度。这就意味着面对 AI Agent绝对不能沿用“先给足权限、后续再收紧”的思路。我之前见过一个团队为了让 Agent 尽快跑通业务流程直接把服务器上常用的管理权限全给了服务账号结果 Agent 在自主处理任务时不仅读了该读的数据还扫描了整个对象存储桶把所有 bucket 列表拉了一遍。它没有恶意但它没有“分寸感”。所以 NHI 的管理逻辑必须是默认拒绝显式授权权限边界越小越好。2.2 凭证生命周期不同密码能改硬编码的密钥没人管人类员工有明确的生命周期入职、在职、转岗、离职。每个环节都有对应的账号处理流程HR 系统会同步状态。但 NHI 的凭证生命周期几乎没人管。尤其是硬编码在代码里的 API 密钥只要代码没改、服务没重启这个密钥就是“永久有效”的。更麻烦的是人类密码被盗了用户可以改密码但一个 API 密钥要是被硬编码在 5 个微服务里你想轮换就得先改代码、发版本、重新部署这在很多团队里是一件“想起来就头疼”的事。于是大家选择不动密钥一用就是几年甚至项目都下线了密钥还挂在共享账号里。NHI 的凭证轮换不是技术问题是流程和管理意愿问题。2.3 行为特征不同人类和 Agent 的操作模式是两套逻辑安全监控团队习惯用“用户行为分析”来发现异常某个员工半夜登录了、下载了大量数据、访问了从不涉及的目录这些都是危险信号。但 Agent 的行为模式完全不同——它是 7x24 小时工作的凌晨 3 点调接口可能完全正常它每秒可能调用上百次 API这种高频次在人类员工身上绝不可能出现它还会并行访问很多系统因为一个 Agent 任务可能需要同时查询数据库、调搜索引擎、读文件存储。所以如果用检测人类异常的那套基线来套 AI Agent结果就是两个极端要么天天误报把 Agent 的正常工作当成攻击要么阈值放得太宽真的有问题也发现不了。NHI 的行为监控必须单独建立基线基于“这个 Agent 平时调用哪些 API、频率多高、什么时间段活跃”来学习。我用一张表把人类身份HMI和非人类身份NHI的核心差异做个对比帮助大家建立直观印象对比维度人类身份HMI非人类身份NHI数量级有限几百到几万通常是 HMI 的 10 倍以上载体用户名/密码、MFA 设备API 密钥、服务账号、角色、证书生命周期入职到离职流程清晰经常被遗忘无自动吊销信任模型可培训、可追责、可软性管理只能靠权限边界和策略硬约束行为特征有作息规律、节奏相对固定7x24 活跃、高并发、高频调用异常检测基于人类行为基线需要单独的 Agent 行为基线失陷影响单人单账号影响可控凭证可能被多个系统复用爆炸半径大这张表的最后一条是后面事故复盘里最关键的背景。3. 海量 NHI 治理的四个核心战场3.1 身份注册建立每个 Agent 的唯一身份标识管理海量 NHI 的第一步是让每个“非人类员工”都有一个排他的、可识别的数字身份而不是共享同一个 root 账号也不是用某个同事的个人账号挂代理。这个道理和人类员工一模一样——你要是让十个人共用一个门禁卡出了事根本查不到是谁。我在实际项目里推荐的做法是“一 Agent 一身份”。每个 AI Agent 部署的时候都从统一身份源中注册一个 workload identity工作负载身份。在云上对应的是 IAM 角色或服务账号在 Kubernetes 里可以结合 ServiceAccount 与 OIDC 联邦在企业内部系统则创建专用的机器人账号。关键是这个身份必须带上足够的元数据——负责人是谁、属于哪个业务线、运行在什么环境生产/测试/开发、用途是什么。有了唯一身份后面所有权限分配、行为审计、异常定位才有一个可以挂靠的锚点。否则你看到一条日志里某个 Agent 调了数据库却不知道该找谁问“这合规吗”治理就无从谈起。3.2 权限治理最小权限与动态授权身份管好了接下来是权限。我的原则很简单用动态临时凭证代替长期密钥用最小权限代替宽泛授权。长期 API 密钥是最危险的因为只要泄漏一次就等于把钥匙交给了别人而且不会过期。现在云平台都支持短期临时凭证比如 AWS STS、Azure Managed Identity这类凭证默认几十分钟到几小时就过期哪怕在传输过程中被截获攻击者能利用的时间窗口也非常小。我给客户做改造的时候第一步就是把“硬编码的长期 AccessKey”替换为“临时凭证 实例角色”。如果一些老系统没法立刻改成临时凭证那就做权限边界。云平台里的 Permission Boundary 非常适合这种场景你可以在账号级别设置一个最大权限范围就算 Agent 申请的权限再大也突破不了这个边界。很多团队以为配了 IAM 策略就完了其实真正限制爆炸半径的往往是那层 Permission Boundary。下面是一段针对知识库读取场景的最小权限策略示例原则是只允许读取指定桶里的对象不允许列出所有桶更不允许写操作{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ s3:GetObject ], Resource: arn:aws:s3:::internal-knowledge-base/* } ] }很多事故其实是权限太宽造成的不是“身份不足”。所以权限治理的核心动作只有一个思路——把每个 NHI 能碰到的东西缩小到它本职工作真正需要的那一丁点范围。3.3 生命周期管理从创建、轮换到吊销NHI 的生命周期管理是很多企业最薄弱的环节。我总结了三个关键动作创建规范化新 Agent 上线时身份注册、权限申请、审核、记录负责人一步都不能少。别为了赶上线时间跳过审批。轮换自动化所有长期凭证必须有轮换周期比如密钥 90 天强制轮换。轮换一定要自动化靠人工记日历一定不可靠。理想的做法是通过 secrets management 平台统一管理到期自动生成新密钥、自动部署更新。下线即吊销Agent 下线、项目终止、服务废弃的时候对应的身份和权限必须立刻吊销。很多企业出了事故回头看发现攻击者用的是三年前就废弃的服务账号。另外还有一个经常被忽略的点定期清理“僵尸身份”。建议至少每个季度跑一次扫描找出超过 90 天没有使用的 NHI确认后直接禁用。我见过有企业在回收站里挂了几千个“已停用但仍然有效”的 IAM 用户这种身份就像没上锁的窗子不用的时候不觉得一到出事就是入口。3.4 行为审计把每一条调用都变成可追溯记录最后一个核心战场是审计。这里的核心不是“存日志”而是“能追溯”。当发生安全事故时你得能回答三个问题哪个非人类身份做的、访问了什么数据、是谁的负责人。落地的时候要注意几个细节。第一所有 NHI 的调用日志必须集中收集不能散落在各个业务系统里第二日志里要有身份维度——通过 Agent 身份 ID、服务账号名来关联而不是只看 IP第三保留周期要足够长至少满足合规要求通常 180 天以上。有了日志之后再建立行为基线。比如某个客服 Agent 平时每天调用 CRM 系统搜索接口 2000 次某天突然开始从数据库导出大批量数据这就应该触发告警。这个基线需要单独学不能拿人类员工的行为模型去套。我自己在这块有一个经验先把 Agent 的“正常行为”跑两周再去找差异误报率会低很多。4. 三个真实事故复盘NHI 凭证泄漏为什么比员工密码泄漏更致命4.1 AI Agent 的密钥被推进了 GitHub 公开仓库那个 SaaS 客户出过这么一档子事他们的 AI Agent 项目里有一个配置文件里面存着生产数据库的连接串和 API 密钥。结果有开发者在调试的时候不小心把这个文件提交到了 GitHub 公共仓库。没过多久就有扫描机器人在 GitHub 上发现了这个密钥开始尝试连接。最可怕的不是密钥本身而是这个 Agent 的权限非常大——因为最初图省事权限申请直接批准了“数据库读写”。结果攻击者不仅读取了数据还删掉了几张业务表。这个事故的根源有两个一是密钥没有做脱敏和 secret scanning二是 Agent 权限完全违背了最小权限原则。后来我们做了三件事一是开启 GitHub 的 secret scanning 和 push protection密钥一旦出现在代码提交里就直接拦截二是把数据库账号权限从“读写”改成“只读”并且用临时凭证替代长期密钥三是清除了 git 历史里所有包含密钥的提交并且全局轮换了一次受影响的所有密钥。这里我想多说一句很多人觉得“我不把仓库设成公开就没事”完全错误。企业内部仓库的员工都可能不小心把密钥带出去更不用说供应链上其他工具和镜像了。密钥的安全不能靠“别外传”只能靠“即使外传也失效”——这就是短时凭证和权限边界的意义。4.2 服务账号权限过大数据被批量拖走另一个案例是一家金融科技公司。他们的一个 BI 报表 AI Agent 通过服务账号连接数仓为了“方便起见”这个服务账号被加入了管理员组。某次攻击者通过一个不那么重要的前端漏洞进入了内网然后发现这个服务账号可以访问整个数仓。接下来的事情就顺理成章了——攻击者用这个服务账号跑了一系列查询把客户交易数据、个人信息全部拉走。整个数据导出过程中没有任何告警因为安全团队根本没想到有人会用 BI 账号做全量数据导出。事后做复盘的时候我们发现其实这个 Agent 只需要查询最近 7 天的报表数据但它被授予了全表访问权限。当时的修复方案是基于 Agent 实际要跑的 SQL 模式创建了一个专门视图只暴露必须的字段然后给该 Agent 的凭证加上了来源 IP 白名单和调用频率限制。这个事故让我明白一个道理——大数据平台的安全不能只靠边界防护服务账号的权限边界才是最后一条真正的防线。4.3 三年没清理的机器人账号变成“后门”第三个案例更典型。一家做电商的公司开发团队三年前为了做自动化测试创建了一批机器人账号密码写在团队共享文档里。后来项目结束了这些账号既没有被删除也没有被轮换密码。某天攻击者从某个泄漏的员工密码入手横向移动到了内网发现这些共享文档里的机器人账号然后直接通过它们访问了订单数据库。整个过程没有触发任何“用户异常”因为这些机器人账号本来就没有行为基线而且在安全团队眼里它们根本不算是“可登录的人”。后来发现这个问题的契机是某次安全审计中审计员发现订单库的访问日志里有一个“从未见过来源”的账号。我们处理这类问题的标准化动作是立即禁用所有超过 90 天未使用的非人类账号对所有历史凭据做强制轮换建立“机器人账号同样纳入审计和生命周期管理”的制度。遇到这种案例我就感慨很多企业愿意花大钱买各种安全设备却连最基本的“账号清理”都没做到位而 NHI 的僵尸账号比人类员工的僵尸账号危险得多——因为没人关心所以没人管所以变成最好的后门。把三个案例放在一起看其实有一个共同点它们的根本原因都不是“攻击者技术高超”而是“非人类身份的权限过大、生命周期失控、行为无监测”。这也是我在文章开头说 NHI 凭证泄漏比员工密码泄漏更致命的原因——员工密码泄漏影响的是一个人的账号而 NHI 凭证一旦被滥用影响的是整个服务、整个数据域。5. 落地路线图从存量盘点开始建立 NHI 治理体系5.1 第 1 步盘点、分类、打标签如果你现在还不知道自己企业有多少 NHI那就从盘点开始。这一步没有捷径你需要把全公司范围内的密钥、服务账号、机器人账号、云角色全部拉出来。我建议用一个简表记录四个关键字段身份标识、所属系统、权限等级、负责人。分类的时候按两个维度分一是环境生产 / 测试 / 开发二是权限等级管理员 / 普通 / 只读。然后再给每个身份打个标签比如“AI Agent - 客服助手”“RPA - 财务开票”“CI/CD - 生产部署”。标签的意义在于后面做策略的时候可以按类型批量操作而不是一个个处理几百上千个身份。5.2 第 2 步分级分权先解决高风险凭证盘完点之后别指望把所有问题一次性解决那既不现实也容易引发业务反弹。我的建议是聚焦“高风险凭证”——拥有管理员权限的、连接生产数据库的、包含敏感数据的系统关联的 NHI这一类优先处理。处理动作也很明确把长期密钥换成短期凭证把管理员权限降为最小权限给高危服务账号加上权限边界和来源限制。我通常会在这一步设置一个“安全红线”任何非人类身份都不应该同时拥有生产环境的写权限和数据的批量导出权限。5.3 第 3 步建立自动化的生命周期管理人工管理几千个 NHI 是不可能的一定要上自动化。你需要一个统一的 secrets management / 身份管理平台来完成下面这些事集中存储和加密所有密钥令牌自动轮换凭证设置过期时间对接云平台、CI/CD、内部系统的身份源提供审计日志和访问记录。选平台的时候除了看功能我会特别看重两点一是能不能覆盖你们现有的技术栈云计算厂商、K8s、GitLab CI、自研系统二是 API 是否开放方便你们做一些定制化的自动清理脚本。5.4 第 4 步工具选型与技术落地要点现在市面上做 NHI 身份治理的工具大致分三类我按适用场景列出来参考类型代表方向适用场景注意点云平台原生能力云厂商 IAM、角色、托管身份云上资源已较合规的团队只覆盖单云无法统一多云专业 NHI 治理平台专门的 NHI 安全平台、身份安全厂商大规模 Agent、跨云、强合规需求需要预算和实施周期开源密钥管理Vault OIDC 联邦技术实力强、想自主掌控运维成本高需要专门团队我见过一些中小企业一开始就蹦着大而全的商业平台去结果部署了半年还没跑起来。其实如果团队规模不大、云环境比较单一先用云平台原生的能力做一轮梳理和权限收敛也能解决 80% 的问题。等 Agent 数量上去了再迁移到专业平台不迟。另外工具落地时有一个很容易踩的坑只上工具不改流程。哪怕你买了最贵的 NHI 治理平台如果开发流程里还是可以随意创建长期密钥、随意审批权限那系统只是个摆设。技术工具一定得配合开发规范的调整比如代码提交前必须做密钥扫描、权限申请必须走审批流。5.5 第 5 步组织流程与文化配套最后说点虚的但其实最关键——非人类身份治理一定是“技术 流程 责任人”三件事一起推否则就是一次性工程。我强烈建议在所有技术方案落地之前先指定每个 NHI 的“负责人”。对你没有听错每个非人类身份都必须有一个人来承担责任。这个人可能是开发这个 Agent 的工程师、也可能是业务线的技术负责人但必须有一个。没有负责人的身份在一个季度内必须被封禁。这条规则听起来很粗暴但效果立竿见影——一旦有人负责权限就会有人认真审生命周期就会有人记着。流程上建议把它挂到现有的 DevSecOps 流程里。每次创建新的 AI Agent 或自动化服务时自动创建一个需求单包含身份注册、权限申请、负责人绑定三部分审批通过后才能拿到凭证。这样就把“事后救火”变成了“事前管理”。最后再分享一点个人体会做 NHI 治理这几年我最大的感受是身份安全这件事本质上不是技术问题而是管理视角问题。以前我们管理身份时心里默认“身份 人”所有工具和流程都围绕人来设计。但 AI Agent 数量爆发之后这个默认前提塌了——你的系统里有一半以上的“员工”不是人而你的安全体系却还停留在“管人”的思维上。所以不管你公司现在有没有正式部署 AI Agent我都建议你现在就开始盘点一次 NHI把它当作一次“体检”。等到 Agent 数量真的涨起来再补课那种工作量绝对让你后悔没早做。先跑一遍扫描花不了几天但你知道自己手里有多少把钥匙之后至少不会在安全上裸奔。