文章总结： 文档分析82:1的机器身份与人类身份比例下agent凭据泄露的三起事故，指出命令注入、提示注入和明文存储是主要泄露路径，强调长期令牌风险。建议采用OBO授权模型、短时令牌、工具白名单和最小权限原则，并给出七条上线前检查清单，包括凭据盘点、令牌时效、scope最小化、审计字段等，以缩小泄露半径并提升可追溯性。 综合评分： 85 文章分类： 数据安全,云安全,安全建设,安全运营

82个机器身份配1个人：Agent凭据泄露三起事故与上线检查清单

cwbird cwbird

bird网络安全

2026年8月18日 09:46 四川

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

CSA 的调研给过一个比例：企业内非人类身份（NHI）与人类身份的数量比达到 82:1，每个员工身后站着 82 个服务账号、API 密钥、OAuth 令牌和 Agent 运行时凭证（CSA 报告数据，转引自《开放式 AI Agent 框架安全风险深度分析》，2026 年 3 月）。2026 年 3 月，这个基数背后的事故接连兑现：OpenAI Codex 因命令注入泄露 GitHub OAuth 令牌；GitHub Copilot 在 Codespace 里被提示注入诱导，把 GITHUB_TOKEN 发到攻击者控制的外部服务器。

三起泄露，终点都是长期令牌

Codex 那次属于命令注入：攻击面在 Codex 执行环境与外部系统的交互通道上，注入成功后环境里存放的 GitHub OAuth 令牌被直接读走（9.AI《AI 24 小时》，2026 年 3 月 31 日）。Copilot 那次更憋屈，安全研究员 Nisimi 构造的提示让 Codespace 里的 Copilot 主动把 GITHUB_TOKEN 外传到指定服务器，全程没有传统意义上的漏洞利用，模型自己「执行」了泄露动作（刹客网络科技资讯，2026 年 3 月 4 日）。

第三起看存储设计。CSA 用 MAESTRO 框架给 OpenClaw 做威胁建模，结论写得很直白：OAuth 令牌、API 密钥、配对凭证以未加密 JSON 文件的形式静态存储（国际云安全联盟 CSA，2026 年 3 月 11 日）。数说安全的分析补上了路径：明文凭证就放在 ~/.openclaw/ 目录下，实例一旦暴露，聊天记录、客户信息之外，邮箱 OAuth 令牌一并可捞（数说安全，2026 年 3 月 25 日）。

命令注入、提示注入、默认明文存储，三条路径的终点一致：攻击者拿到长期有效的机器凭据。人泄露密码可以强制改密加双因素，OAuth 令牌被第三方复制后在吊销前一直可用，而多数 Agent 的令牌从创建那天起就没设过过期时间。8 月初联想全球安全实验室的文章把边界问题讲得很透：Agent 具备调用工具、执行操作和访问企业资源的能力之后，企业安全的边界已经从大模型本体延伸到 Agent 本身（2026 年 8 月 7 日）。

82:1 的真正麻烦在生命周期

机器身份的管理难度被 82:1 这个比例放大。按人头做凭据盘点，一个人名下 82 个身份，靠表格必然盘不动。CSA 2026 年的 NHI 调研把令牌管理失控列为 AI 时代身份安全的主要风险之一，两条硬建议值得直接抄走：把 NHI 权限审查纳入季度合规流程，在 Agent 场景实施 OBO（On-Behalf-Of）授权模型（CSA 2026 调研，竹云解读，2026 年 3 月 13 日）。

生命周期问题的实际形态长这样：一个 Agent 项目跑三个月下线，创建时申请的服务账号、API key、OAuth 刷新令牌没有明确的责任人回收。业内有人把这类无人管理的代理叫「身份暗物质」（identity dark matter），名字起得真准（何夕一言堂，2026 年 3 月 18 日）。我们内部盘过一次：一个做告警摘要的测试 Agent，项目停了半年，它的服务账号 key 还躺在生产环境的配置中心里，权限是当时的开发为了省事直接给的只读全库。这半年没被滥用，纯属运气。

另一组数据供参考：一项面向 235 位 CISO 的风险调研里，47%的受访者观察到 AI 智能体相关的越权行为（AI 数术研习社，2026 年 3 月 23 日，n=235）。样本规模不算大，方向与上面三起事故对得上：风险已经从「理论上可能」进入「确实在发生」。

OBO 加工具白名单：把泄露半径压进一小时

第一个做法是 OBO 模型。Agent 不持有用户的全量令牌，接到任务时用当前用户身份换一个作用域受限的短时访问令牌，任务结束令牌即失效。以 OAuth 的 scope 为例，一个只需要读仓库信息的 Agent，申请的 scope 应该收敛到 repo:read 这一级，砍掉 workflow 和写权限。Codex 泄露的正是全量 OAuth 令牌，如果令牌按任务签发、有效期一小时，泄露的爆炸半径会小一个量级。这是我基于三起事故共性做的推断，标注为个人观点。

第二个做法落在工具调用层。MCP 实践里已经有成熟套路：工具白名单、审计日志、危险操作二次确认（走在大数据架构路上的笔《为什么你的 Agent 需要 MCP》，2026 年 8 月 8 日）。RSAC 2026 创新沙盒选手 Token Security 把这件事产品化了，它强调的归因链路字段可以直接抄进自家日志规范：谁、在什么时间、以什么输入和上下文、调用了什么工具和权限、对哪个资源（绿盟科技，2026 年 3 月 11 日）。

配置示意（MCP server 侧，示例性质）：

{   「agent_id」: 「alert-summary-01」,   「tools」: [「jira.search」, 「confluence.read」],   「denied_tools」: [「shell.exec」, 「http.fetch」],   「token_ttl_minutes」: 60,   「confirm_required」: [「jira.comment」] }

白名单外的工具直接拒绝，令牌按小时轮换，写操作弹人工确认。这几行配置挡不住提示注入本身，但能把注入成功后的动作压死在只读范围内。把长期令牌发给 Agent，然后指望系统提示词防住所有注入，这个思路本身就悬。

上线前的一页清单

七条，按优先级排：

1. 凭据盘点：全量排查明文存储点，重点覆盖 ~/.openclaw/ 这类框架默认目录、配置中心、CI/CD 变量组。
2. 令牌时效：长期令牌换成短时访问令牌加刷新令牌轮换，访问令牌有效期不超过 1 小时。
3. scope 最小化：逐个 Agent 核对申请的 scope，任务用不到的权限全部砍掉。
4. 工具白名单：默认全拒，按任务开白名单，写操作加二次确认。
5. 审计字段：日志至少包含 agent_id、task_id、工具名、参数、目标资源、时间戳，缺一项事后就没法归因。
6. 季度审查：把 NHI 权限审查挂进已有合规流程，CSA 调研里这是被验证过的落地路径。
7. 吊销演练：验证从发现令牌泄露到完成吊销加轮换能在 1 小时内走完，没演练过的预案等于没有。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：bird网络安全 cwbird cwbird《82个机器身份配1个人：Agent凭据泄露三起事故与上线检查清单》