你的AIAgent根本没有”身份”——这是下一场安全事故的源头
先说一个会让安全团队睡不着觉的比例。
在那些已经认真部署了 AI agent 的企业里，“非人身份”——也就是各种 API key、服务账号、机器人、agent——的数量，已经达到了真人用户的 82 倍。但根据 Salt Security 2026 上半年的报告，将近一半的组织（48.9%）对这些非人流量基本是”瞎”的：它们根本不知道自己手底下那些自主 agent 每天在访问什么、调用什么、改动了什么。
我们正在飞快地给 AI agent 放权——让它访问数据库、调用第三方 API、替我们花钱、自动改文件。可与此同时，有一个最基础的问题几乎没人停下来认真回答过：这个 agent，到底”是谁”？
打个比方：这就像你给一个实习生发了张门禁卡，卡上没写名字，不限楼层，还永远不会失效。哪天卡丢了，你既不知道是谁的卡，也不知道它能进哪些门，更没法远程把它停掉。agent 现在用的，多半就是这种卡。
先搞懂什么是”非人身份”，以及它为什么突然爆炸
身份这个词，我们通常默认指人。你有账号、有密码、登录时可能还要过一道短信验证。但在任何一个稍微复杂点的系统里，“不是人”的身份其实一直存在，而且数量庞大：服务账号、API key、OAuth token、证书、CI/CD 流水线里的凭证、各种自动化机器人。安全圈把它们统称为”非人身份”（Non-Human Identity，简称 NHI）。
这些东西过去也带来麻烦，但麻烦相对可控。一个服务账号说到底是个”静态凭证”——它持有一把钥匙，能开某几扇门，但它不会自己思考、不会临时决定去开别的门。你把它配好、锁好，基本就不用太操心。
AI agent 把这件事彻底改变了。
云安全联盟（CSA）在 2026 年 5 月的一份白皮书里说得很直接：agent 不是被动的凭证持有者，而是自主的行动者。它会在运行时动态获取权限、临时派生出子 agent、调用外部 API、自己写代码并执行，还能把一连串动作串起来跨越几十个系统。这里的每一个行为，都在放大”一把凭证一旦泄漏”的爆炸半径——这个半径，远远超过一个老老实实的服务账号能造成的破坏。
数字也很扎眼。CSA 的调查显示，只有 15% 的组织对自己防住 NHI 攻击的能力有信心；2026 年的一份分析发现，超过 16% 的组织压根不追踪”AI 相关身份”是什么时候、被谁创建出来的。换句话说，很多公司连自己有多少个 agent 在跑、各自拿着什么权限，都说不清楚。
agent 既不是”人”也不是”服务账号”——身份体系的尴尬
要理解这个洞为什么不好补，得先看清楚一件事：agent 不属于我们已有的任何一类身份。
传统上身份就两类。
一类是人：有登录入口，有多因素认证，会犯困会离职，权限随岗位变动，出了事能找到具体的人负责。另一类是服务账号：一串静态凭证，只负责”持有访问权”，不做判断，配好之后长期不变。
agent 是冒出来的第三类，而且它最别扭的地方在于——它会行动，而且它的行动带着一条委托链。一个 agent 干活时，背后其实是这么一句话：“这个 agent，代表这个用户，在这个权限范围内，做这件具体的事。” 这条链上有三方：发起的人、跑 agent 的应用、agent 本身。三方缺一不可，但现有的身份协议偏偏表达不了这种结构。
OAuth、SAML 这些用了十几年的协议，是围绕”人登录”或”应用调用”设计的。它们能处理”用户授权某个应用”，也能处理”应用之间互相调用”，但它们缺一个关键机制：为某个具名的 agent，向用户征求一次明确的同意。结果就是，今天大量 agent 的接入方式简单粗暴——直接塞一把 API key 了事。这把 key 既不知道背后是哪个用户授权的，也不限定具体能干什么，往往还永不过期。
三类身份对比：人、服务账号、AI Agent
行业怎么补这个洞——OBO、临时身份与委托链
好消息是，2026 年这个问题已经从”没人管”变成了”一堆人在抢着定标准”。思路大体可以归成三层。
◎ 第一层，让 token 说清楚”到底是谁在操作”
这就是 OAuth 的 On-Behalf-Of（代表某人，简称 OBO）流程。它的核心改动是：签发出来的访问令牌里，同时记下三个身份——用户、客户端应用、以及具体的那个 agent。这样一来，下游任何一个系统在收到请求时，都能看清楚”这是 X 用户，通过 Y 应用，授权 Z 这个 agent 来做的”。微软的 Entra Agent ID 已经落地了这套 OBO 流程，把 agent 当成一个独立的身份来做令牌交换。
◎ 第二层，给 agent 一个能过”同意屏”的真名字
IETF 正在推进一份草案，给 OAuth 的授权流程加了两个参数：一个叫 requested_actor，放在授权请求里，用来在用户的授权同意页面上显示”你正在授权给哪个 agent”；另一个叫 actor_token，放在换取令牌的环节，用来证明”我确实是那个 agent，不是冒充的”。授权服务器会核对这两者匹配，才发令牌。说白了，就是让用户在点”同意”之前，真真切切看到自己授权的是哪个 agent，而不是稀里糊涂给出去。
◎ 第三层，让权限尽量短命、尽量收窄、还能随时收回
CSA 把理想形态描述为”临时认证”——为 agent 当前这个任务量身定制一个短时、随上下文变化的身份，任务一结束就自动过期。还有更前沿的方案。可衰减令牌（AAT）把 agent 能调用哪些工具、参数受什么约束都写进令牌本身，持有者可以离线派生出一个权限相等或更窄的子令牌，但无法扩权，并且要受父令牌的委托深度与有效期限制。
另一份草案 DAAP 走得更远：它用 DID 给 agent 配一个基于密码学的独立身份，配上防篡改的哈希链审计记录、可在线校验的吊销模型，以及一套支持多级委托与级联吊销的策略引擎——也就是说，整条委托树可以被最初授权的那个人一次性收回。
这些方案的细节各不相同，但落到一个共同原则上：最小权限、绑定到具体任务、用完即弃、全程可审计。
OBO 委托链：令牌同时记下用户、客户端、agent
看不见，才是最大的风险
讲了这么多技术方案，但现实里最要命的问题，往往还不是”被攻击”,而是”压根不知道发生了什么”。
回到开头那个数字：近一半组织看不见自己的非人流量。一个你看不见的 agent，哪怕它现在没出事，你也无从判断它有没有被人做了手脚、有没有在偷偷越权。安全的前提是可见，可见的前提是每个 agent 都有可追溯的身份——而这恰恰是很多团队缺的。
供应链是这个盲区里最危险的一块。企业接入的 agent、集成、AI 工具，很多来自第三方，而它们往往用一把宽泛的 API key 接进来，而不是受限的 scoped token。2026 年 3 月就出过一次典型事故：一个叫 LiteLLM 的包（它是 CrewAI、DSPy、微软 GraphRAG 等一大批 agent 框架的”语言模型网关”）被植入后门，在 PyPI 上挂了三个小时，期间被下载了将近 4.7 万次。一个环节被污染，顺着这些框架往下，影响面瞬间放大。
CSA 在白皮书里强调了一点：第一方凭证管得再好，也挡不住这种供应链攻击。任何接进企业系统的第三方 agent，都该遵守和自研 agent 一样的身份治理标准——用受限的 OAuth 令牌而不是大把的 API key，在合同里写明安全要求，对第三方集成的异常访问做持续监控。
开发者与团队现在能做什么
道理讲完，落到能动手的事情上，其实有一份相当清楚的清单。
给每个 agent 一个独立的、可追溯的身份，别让一堆 agent 共用同一把 key。出了事，你至少能定位到是哪一个。
用受限、短时的令牌，替代长期有效的 API key。权限绑定到具体任务，任务做完就让它过期，而不是发一把”万能永久卡”。
把第三方 agent 纳进同一套治理标准。别因为它是”别人家的工具”就网开一面——它接进你的系统，就该按你的规矩来。
给非人流量上监控，先把”看不见”这个最大的盲区解决掉。你没法管控一个你压根观察不到的东西。
在设计阶段就把身份问题画进架构图：这个 agent 能做什么、代表谁、谁能在它失控时把它叫停。这些不是上线后再补的功能，而是第一天就该想清楚的地基。
给 Agent 一个真正的身份：五条治理要点
结尾：身份是 agent 安全的地基
这一两年，我们花了大量精力讨论 agent 的能力——它会编程、会花钱、会操作电脑、会自己组队干活。这些都很激动人心。但有一个更朴素的问题，被能力的光环盖过去了：它到底是谁？
安全的逻辑恰恰是反过来的。先有身份，才谈得上授权；先看得见，才谈得上管控。一个连身份都没理清的 agent，给它的权力越大，埋下的雷就越深。
所以在你给手里的 agent 放更多权之前，不妨先停下来回答三个问题：它是谁，它代表谁，它失控时谁能叫停它。把这三件事想明白了，再谈让它替你干活也不迟。
数据来源说明
· 非人身份规模与盲区（82:1 比例、48.9% 看不见非人流量）：Salt Security《1H 2026 State of AI and API Security Report》、Rubrik Zero Labs（2025-11）NHI 比例研究
· NHI 治理现状（15% 有信心防 NHI 攻击、16% 不追踪 AI 身份创建、agent 动态获取权限/派生子 agent/爆炸半径、临时认证原则、第三方供应链治理）：云安全联盟（CSA）《The Non-Human Identity Governance Vacuum》白皮书（2026-05-20）
· OAuth On-Behalf-Of 与 agent 身份方案（requested_actor / actor_token 两参数、令牌记录委托链）：IETF 草案 draft-oauth-ai-agents-on-behalf-of-user-01、WorkOS《OAuth’s On-Behalf-Of flow for AI agents》（2026-04-28）、Microsoft Entra Agent ID 文档
· 可衰减令牌与委托链方案：IETF 草案 draft-niyikiza-oauth-attenuating-agent-tokens-01（AAT）、draft-mishra-oauth-agent-grants-00（DAAP）。以上 IETF 草案均会滚动更新，此处引用的是 2026 年 8 月初可见的版本，落地前请以 datatracker 上的最新版为准。
· LiteLLM 供应链后门事件（3 小时、约 4.7 万次下载、殃及 CrewAI/DSPy/GraphRAG）：helpnetsecurity《OWASP: prompt injection still drives most agentic AI security failures》（2026-06-11）
—推荐阅读 —
