NIST勾勒Agent安全IAM蓝图：六个关键要素

随着 Agent 从“回答问题”走向“执行任务”，AI 安全正在面对一个越来越基础、却长期被模型安全讨论所忽视的问题：当 Agent 开始读取文件、调用工具、访问数据库甚至代表用户执行真实操作时，它究竟是谁？它代表谁？又被允许做什么？

2026 年 8 月 27 日，美国国家标准与技术研究院（NIST）发布文章《Back to the Future: Why Agentic AI Needs a Strong Identity Foundation》，结合此前国家网络安全卓越中心（NCCoE）发布的《Software and AI Agent Identity and Authorization》概念文件以及产业界反馈，系统讨论了 Agent 身份与访问管理问题。

https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation

NIST认为，当前不少 Agent 系统正在重复传统 IAM（Identity and Access Management，身份与访问管理）几十年前已经踩过的坑，包括共享凭证、长期 Token、过宽权限以及过度依赖人工授权等；与此同时，Agent 的自主性和机器级执行速度，又会进一步放大这些问题。

需要说明的是，NIST目前还没有正式发布一套名为“Agent IAM Framework”的标准。本文结合其概念文件和最新文章，将其中分散的身份、认证、授权、委托、运行环境和审计要求进一步归纳为 Agent 安全 IAM 的六个关键要素：独立身份、动态凭证、最小授权、委托控制、运行隔离和审计治理。

为什么 Agent 需要重新设计 IAM？

过去的大模型主要负责生成内容，系统安全问题更多集中在“模型会不会输出不该输出的内容”。但 Agent 不同，它不仅能生成答案，还会为了完成目标自主寻找信息、选择工具并执行操作。一个 Coding Agent 接到“帮我修复这个 Bug”的指令后，可能自行读取代码、搜索文档、调用终端、访问 GitHub、创建分支、执行测试甚至触发部署。

问题在于，用户只提出了一个高层目标，Agent 具体会走哪条路径、调用哪些工具，往往是在运行过程中动态决定的。NIST在今年 2 月的概念文件中因此提出了一系列非常基础的问题：Agent 应该如何被识别？什么构成 Agent 的强认证？如何在动作无法提前完全预测时实现最小权限？Agent 怎样证明自己有权执行某个具体动作？又该如何处理“代表某人行动”的授权委托？

这意味着 Agent 安全正在从一个单纯的“模型安全问题”，进一步变成一个传统安全非常熟悉的 主体—权限—资源问题。过去我们问“模型会不会做错事”，现在还必须问：

是谁在行动？代表谁行动？在当前任务下，它究竟有权做什么？

这正是 IAM 要解决的问题。

01 独立身份

不要让 Agent 直接“冒充”用户

目前很多 Agent 最简单的接入方式，是直接继承用户已有的身份。例如用户将自己的账号、Cookie、API Key 或访问令牌交给 Agent，Agent 再以用户身份访问 GitHub、邮箱、数据库等系统。

这种设计的问题并不只是“凭证可能泄露”，更重要的是它破坏了责任边界。服务器看到的可能只是“张三修改了文件”，但真实过程可能是“张三让 Agent 完成一个任务，Agent 自己决定修改了文件”。如果 Agent 又受到了错误上下文、提示注入或其他外部因素影响，仅凭最终操作日志，很难再回答究竟是谁做出了决定。

因此 NIST提出，Agent需要被视为一个 一等身份主体（first-class entity），拥有自己的唯一标识、凭证和权限，并与运行或授权它的用户、系统建立明确绑定关系。

理想情况下，身份关系不再是：

用户身份 → Agent直接复用 → 服务

而应该变成：

用户身份 → 授权/委托 → Agent身份 → 服务

这样系统看到的就不再只是“张三访问了 GitHub”，而可以知道：这是 Agent-A，代表张三，在 Task-123 中执行了一次代码提交。

这构成了 Agent IAM 最基础的一层：

首先证明“是谁在行动”，再讨论“它能做什么”。

02 动态凭证

Agent 消失，权限也应该消失

拥有独立身份之后，第二个问题是 Agent 用什么凭证证明自己的身份。

目前不少 Agent 原型仍然采用最简单的方法：把 GitHub Token、云服务 Key、数据库密码直接写进环境变量、配置文件甚至 Markdown 文件，然后让 Agent 自行读取。NIST指出，长期 API Key 和 Bearer Token 本身就是传统 IAM 长期试图解决的问题：任何拿到 Token 的主体都可能直接使用它，而 Agent 又会频繁穿越工具、网络和服务，使凭证暴露面进一步扩大。

Agent 的一个重要特点恰恰是临时性。很多 Agent 实例可能只为了一个任务存在几分钟，那么它对应的 Credential 和 Authorization 也应该具有类似生命周期：

任务创建 → 动态获取凭证 → 执行任务 → 凭证失效。

因此，相比长期静态 Key，更适合 Agent 的是短生命周期、范围受限、面向特定服务的动态凭证。NIST特别提到了 OAuth 2.0、SPIFFE、JWT、X.509 以及 DPoP 等现有技术。其中 DPoP 可以进一步把 Token 与密钥持有者绑定，降低 Token 被盗后直接重放的风险。

这里真正重要的不是具体采用哪一种协议，而是一条原则：

Agent 是临时的，它携带的权力也应该是临时的。

03 最小授权

从“角色权限”走向“任务权限”

有了身份和凭证，并不意味着 Agent 就安全了。真正棘手的问题在于：应该给它多大权限？

传统企业 IAM 经常采用角色授权。例如某个开发人员属于 Developer Role，因此拥有仓库读取、代码提交甚至测试环境部署权限。但把同样的角色权限直接赋予 Agent，风险会明显放大。因为 Agent 可以以机器速度连续操作大量资源，而且会为了完成目标自主尝试不同路径。NIST指出，在宽泛权限下，Agent 可能使用意料之外的数据或工具；即使权限已经受到限制，其“机会主义”式的问题求解过程仍可能寻找遗留凭证或其他替代路径。

因此，Agent IAM需要进一步从粗粒度的“角色权限”走向更动态的任务级、交易级授权。例如，不是简单告诉 Coding Agent：

你拥有 repo.write。

而是明确：

在 Task-123 中，你可以访问 project-X，可以修改 feature-123 分支，可以运行测试和创建 PR，但不能删除仓库、不能访问其他项目，也不能进入生产环境，这份权限 30 分钟后自动失效。

NIST提到的 RAR（Rich Authorization Requests）可以表达更加细粒度和动态的授权要求，AuthZEN 则试图通过标准接口把“是否允许执行”的判断交给独立的策略决策系统。

于是授权问题发生了一个重要变化：

不要只问“这个 Agent 有什么权限”，而应该问“在这次任务里，这个 Agent 被允许做什么”。

04 委托控制

Agent 可以传递任务，但不能复制权限

如果系统里只有一个 Agent，身份和权限管理已经不简单；进入多 Agent 系统后，还会出现一个更复杂的问题——授权如何沿调用链传递。

未来典型的执行链很可能是：

用户 → Manager Agent → Coding Agent → Deployment Agent → Tool / API

用户只向 Manager Agent 提出任务，Manager Agent 再自行将部分工作交给其他 Agent。如果每一级 Agent 都直接继承上一级的全部权限，那么经过几轮委托后，一个原本只负责代码分析的子 Agent，也可能最终拥有生产环境访问权。

因此，NIST在概念文件中特别强调了“on behalf of”场景下的授权委托问题，而最新文章进一步提到 Transaction Token 等机制，用于在用户和 Agent 的调用链上传递授权上下文，并保证权限在委托过程中得到衰减（attenuation）。

可以把它理解为：

用户拥有 100 的权限，并不意味着 Agent A 获得 100；Agent A 拥有 30，也不意味着它创建的 Agent B 自动获得 30。

每一次委托都必须重新回答：这个子任务真正需要哪些权限？哪些信息应该继续向下传？哪些权限必须在这里被截断？

这也是多 Agent 系统一个非常重要的安全原则：

Agent 可以继续委托任务，但不能继续复制权力。

未来的 Agent 安全问题，很大一部分可能都会演变为这种 Delegation Security（委托安全）问题。

05 运行隔离

不要让 Agent 天然拥有用户的一切

NIST还特别讨论了一种越来越普遍的场景：本地 Agent。

Coding Agent、办公 Agent 等工具为了方便使用，往往直接运行在用户电脑上，并继承用户当前的系统账号。这样做非常方便，但也意味着 Agent 可能天然拥有用户在这台机器上的大量权限，包括本地文件、Git Credential、SSH Key、云服务配置、环境变量甚至内部网络资源。

从传统操作系统角度看，这相当于：

Agent 并没有自己的权限边界，而是直接生活在用户的权限空间里。

NIST认为，这不仅允许 Agent 冒充用户，也会削弱不可否认性和集中式身份治理能力。因此，即便 Agent 运行在本地，也应该部署在经过加固的 Harness 或 Sandbox 中，通过容器、文件系统权限、网络限制、工具访问策略等方式限制其活动范围。(NIST)

这里实际上把 IAM 和运行时安全连接到了一起。仅仅在身份系统里规定“Agent没有读取 SSH Key 的权限”并不够，如果操作系统层面它仍然能够直接打开 ~/.ssh，IAM 策略就可能成为纸面规则。

因此第五个要素实际上是：

身份隔离 + 权限隔离 + 运行环境隔离。

其核心原则很简单：

一个 Agent 由某个用户启动，不意味着它自动继承这个用户拥有的一切。

06 审计治理

必须能够还原“人—Agent—工具”的责任链

最后一个问题是：即使前面的安全控制全部建立起来，当 Agent 真正执行了某个动作之后，我们如何知道它为什么这么做，以及谁应该为这次动作负责？

传统审计日志可能只记录：

Alice 删除了 file-X。

但到了 Agent 时代，这条记录已经远远不够。一个更完整的记录至少需要回答：

哪个用户发起了任务？哪个 Agent 实际执行了动作？是否存在上级 Agent？执行的是什么任务？使用了哪份授权？访问了什么资源？当时的权限从哪里获得？

NIST在概念文件中将 **Auditing and Non-repudiation（审计与不可否认性）**单独列为重要问题，并提出需要考虑如何以可验证、防篡改的方式记录 Agent 的动作和意图，以及如何将 Agent 行为重新绑定回人的授权。

这意味着未来 Agent 日志需要记录的不再只是 Action，而是一条完整的：

Human → Agent → Agent → Tool → Resource

责任链。

这也是 Agent 自主程度越高之后，一个非常现实的问题：以前可以通过“谁点了这个按钮”寻找责任主体，但未来越来越多动作并没有任何人直接点击按钮，而是来自几分钟前甚至几小时前的一次高层目标授权。

Human-in-the-Loop 也不是万能解

很多系统目前把人工确认视为最后一道安全保险：

Agent 要执行高风险操作 → 弹窗 → 用户点击 Allow。

但 NIST特别提醒，过度依赖这种机制可能产生 Consent Fatigue（授权疲劳）。如果 Agent 在复杂任务中不断弹出权限申请，用户最终很可能像面对大量 MFA 推送一样，形成机械点击“允许”的习惯，此时人工确认反而失去了原本承担的责任确认作用。(NIST)

因此，更合理的方向并不是“每一步都让人审批”，而是在任务开始时建立明确的授权边界，只在真正突破边界时重新请求确认。例如提前批准一份任务“飞行计划”：允许读取某个仓库、修改指定分支和运行测试，而访问生产环境、读取敏感凭证等行为则始终需要额外授权。

换句话说：

Agent IAM 的目标不是让人审批更多，而是让人的授权表达得更准确。

六个要素背后，其实是三个安全控制面

如果进一步抽象，前面的六个要素其实可以归入三个不同的安全控制面。

第一层是身份控制面：Identity + Credential。 它负责回答“这个 Agent 是谁”“代表谁”“如何证明自己的身份”。Agent 不再只是一个模型进程，而是企业数字身份体系中的独立主体。

第二层是权限控制面：Authorization + Delegation + Runtime Isolation。 它负责回答“Agent 现在被允许做什么”，以及这种权限在 Agent、子 Agent 和工具之间如何安全传递。这里真正执行的是最小权限、动态授权和零信任原则。

第三层是治理控制面：Audit + Non-repudiation + HITL。 它负责回答“发生了什么”“为什么允许发生”“最终责任可以追溯到哪里”。

将这三层放到一起，就形成了一套比传统“模型护栏”更完整的 Agent 安全结构：

LLM负责推理和决策，但不能成为权限本身。

身份、凭证、授权、策略执行、沙箱和审计应该由模型之外的确定性系统负责。这样即使模型发生误判、受到错误上下文影响，甚至遭遇提示注入，系统仍然可以通过外部权限边界限制其实际影响范围。

这也回应了 NIST 在文章开头提出的一个重要判断：现有仅围绕模型构建的 Guardrail，并不足以覆盖 Agent 带来的全部安全问题。

从“让模型不犯错”到“让错误无法越过边界”

过去几年，大模型安全的一个重要目标，是让模型尽可能“做正确的事”：识别攻击、拒绝危险指令、避免产生错误行为。

但随着 Agent 开始真正进入操作系统、企业应用和现实业务流程，这种思路本身已经不够了。因为只要系统允许模型自主决策，就很难要求一个概率模型永远做出正确判断。

NIST这套 IAM 思路提供了另一种安全路径：不再把全部希望寄托在模型永远不犯错，而是建立模型无法自行突破的身份与权限边界。

即使 Agent 判断错误，它也只能访问当前任务允许访问的数据；即使 Agent 被诱导，它也不能自动获得用户全部凭证；即使 Agent 创建新的子 Agent，权限也不会无限向下复制；即使最终真的发生错误操作，系统仍然能够还原“谁授权了谁、谁执行了什么”。

因此，Agent 时代真正需要建立的，不只是更强的模型护栏，而是一套新的运行时控制基础设施：

无论模型听了谁的话、做出了什么判断，它最终都只能在被明确授予的身份和权限边界内行动。

这或许才是 NIST 重新把 IAM 拉回 Agent 安全核心位置的真正原因。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。