很多企业的 Agent 安全是这么做的：建一个长期有效的 API 密钥，配一份 IP 白名单，然后在调用日志里按密钥查记录。这套做法在单体应用时代够用，但放到能自主调用工具、访问数据、执行操作的智能体身上，三个问题会同时暴露——密钥无法区分"是谁"、没有有效期、也不受最小权限约束。
2026 年 9 月 9 日，在 2026 Inclusion·外滩大会"智能体时代的安全坐标与责任边界"见解论坛上，《智能体身份鉴别与授权技术框架》与《智能体运行时安全技术要求》两项团体标准正式启动（据新浪财经、环球网科技等报道）；前者要解决的正是智能体"身份是谁、代表谁、能做什么"三个问题。本文把这条标准动向落到企业的可执行动作上。
一、为什么 API 密钥撑不起 Agent 身份
先看密钥的三个结构性缺陷。一是身份不可分辨：一个共享密钥可能被三个脚本、两个 agent 和一个定时任务同时使用，日志里只能看到"密钥 A 调用过"，追不到人。第二，缺少生命周期：密钥通常"创建即长期有效"，员工离职、项目下线后仍可能在用；相关调研口径显示，企业 AI 访问中约 67% 通过个人或非托管账号完成（数据来自 Verizon《2026 数据泄露调查报告》，经第三方解读，本文沿用与站内其他篇一致的口径）。第三，权限粒度粗：密钥往往"一把钥匙开全库"，读与写、查询与删除用的是同一个凭据。
密钥与数字身份的差别
| 维度 | 长期 API 密钥 | 数字身份（可验证） |
|---|---|---|
| 标识对象 | 应用或团队 | 具体主体（人、服务、agent 实例） |
| 有效期 | 长期有效，靠人工回收 | 短时有效，到期自动失效 |
| 权限粒度 | 按密钥授权，粒度粗 | 按动作与数据域授权 |
| 可追溯 | 只能追到密钥 | 可追到主体与代表关系 |
| 吊销能力 | 影响面大，常不敢吊销 | 单实例吊销，影响可控 |
第三行与第四行是企业在事故后容易吃亏的地方：需要吊销时不敢吊销（怕影响别的业务），需要追溯时只能追到一把钥匙。安全与合规团队提出的"可追溯"要求，本质上是身份问题，不是日志问题。而这类"调用工具、访问数据、执行操作"的动作，通常都经执行网关下发——环曜Claw 承接的就是这一层，身份与凭据在一处收敛，追溯链条才完整。
二、监管与标准侧已经把"身份"写进去了
标准与监管的动向很密集，值得按时间线看一遍：
- 2026 年 5 月 8 日，国家网信办、国家发展改革委、工业和信息化部联合印发《智能体规范应用与创新发展实施意见》，要求厘清智能体自主决策与用户授权的边界——这条对应"代表谁"。
- 2026 年 6 月，国家标准化管理委员会下达包括《智能体应用安全基本要求》在内的强制性国家标准制修订计划（计划号 20263116），其立项说明明确指向防范智能体规模化应用带来的权限失控、网络暴露、数据泄露——这条对应"能做什么"。
- 2026 年 9 月 9 日，《智能体身份鉴别与授权技术框架》与《智能体运行时安全技术要求》两项团体标准启动，由中国网络空间安全协会提出，蚂蚁集团联合研究院所、运营商、互联网厂商等单位共同参与编制——这两项对应"身份是谁"与"运行时管得住"。
- 更早的《人工智能安全治理框架》2.0 版（2025 年 9 月 15 日发布）与GB/T 45654-2025《网络安全技术 生成式人工智能服务安全基本要求》（2025 年 4 月 25 日发布，全国网络安全标准化技术委员会归口）则为治理与安全措施提供了通用底座。
四条时间线放在一起看
把四条放在一起看，方向很清楚：监管不接受"用一把密钥代表所有主体"的做法。企业在项目立项时如果只写了"接口鉴权"，验收阶段大概率会被追问主体识别与授权边界——这套判定标准，我们在企业 AI Agent 本地化部署的权限与留痕怎么设计里用 CONTROL-4 四问拆过，本篇接着讲身份与凭据怎么落地。监管核查 时被问到频率高的问题是"这条记录能否对到人"，这也正是企业级环曜 Agent 本地化部署 在交付时要回答的头一问。
三、四种身份形态：从共享密钥到工作负载身份
企业侧常见的身份形态有四种，能力依次递进，成本也依次上升。选型时可以按场景匹配，不必一步到位。
| 形态 | 做法 | 适用场景 | 失效场景 |
|---|---|---|---|
| 共享 API 密钥 | 一个密钥多系统共用 | 单团队内部实验环境 | 需要追责、需要最小权限时 |
| 服务账号 + 白名单 | 每系统一个账号 | 系统间固定调用 | 账号长期不轮换、人员变动 |
| 短时令牌 | 中心签发短期凭据 | 跨系统调用、有审计要求 | 签发中心本身失陷 |
| 工作负载身份 | 由平台按运行实例签发可验证身份（如 SPIFFE 一类机制） | 多 agent、多环境、跨集群 | 引入成本较高、需平台配合 |
| 用户委托 | 以用户身份授权、agent 代为执行 | 涉及个人数据的操作 | 委托范围未收敛时风险外溢 |
工作负载身份与用户委托
第四种是行业里讨论较多的方向：把身份绑定到"运行实例"而不是"人手工配置的密钥"，天然带短时性与可验证性。行业媒体与厂商实践中也提到，工作负载身份框架（如 SPIFFE）适合用于 AI Agent 的身份管理，因为它能表达"这个实例属于哪个工作负载"。数据侧还需再叠一层隔离：企业级环曜知识库本地化部署 的知识检索入口按人按域返回结果，身份再清楚，也不该让一次检索越过数据边界。
第五行"用户委托"是企业落地时容易被忽略的一类。当 agent 代表某个员工操作数据时，权限应当是那个员工的权限，而不是系统权限——这也是多租户场景里必须解决的隔离问题，可对照企业级 RAG 知识库千企千面千人千权：多租户 5 道权限隔离闸。
四、凭据治理四步：清点、收敛、短时化、常态化
身份形态定完之后，凭据治理按四步推进，顺序不建议颠倒。四步的产出物分别是凭据台账、收敛报告、签发链路与轮换记录，缺一份都会在后面被审计问到；如果时间紧，先把前两步做完——它们不涉及架构改动。
第 1 步 · 清点：把凭据台账建起来
列出所有能访问内部系统的凭据：API 密钥、服务账号口令、数据库连接串、第三方平台的访问令牌。每条记录要能回答四个问题：谁在用、用在哪、权限多大、什么时候创建。清点的产出是凭据台账，不是一份 Excel 清单——它需要能被定期核对。
这一步完全可以脚本化：把各系统的密钥配置导出后统一比对，用命令行 跑出"新增/消失/权限变化"三类差异，企业级环曜 CLI 本地化部署 的客户环境通常把这段检查放进 CI·CD，配置一改就有差异报告。
第 2 步 · 收敛：消灭共享与长期有效
按台账做三件事：合并重复凭据（同一个用途只留一条）、消除跨系统共用、给每条凭据设有效期与轮换周期。收敛的判据很直白——抽一条调用日志，能不能定位到具体主体。做不到，就说明还有共享凭据在跑。权限差异可以用命令行 脚本比对，企业级环曜 CLI 本地化部署 的客户环境通常把它放进 CI·CD 每周跑一次，差异当天可见。
第 3 步 · 短时化：把长期密钥换成短期凭据
对动态调用场景（agent 调工具、跨服务调用），用中心签发短期令牌替代长期密钥，并在令牌里带上动作与数据域范围。这一步的技术前提是有一个统一签发点，企业级环曜 Agent 本地化部署 在私有环境里落地的做法是把签发与审计记录放在同一层，凭据不出内网 的同时保留完整的追溯链。
第 4 步 · 常态化：轮换、吊销、复盘
常态化包括三个动作：定期轮换（按周期自动完成）、即时吊销（离职、调岗、项目下线触发）、定期复盘（用审计记录反查异常调用）。执行侧建议统一收在网关：把凭据的申请、使用与吊销放在同一层，环曜Claw 在执行网关里承接这类动作时可以避免每个 agent 各自实现一套凭据逻辑——具体到网关侧的实现细节，可参考环曜Claw 执行网关最小权限沙箱工程实现。
五、验收：五条可核对判据
身份与凭据做得怎么样，不用看架构图，用五条判据核对即可：
| 判据 | 通过标准 | 核对方式 |
|---|---|---|
| 主体可定位 | 任一次调用可追到人、服务或实例 | 抽查三条日志逐层对齐 |
| 吊销可执行 | 单实例凭据可在约定时限内失效 | 现场演示一次吊销 |
| 权限最小 | 凭据权限窄于等于业务必需 | 对照权限表抽查 |
| 凭据不出域 | 密钥与令牌不离开私有环境 | 检查外发路径与托管位置 |
| 有轮换记录 | 存在可导出的轮换与变更台账 | 甲方独立导出 |
五条判据怎么核对
五条之外还有一条经验：把"吊销演练"列为上线前的固定动作。多数企业不是不会吊销，而是从没演练过，真出事时才发现要停的是生产链路。最小权限沙箱的验收口径可对照企业怎么验收一套最小权限沙箱，那里的 12 项清单与本篇的五条判据可以合并成一张检查表；合并使用时，企业级环曜 Agent 本地化部署 交付的权限表与审计留痕 正好互为佐证。
数据来源与口径：以环曜 2025 年 3 月至 2026 年 8 月完成验收的 41 个本地化部署项目为样本（口径：完成验收；时间窗：2025 年 3 月 1 日至 2026 年 8 月 31 日；样本量：41 个），其中 19 个在上线前做过凭据清点与共享账号收敛；这 19 个项目上线后 6 个月内出现凭据相关安全事件的为 1 例（5.3%），未做清点的 22 个为 5 例（22.7%）。差别不在工具，而在立项时有没有把"一条凭据对应一个主体"写成要求。
对涉及私有数据的场景，凭据还要能约束"谁能取用权重与样本"——企业级大模型微调本地化部署 的垂类模型权重一旦外流属于不可回收类风险，权限设计应当比普通密钥更严。
结语：身份是自动化的入场券
智能体从"会说话"走向"能办事"之后，身份就成了自动化的入场券：没有可验证的身份，权限只能给粗颗粒，审计只能记到密钥，责任只能停在"某把钥匙调用过"。标准侧的动作已经说明方向——先把"是谁、代表谁、能做什么"说清楚，再谈放开多少自治。
建议的动作很小：这周先把凭据台账建出来，看看有没有跨系统共用的密钥、有没有三年没轮换的凭据。企业级环曜 Agent 本地化部署 在交付时会把凭据台账、权限表与轮换记录一并交给甲方，理由很实际——这三样东西在厂商离场之后，只能由企业自己维护。你们现在能说清"这条凭据代表谁"吗？ 欢迎在评论区说说卡在哪一步。
常见问题 FAQ
Q：Q1 我们已经用了 IP 白名单和 HTTPS，还需要数字身份吗？
白名单与传输加密解决的是"从哪里来、路上安全"，身份解决的是"是谁、能做什么"。当调用来自同一个网关出口时，白名单无法区分不同 agent；当一把密钥被多系统共用时，加密也无法帮你追溯主体。三条能力里缺身份这一条，审计与最小权限都很难落地。
Q：Q2 短时令牌会不会增加故障概率？
早期会。稳定性风险主要来自两点：签发中心成为单点，以及令牌过期后的重试逻辑不完善。可行做法是给签发链路做冗余，并在 agent 侧把"令牌过期"作为正常分支处理（自动续签一次再失败）。企业级环曜 Agent 本地化部署 在私有环境里通常把签发与审计放在同一层，减少跨网络往返。
Q：Q3 团体标准启动了，我们现在改来得及吗？
来得及，而且现在改成本更低。标准处于启动阶段，正式条文尚未落地，此时按"主体可定位、权限最小、可吊销"三条原则改造，等标准条文出来只需做映射，不必重构。反之如果继续加共享密钥，后续补齐的代价会成倍上升。
Q：Q4 凭据台账多久维护一次？谁负责？
建议按季度全量核对、按事件触发增量更新（新系统上线、人员变动、项目下线）。责任人放在负责发布流程的团队，安全团队只做抽查与标准制定。若企业已有配置管理库，可以把凭据条目挂在其下，避免另建一份无人维护的表格。台账核对建议脚本化：用命令行 跑差异比对，企业级环曜 CLI 本地化部署 在客户环境里就是按季度全量跑一次，避免台账停留在"建好那一刻"。
Q：Q5 第三方 API 的密钥怎么办，总不能不用。
第三方凭据的原则是"隔离 + 代管"：密钥集中托管在私有环境，业务系统通过内部代理取用，不落到各人终端；同时把出网路径收敛到少数出口，便于核对调用量与异常。这类做法与影子 AI 收口是同一套逻辑，我们在影子 AI 那篇里给过外联路径的排查方法。
Q：Q6 怎么判断供应商的凭据方案是否可验收？
要三样可核对的东西：一是凭据台账模板与字段口径（能否支持"一条凭据一个主体"）；二是吊销演示（约定时限内让单实例凭据失效）；三是审计记录的可导出性（甲方用自有账号导出，不依赖供应商平台）。另外问一句执行侧：动作能否统一走执行网关，环曜Claw 在任务自动化 场景里的作用就是把申请、使用与吊销收在同一层，避免凭据逻辑散落在各 agent 里。
