AI Agent接入业务系统前，身份与权限要管住哪6件事

原创

老张
老张

信息安全动态

2026年10月4日 11:56
山东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

周一上午，OA 里多了一张申请：市场部想让一个 AI Agent 读部门共享邮箱、自动在 OA 里建工单，顺手再帮研发提代码 PR。附件只有一页产品介绍，“使用账号”那一栏写着：用我自己的账号授权就行。

这张单子批还是拦？我的建议是先别急着二选一。把 Agent 当成一类新的“非人类身份”来管，看 6 件事有没有补齐：影子 AI 盘点、身份登记、最小授权、令牌生命周期、高危操作人工确认、日志留存。按下面的步骤走完，你手上会有一份 Agent 台账、一张权限矩阵、一套令牌基线，外加文末那张可以直接挂进内部审批流的《Agent 接入评审表》（分必做、应做、可做三级）。适合正被业务推着走的 CISO、身份与权限负责人，以及兼管安全的 IT 负责人。

为什么是现在？8 月 27 日，NIST 在网络安全博客发文《Back to the Future: Why Agentic AI Needs a Strong Identity Foundation》，直言不少 Agent 系统正在重犯传统 IAM（身份与访问管理）几十年前踩过的坑——共享凭证、长期令牌、权限过宽。最近 MCP Python SDK 又披露了一个 OAuth 校验缺陷，Agent 的授权有被冒用的风险（MCP 是让 Agent 连接外部工具和数据源的开放协议）。

01

开工前先对齐：Agent 到底算哪类身份

▎它和服务账号、API Key 差在哪

先说结论：Agent 像服务账号，但不能完全按服务账号那套管。

相同处好理解：都不是人，都靠凭证调用系统。不同处有三点，决定了现有 IAM 能复用多少。

一是行为路径运行时才决定。服务账号调哪些接口，开发时就写死了；Agent 接到“帮我修这个 Bug”，会自己决定读哪些文件、调哪些工具，事先列不全。

二是它常常代表某个人在做事。服务账号代表的是系统，Agent 背后通常站着一个发起任务的员工，中间还可能再委托给别的 Agent，形成一条委托链。

三是生命周期两极分化。有的 Agent 实例只为一个任务存在几分钟；有的装在员工电脑上，一驻留就是大半年，没人记得它还开着。

API Key 只是凭证形态，证明不了“谁在用”。NIST 那篇博客说得直接：bearer token（持有即可用的令牌）和静态 Key，谁拿到谁能用。“给 Agent 发一把 Key”不等于“给 Agent 建了身份”。

▎本文覆盖的三类接入

按管控难度从低到高，大致分三类：

•

A 类：SaaS 自带的 Agent 功能，比如邮箱、协同办公、代码托管平台内置的助手；

•

B 类：员工在本地装的 Agent 客户端、IDE 插件、MCP 客户端，影子 AI 大多在这一类；

•

C 类：企业自建 Agent 平台，通过 API 或 MCP 调业务系统。

A 类主要管授权范围，C 类主要管身份和令牌。B 类最难——你往往不知道它存在。

▎三个前提，缺了先补

统一身份源（IdP，能对接 OAuth/OIDC 或单点登录）、知道哪些系统存敏感数据的应用清单、能收 IdP 和 SaaS 审计日志的集中日志平台。缺哪个，对应那一步就只能做半截。

▎NIST 的思路怎么对到你现有的 IAM

先澄清一点，免得内部汇报引错：NIST 没有发布叫“Agent IAM 框架”的正式标准。流传的“六要素”，是国内解读文章结合上面那篇博客和 NCCoE（NIST 下属的国家网络安全卓越中心）今年 2 月关于 AI Agent 身份与授权的概念文件归纳的。可以用，但别写成“NIST 提出六要素”。

第 1 步“影子 AI 盘点”不在上表里，它是企业侧的前置动作。

02

第 1～2 步：先看见，再登记

▎第 1 步：影子 AI 盘点（产出：Agent 台账初稿）

很多企业第一反应是发通知“禁止私装”。可你不知道现在有多少在跑，禁令就没法验收。所以先盘点，从三处入手。

终端。 在软件资产或 EDR 清单里查 Agent 客户端、IDE 插件和本地 MCP 配置文件。重点看一件事：有没有把云服务 Key、代码平台 Token 直接写进本地配置。NIST 博客点过名，这类凭证经常以明文出现在配置文件、markdown 文件甚至日志里。

网络出口。 用代理或防火墙日志，统计哪些终端在访问主流大模型 API 和 Agent 服务域名。不必精确，能圈出重度使用的部门就够了。

SaaS 授权。 最容易漏、也最该优先看的一处。在 IdP 和各 SaaS 管理后台导出“第三方应用 OAuth 授权”清单，把申请了邮箱读写、文件全盘访问、代码仓库写权限的应用挑出来。员工点一次“同意”，Agent 就拿到了长期访问权，终端和出口日志里都未必看得出来。

▲ SaaS 授权这条路不经过终端和出口，只盘前两处会漏掉拿着长期令牌的 Agent

盘出来之后，原则是先登记、不急着封。按“数据敏感度 × 权限范围”分三档：碰核心数据且权限全量的，立即收回授权；权限过宽但数据一般的，限期整改；其余的纳入正式评审。一刀切全封，结果通常是员工换个更隐蔽的用法。

▎第 2 步：身份登记（产出：Agent 身份登记表）

回到开头那张申请。“用我自己的账号授权就行”——这一条在评审里要直接否掉。

要害在责任边界。Agent 用张三的账号删了一个文件，日志只会记“张三删除了文件”。是张三自己点的，是 Agent 自己判断要删的，还是被一封邮件里夹带的指令带偏了？事后说不清。

所以每个 Agent 都要有自己的身份，同时绑定两个人：责任人（出了事找谁）和委托人（它代表谁行动），两者可以是同一个人，但要分别登记。字段建议至少包括：Agent ID、接入类型（A/B/C）、责任人、代表谁行动、可访问系统、数据级别、凭证方式，以及上线、复审、下线三个日期。

落到 IdP 里很朴素：单独设一个身份类别或统一命名前缀（比如 agt-），和普通服务账号分开。再挂到现有入转离流程上，责任人离职或转岗，名下 Agent 自动进入复审或停用。花不了多少钱，却能堵掉“人走了 Agent 还在跑”的口子。

03

第 3～4 步：权限按任务给，令牌按小时算

这一节最重，也是业务方最容易嫌麻烦的部分。

▎第 3 步：最小授权与委托控制（产出：Agent 权限矩阵）

最常见的偷懒，是让 Agent 直接套用发起人的角色。问题在于 Agent 以机器速度操作，还会为完成目标自己尝试各种路径。NIST 的说法是，即使权限已收紧，这种“机会主义”式解题仍可能去找遗留凭证或绕路。

所以授权口径要从“角色”换成“任务”。还是开头那个例子，合理的授权大概是这样：

具体到 OAuth scope 审查，我自己掌握的几条硬杠杠：

•

拒绝全量范围。Files.ReadWrite.All、full\_access 这一类，没有充分理由一律不批；

•

能只读就不给写，能限定到具体资源就不给全局；

•

申请单要写清每个 scope 对应哪个功能，写不出来的砍掉。

多 Agent 场景还有个委托问题：主 Agent 把子任务交给子 Agent 时，权限只能减、不能加。用户有 100 的权限，不代表 Agent A 能拿 100；A 有 30，也不代表它派生的 B 自动拿 30。你用的平台如果做不到逐级收窄，就干脆禁止多级委托。

▲ 每往下委托一级，权限只能收窄，不能自动继承上一级的范围

本地 Agent（B 类）再补一条运行隔离：不让它直接继承用户在这台电脑上的全部权限，SSH Key、云配置、内网访问都在里面。放进独立系统账号、容器或沙箱里跑，限制文件和网络访问。成本不低，我把它放在应做和可做之间，研发终端优先。道理也简单，IdP 里写着“不许读 SSH Key”，操作系统层面它照样能打开用户目录下的密钥文件，策略就成了纸面规则。

标准层面，NIST 博客提到 RAR（RFC 9396，细粒度授权请求）、AuthZEN（把授权判断交给独立策略引擎的接口规范）、Transaction Tokens（在调用链上传递授权上下文，仍是 IETF 草案）。知道方向即可，不必强求马上上。

▎第 4 步：令牌生命周期（产出：令牌管理基线）

Agent 是临时的，它带的权限也该是临时的。基线就四条：

1

禁止把长期静态 Key 直接配给 Agent；

2

访问令牌短时效（以小时计，能按任务签发更好），并限定受众（audience，即这个令牌只能用在哪个服务）；

3

刷新令牌可吊销，而且吊销要有明确的操作路径；

4

凭证集中托管在密钥管理系统或凭证库，不落本地明文。

光有基线还不够。我看过的几次 OAuth 相关整改，缺口大多出在配置上，而不是协议本身：

•

授权服务器的 issuer（签发方标识）没有固定，客户端信了对端下发的 OAuth 元数据；

•

回调地址写得太宽，甚至用了通配；

•

client secret 一用好几年不轮换，几个 Agent 共用一个客户端；

•

没有吊销预案，出事时不知道该吊销哪些令牌。

MCP Python SDK 这次的问题，正好撞在第一条上。据安全内参转载的看雪学苑报道（转引 Cycode 的披露），部分客户端在处理 OAuth 发现时过度信任了 MCP 服务器返回的配置，没有严格校验 issuer。受影响版本为 1.9.1～1.29.1 和 2.0.0～2.1.1，修复版本是 1.30.0 和 2.2.0。公开报道里我没找到 CVE 编号，具体以 MCP 官方 GitHub 安全公告为准。

对甲方来说，处置清单比漏洞原理有用：升级；显式配置预期 issuer；连过不可信 MCP 服务器的，清理旧 OAuth 注册、轮换 client secret、吊销可能暴露的令牌、回查日志。这几步做不做得下去，取决于第 2 步登记得清不清楚——不知道哪些 Agent 用了这个 SDK，就不知道该轮换谁。

可做项有两个参考：NIST IR 8587（草案）讨论令牌和断言怎么防伪造、防窃取；DPoP（RFC 9449）把令牌和持有者密钥绑定，被偷了也没法直接重放。规模不大的企业，先落实四条基线更划算。

04

第 5～6 步：高危操作有人点头，每一步追得到人

▎第 5 步：高危操作人工确认（产出：高危操作清单 + 确认规则）

先定义什么算高危。建议从这几类起步，再按业务补：对外发邮件或群发、删除数据、付款和审批流转、权限变更、代码合并到主干、访问生产环境、导出敏感数据。

怎么弹确认，比弹不弹更关键。每一步都弹窗，用户很快会闭眼点“允许”，NIST 博客把这叫 consent fatigue（授权疲劳），跟 MFA 推送轰炸一个道理。更可行的做法：任务开始时由人批准一份“任务边界”，读哪些、改哪些、能调哪些工具写清楚，边界内放行，越界才弹确认。

还有一条容易忽略。判断“这算不算高危”的，不能是 Agent 自己。确认规则要落在 Agent 之外的确定性系统里，比如审批流、API 网关或策略引擎。模型会误判、会被诱导，网关上的规则不会。

▲ 任务边界内由网关直接放行，越界或高危才转人工确认，判断不交给 Agent 自己

▎第 6 步：日志留存与责任链（产出：日志字段规范 + 留存策略）

日志要达到的效果，一句话说得清：把“张三删除了文件”还原成“张三发起任务 T-123，Agent-A 在该任务中执行了删除”。

表里的来源要能用任务 ID 或令牌标识串起来，否则查起来还是各看各的。

留存有法规底线。《网络安全法》第二十一条第（三）项要求采取监测、记录网络运行状态和网络安全事件的技术措施，并按规定留存相关网络日志不少于六个月；GB/T 22239-2019 第三级的 8.1.4.3 条（安全计算环境·安全审计）要求审计覆盖到每个用户，审计记录包括日期时间、用户、事件类型和是否成功。Agent 要不要单独算作一个“用户”，目前没有明确说法。我倾向于按用户管，具体以监管部门和测评机构的解释为准。

05

最容易踩的 5 个坑

1. 让 Agent 用员工本人的账号或 Cookie 登录。 接入最快，但日志里分不清人和 Agent，出了事说不清责任。修法看第 2 步。

2. 只看连了哪个系统，不看 scope。 授权页一路点“同意”，拿到的往往是全量读写。修法看第 3 步，scope 逐条对应功能。

3. 一个客户端、一把 Key，多个 Agent 共用。 吊销一个就全停，不吊销又分不清是谁。修法看第 2、4 步。

4. 以为加了人工确认就安全了。 确认太频繁，等于没确认。修法看第 5 步的任务边界。

5. 只管自建平台，不管员工本地装的。 C 类管得最严，B 类反而没人看。修法看第 1 步，按季度复跑。

扯一句：这 5 个坑，很多团队当年管服务账号时几乎都踩过一遍。NIST 那篇文章叫《回到未来》，我猜也是这个意思。

06

怎么算验收通过

验收不看文档写得多漂亮，看能不能拿出证据。建议按下面 6 条抽查：

•

每个 Agent 都有独立身份和责任人。证据：IdP 身份清单与台账逐条对得上；

•

没有全量 scope，没有直配的长期静态 Key。证据：SaaS 授权清单和凭证库记录；

•

抽一个 Agent 做吊销演练，能在约定时限内（比如 1 小时）让它的令牌全部失效。证据：演练记录；

•

抽一次高危操作，能看到确认记录，且确认发生在审批流或网关。证据：审批流日志；

•

随机抽一条 Agent 操作日志，能追到发起人和任务 ID。证据：日志查询结果；

•

影子 AI 盘点按季度复跑。证据：盘点报告和处置记录。

复审节奏：上线前评审一次，之后每季度复审，责任人变动或权限变更时触发临时复审。

说实话，第一次跑通会比较吃力，尤其吊销演练——不少团队做了才发现，根本不知道某个 Agent 的令牌存在哪。这正是演练的价值。

07

《Agent 接入评审表》

评审结论建议分三档：必做项全部通过，可以上线；必做项有缺口，限期整改后上线；涉及核心数据且必做项缺口在 2 项及以上，不予接入。

你们内部现在是怎么批 Agent 接入的？欢迎留言聊聊。

— END —

信息安全动态

面向企业安全负责人与安全工程师的专业号：把等保、数据安全合规和安全运营落到可执行的清单和方案。