别把人的账号直接交给 Agent

回到未来：为什么 Agentic AI 需要坚实的身份基础

引言

随着 AI 走向成熟，企业和客户正在迅速部署智能体（Agent），以期释放下一层级的自动化与生产力。Agentic AI 展现出处理海量用例的潜力，从在亚马逊上购买个人物品，到客服应用，再到企业安全与软件开发。然而，早期的 Agentic 部署正在重复一个熟悉的模式：把功能开发和即时价值置于安全之上。

这种策略可以理解。战略、财务与技术负责人都急于展示 AI 投资的 ROI（投资回报率）。企业面临创新和提升组织效率的压力。个人则在追求自动化、个性化的体验。更重要的是，Agentic AI 引入了一片全新的安全挑战前沿，而"仅靠模型"（model-only）的护栏尚不足以解决这些问题。在一个快速演进的领域里建立完全成熟的安全框架需要时间，但退回过时的安全实践，会侵蚀 AI 智能体本应提供的核心价值。

本文将讨论当前一些身份与授权实践，它们给 Agentic AI 系统带来了严重的安全挑战。这里讨论的许多挑战并不新鲜——说白了，就是几十年来一直困扰身份管理系统的老问题。本文旨在提醒：当我们向着 Agentic 落地一路狂奔时，在既有的基础性身份标准与最佳实践之上部署和构建，才能让实施者更好地应对未来的挑战。

本文涵盖的主题，取材于近期 NCCoE《加速软件与人工智能智能体身份与授权的采用》（Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization）概念文件的公众评论，以及与 Agentic AI 生态利益相关方的广泛交流。（原文链接：https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf ，2026 年 2 月发布，公众评议期至 2026-04-02。NCCoE 即 National Cybersecurity Center of Excellence，美国国家网络安全卓越中心。）这项 NCCoE 工作的目标，是通过展示网络安全标准与最佳实践如何降低风险、实现 Agentic AI 的价值，来加速 Agentic AI 的采用。

Credential Sharing ｜ 凭证共享

自从密码诞生以来，安全专家就一直在告诉用户：不要共享你的凭证。这样做违反了身份与访问管理（Identity and Access Management，IAM，即对"谁"在访问、"能做什么"进行统一管理的体系）的一项核心原则：通过验证试图完成交易的个人或服务的身份与权限，来建立可问责性（accountability）。在任何场景下，共享凭证都是坏主意。

然而，个人把自己的个人及企业凭证交给智能体，已经迅速成为一种常见模式，用来让 Agent 访问数据、应用和服务。在人之间或 Agent 之间共享凭证，会造成问责缺口，进而引发各种安全、隐私和法律问题。对于那些把不可否认性（non-repudiation，即事后无法抵赖"这不是我做的"）作为核心安全要求的行业——例如金融交易或健康信息共享——这一点尤其严重。

要让组织对交易有信心，Agent 需要被当作一等实体（first-class entities）来对待：拥有自己唯一的标识符、凭证和相关授权（entitlements），并且这些凭证与授权绑定于、且来源于操作该 Agent 的用户或系统的身份。企业与 IAM 服务商在这一点上是一致的，许多技术厂商正在构建支持 Agentic 身份注册、凭证、权利委托（rights delegation，即把部分权限转授给 Agent）、策略管理与治理的系统。许多 Agentic AI 用例可以借助已经在使用的现代授权模式来满足——这些模式本来就用于共享或"委托"（delegating）对数字工具的访问。对企业部署而言，SPIFFE（Secure Production Identity Framework for Everyone，面向所有人的安全生产身份框架，为工作负载签发标准化身份）和 OAuth 2.0（业界最广泛使用的授权协议，允许第三方应用在不拿到用户密码的情况下获得有限授权）等协议，提供了应对 Agentic 身份识别与授权挑战的机制。而 WIMSE（Workload Identity in Multi-System Environments，多系统环境工作负载身份，IETF 正在制定的新标准）和 Identity Assertion JWT Authorization Grant（身份断言 JWT 授权许可，OAuth 工作组草案）等新兴标准，则在这些协议之上构建，增加新的能力。（相关链接：https://spiffe.io/docs/latest/spiffe-specs/ ；https://datatracker.ietf.org/doc/html/rfc6749 ；https://datatracker.ietf.org/wg/wimse/about/ ；https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ ）

面向消费者的场景挑战更大：企业对 Agentic 身份几乎没有控制权，可能难以把 Agent 和真人区分开来——尤其是当用户凭证被交给 Agent、从而允许"冒充用户"时。虽然 FIDO（Fast Identity Online，快速在线身份联盟，制定无密码认证标准的组织）等标准机构正在研究（https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/ ）签发可绑定到用户身份的 Agent 认证器，但这项工作仍处于早期阶段。总体而言，业界已经认识到：在消费者场景中，"安全之路"必须同时是"便捷之路"，否则凭证共享与冒充只会继续泛滥。

Static and Long-lived Credentials ｜ 静态与长期凭证

给 Agent 配发长效 API 密钥（API key）或第三方服务的访问令牌（access token），往往是搭起 Agentic 概念验证或工作流最快的方式。然而，持有者令牌（bearer token）和静态 API 密钥并不能证明身份——任何拿到密钥的人或服务都能调用该 API。API 密钥提供的是宽泛、无范围限制的访问，无法为"Agent 可以如何与服务交互"建立更细粒度的授权。长效持有者令牌虽然可以携带一些范围（scope）信息，但它们不带有密码学的持有证明（proof of possession）：任何人、系统或服务，只要拿到令牌就能出示它。携带 API 密钥与持有者令牌穿梭于网络、工具和资源之间的 Agent，让其所有者和下游应用暴露在日益增长的风险之下——密钥或令牌可能泄露，或被未授权第三方获取。此外，API 密钥、令牌这类凭证常常毫无保护、明文存放在配置文件、Markdown 文件、日志等随处可及的地方。

这些问题并不新鲜。多年来，静态长效令牌的丢失与滥用一直是众多重大安全事件的根源。但 AI 技术的普及及其在各类用例中的横向渗透，让许多个人和组织在几乎无视身份最佳实践的情况下，被迫仓促部署和测试 Agentic 功能。虽然短生命周期（ephemeral，即用即弃）的 Agent 已被普遍部署，但并非所有人都意识到：Agent 的凭证与授权也需要体现这种短暂性。幸运的是，基础性标准早已就位——尤其是 OAuth 2.0、SPIFFE，以及以 JSON Web Token（JWT）、X.509 证书等形式承载的凭证——为 Agentic 系统提供了关键的构建起点。此外，发送方约束（sender constraining）协议，例如 DPoP（Demonstrated Proof-of-Possession，持有证明演示，RFC 9449，https://datatracker.ietf.org/doc/html/rfc9449 ），可以为人和非人用户缓解许多令牌被盗场景。这些标准若要为 Agentic IAM 系统提供最优能力，还需要继续演进；但实现关键前置条件的能力今天就已存在——例如动态的、范围收紧的、受众受限（audience-restricted）的令牌与凭证。为帮助企业保护令牌，NIST 近期发布了 NISTIR 8587 草案（DRAFT），聚焦令牌管理最佳实践（https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8587.ipd.pdf ）。

Broadly Scoped Access ｜ 授权范围过宽

API 密钥和静态持有者令牌因授予过宽的访问权限而臭名昭著，但迁移到现代授权系统与协议并不会自动解决问题。IAM 从业者一直在为实现细粒度授权、策略执行与访问控制而战，以推进"最小权限"（least privilege，即只授予完成任务所必需的最小权限）原则。因此，许多访问控制场景可应用的粒度随时间不断改善，但宽泛的、基于角色的授权——无论源自遗留技术、权限蔓延（entitlements creep），还是糟糕的实现模式——依然是难题。虽然零信任（Zero Trust）实现日益普遍（参见 NIST SP 800-207，https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf ；零信任即"永不默认信任、始终验证"的安全架构），但即时访问（just-in-time access）与最小常驻权限（least standing privilege）等原则尚未普遍落地运营。

Agent 势必会加剧这个问题。Agentic 操作的速度、规模与容量可以远超人类。在宽泛的高层指令与概率式推理（probabilistic reasoning）驱动下，Agent 会不可预测地搜寻、探测并执行多条路径来达成目标。一旦拿到宽泛访问权，它们可能使用意料之外的工具或数据，造成非预期的破坏——例如删除整个数据集或代码库。即便授权被严格限制，Agent 的机会主义本性也可能驱使它去利用漏洞、寻找被遗弃的孤儿凭证（orphaned credentials）来提升权限。

为迎接 Agentic 采用，企业不仅需要把 Agentic 授权范围收紧到与业务价值和风险承受度相匹配，还需要确保全企业范围内的凭证与令牌管理到位。在这一领域，厂商和标准同样在演进以迎接挑战：对传统访问令牌中静态、粗粒度范围（scope）的担忧，催生了 RAR（Rich Authorization Requests，丰富授权请求，RFC 9396，https://datatracker.ietf.org/doc/html/rfc9396 ），它支持动态、细粒度的授权。Transaction Tokens（事务令牌，https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/ ）等其他规范，则在研究如何把授权上下文贯穿人类与 Agent 的调用链，确保授权在委托传递过程中逐级衰减（attenuated）。开放身份基金会（Open Identity Foundation）的 AuthZen（Authorization API，授权 API 规范，https://openid.net/specs/authorization-api-1_0.html ）定义了与外部策略执行点（PEP）和策略决策点（PDP）通信的标准化 API，为更大规模、更细粒度的授权打开了大门。

Deploying Agents with Local User Accounts ｜ 用本地用户账号部署 Agent

企业与个人都希望快速、便捷地部署 Agent 来获取 Agentic 价值。一种常见模式是在本地部署 Agent，并赋予它本地用户凭证与权限，让 Agent 协助完成软件开发、制作演示文稿、创建表格与文档等任务。这种部署模式虽然方便——许多开发者也确实偏好本地工作——但把本地账号交给 Agent，等于同时允许 Agent 冒充用户并以宽泛范围行事。Agent 以用户授权执行命令，破坏了不可否认性（non-repudiation）；当 Agent 在用户未充分理解或同意的情况下执行操作时，组织还要承担潜在的下游后果。此外，本地 Agentic 部署使得集中管理的 Agent 身份库难以建立，还会助长其他棘手的 IAM 实践，例如把静态凭证存放在本地文件里。

尽管 IAM 社区仍在围绕"首选且标准化的 Agentic 部署模式"凝聚共识，但有一点很清楚：Agent 所依托的基础设施，极大影响着 Agent 能被如何识别、认证与授权。许多人相信云部署能提供更强健的安全服务——可以利用硬件信任根（hardware roots of trust）以及原生的分段或容器化架构——但本地 Agentic 部署将长期存在。本地 Agent 及其推理模型需要被部署在一个经过加固、受到保护的外壳（harness）中（示例：https://www.anthropic.com/engineering/harness-design-long-running-apps ），让用户和组织能够预先约束 Agent，并获得类似云部署的控制能力。本地 Agent 也可以部署在沙箱（sandbox）中——例如严格受控的容器——让 Agent 能安全地执行代码、运行终端命令，同时限制它可触达的攻击面。

Relying on Human-in-the-Loop ｜ 过度依赖人工审批环节

把 Agent 身份绑定到人、让委托的权利逐级衰减、收紧授权范围——这些措施都有助于确保 Agent 按照个人与组织的预期行事。但许多人仍把 Human-in-the-Loop（HITL，人工介入审批环节）视为 Agentic 控制的根本要素。Agent 在复杂工作流中穿行时，经常需要访问新的数据源或外部工具。为了支撑 Agentic 行为的可问责性与不可否认性，"去问一下人、让人批准访问"很有诱惑力；但过度依赖 HITL 机制，会带来严重的"同意疲劳"（consent fatigue）风险。

这一现象在 MFA"轰炸"（MFA bombing，又称 MFA fatigue，多因素认证疲劳攻击）中已有充分记录：攻击者用一连串认证推送通知淹没用户，直到受害者不加看地批准一次恶意登录。同样，喋喋不休的 Agent 会训练用户出于本能点击"允许"，只为让自动化流程继续跑下去。当用户习惯了不假思索地批准访问请求时，HITL 反而破坏了它本应提供的不可否认性与可问责性。

但 HITL 的频率并不是唯一的担忧。通过 MCP（Model Context Protocol，模型上下文协议）中的引出/征询（elicitation）等机制，Agent 可以就"如何最好地完成某项任务"向人请求额外输入。这一机制在让 Agent 行为符合预期、聚焦为用户创造价值方面非常有用，但它也可能被用来索要用户凭证或其他敏感信息。在这类场景中，elicitation 让 Agent 得以冒充用户，并可能促成对敏感信息的未授权使用——这又一次破坏了 IAM 的核心原则。

与过去的 IAM 方案一样，持久可靠的 Agentic 身份与授权设计，要求企业同时权衡 HITL 的可用性与安全性。虽然治理这一挑战的标准可能尚不存在，但 Agentic 生态正在形成缓解 HITL 问题的最佳实践：MCP 协议明确警告不要用 elicitation 收集敏感信息（https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation ）；AI 模型厂商也在开发易用的方案，例如为 Agentic 行为预批准"飞行计划"（approved flight plans，示例：https://www.anthropic.com/engineering/claude-code-auto-mode ）——把敏感信息从提示词中剥离，并帮助减少同意疲劳。

Conclusion ｜ 结论

Agentic AI 带来了新的 IAM 挑战。这些挑战的解决方案，将建立在 IAM 社区多年来不断打磨、倡导和践行的最佳实践基础之上。退回到糟糕的实践——共享凭证、依赖静态令牌、授予过宽访问、滥用 Human-in-the-Loop 审批——只会让 IAM 社区花了数十年试图消灭的漏洞借尸还魂。任何组织在迎接 Agentic 未来时，最重要的行动之一，或许是清醒地对照当前标准与最佳实践，评估自己现有的 IAM 实践、系统与能力。因为当 Agentic 规模横跨整个企业部署时，现有能力中的问题、挑战与缺口只会被进一步放大。

今天已经确立的 IAM 标准与最佳实践，正是我们未来构建安全、可扩展的 Agentic 协议的地基。

这些推动 IAM 标准与协议演进的工作，将为 NCCoE 的《软件与 AI 智能体身份与授权》项目（Software and AI Agent Identity and Authorization，https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization ）提供参考。我们期待与产业界及其他利益相关方协作，探讨既有和新兴的身份标准与技术如何应用于实际的 Agentic 架构，并确定还需要哪些补充指引。

与其他项目一样，NCCoE 计划发布一套资源组合，包括博客文章、在线资源中心和 NIST 出版物，以支持面向软件与 AI 智能体的 IAM 标准与最佳实践的采用。本系列的下一篇博客，将重点介绍持久 Agentic 设计所需的一些身份与授权原则。

对本项目的意见可发送至：AI-identity@nist.gov

About the Author ｜ 关于作者

Bill Fisher 是美国国家网络安全卓越中心（NCCoE）的安全工程师。他负责领导一支工程师团队，与产业伙伴协作解决国家面临的网络安全业务挑战。他曾领导该中心的基于属性的访问控制（Attribute Based Access Control，ABAC）项目，是 ITL 物联网安全（Cybersecurity for IoT）项目成员，领导 NCCoE 公共安全与数据安全项目，也是 NCCoE 勒索软件团队成员。近期他加入担任 NCCoE 移动驾照（mobile driver's license，mDL）项目的联合负责人。

Ryan Galluzzo 是 NIST 应用网络安全处（Applied Cybersecurity Division）的数字身份项目负责人（Digital Identity Program Lead）。他负责协调数字身份相关项目与倡议，推动 NIST 标准与指南的演进，并开展促进数字身份创新的基础性研究。他曾参与多部 NIST 特别出版物的编写，包括 NIST SP 800-63《数字身份指南》（Digital Identity Guidelines）。加入 NIST 之前，Ryan 是德勤（Deloitte & Touche）的专家负责人（Specialist Leader），十余年间为包括国税局（IRS）、总务署（GSA）和 NIST 在内的多个联邦机构提供网络安全与身份管理的专家意见。

引用的标准与文件清单

附：读者评论要点（以下为该博客下的读者留言，非 NIST 正文）

以下为评论区的读者留言要点，均属读者观点，与 NIST 正文立场无关：

1. 授权是时间点行为，执行却是过程：有评论指出，授权在某一时刻授予，但执行不会停在原地——Agent 会切换工具、委托给其他 Agent、访问不同数据源、找到通往同一目标的其他路径。每个身份都已知、每次单独授权都有效，仍可能失去对"执行是否仍在最初意图与授权之内"的追踪。HITL 一节使这一点更尖锐：这个缺口显然无法靠"每次执行变化都去问人"来弥补。"开始时已授权"与"执行变化后仍授权"之间的地带，是大部分实际工作仍需完成之处。
2. Agentic AI 需要边界：随着 Agent 自主性增强，零信任原则（最小权限、持续验证、强身份）更加关键；保护 AI-Agent 身份层，是在企业规模安全部署 Agentic AI 的根本（附一条 YouTube 链接）。
3. 机器速度下的信任保持：赞赏文章对凭证共享、长效权限与 HITL 局限性的处理；Agentic 规模会迅速放大本来在人类场景下就困难的 IAM 弱点。随着 Agent 能跨多系统执行有后果的操作，保持"身份、委托权限、具体交易"三者的区分越来越重要。强身份是地基，现在的挑战是让其上构建的保障性（assurance）在机器速度下仍有意义。
4. 身份不等于权限（Identity Is Not Authority）：一位读者（David Forbes，BLOCK VECTOR Technologies）发布了同题技术回应文章，探讨下一个架构问题：Agent 被识别、认证并授予访问之后，系统如何为某次具体的、有后果的执行确立"被承认的权限"（recognized authority）？其主张是：拟议执行应在产生后果之前对照"被承认的权限"进行评估，无法确立权限时就不执行。
5. 给 Agent"发驾照"：有读者提到自己在做一个高度符合 NIST 标准的系统（xchk，自称 46/47 项合规），认为 Agent 应该像汽车一样被"发牌照"——这个类比非常贴切，"这个问题我们 100 年前就解决过"。
6. 信任依赖在协议之外：Hushmesh 的评论认为，现有 IAM 能认证身份、传递凭证与授权，但身份背后的许多信任依赖位于协议之外——Agent 实际上继承了创建并运营它的管理域的信任边界（基础设施、运维人员、密钥管理、策略系统等）。跨组织边界运行与组合的 Agent，这些继承来的依赖会成为每个依赖方（relying party）信任决策的一部分，并随组合而累积。他们认为这需要新的架构基础（可验证的加密标识符），而不仅是 IAM 的延伸。
7. 让安全成为阻力最小的路径：Atsign 的评论认为，这些模式之所以存在，是因为它们是"周五下午让 Agent 跑起来最快的方式"，光靠指南无法纠正，要让安全做法成为最省事的做法。其方案：每个 Agent 在运行机器上生成自己的密钥（不从所有者处复制任何秘密，配置里存的是名字而非秘密）；Agent 在它所服务的人或角色名下获得名字，日志记录"Alice 的 Agent 以 Alice 的授权行事"而非"Alice 做了这件事"；每次授权限于一片数据、可在签发时设过期，且所有者的服务器在每次请求时都校验（而非仅登录时一次）。并强调吊销（revocation）必须能触达已交付的数据，而不只是拦截下一次请求——这是多数设计忽略的部分。表达希望以开源项目身份参与 NCCoE 项目。
8. 只在登录时校验身份必然失败：有短评指出，"仅靠模型"的护栏失败的原因与"仅在登录时做 IAM"失败的原因相同——Agent 在运行中途切换工具，而密钥还是同一把；如果只在开始时校验身份，就会漏掉第三跳时它读取的对象（即需要连续验证）。
9. 把 harness 标准与身份要求结合：有读者提到 ISO 等机构正在制定 Agent"harness"（外壳/运行框架）标准，建议将 harness 标准与身份要求整合，实现细粒度、按身份分级的访问。
10. IAM 不能只是"延伸"到 Agent：有评论认为 Agent 是概率式的，其行为无法单靠权限控制——权限控制的是"可触达范围"，而不是"Agent 拿到权限后做什么"，希望 NIST 有专门的工作体系应对。

原文链接：https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation PRIMARY_SOURCE: https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation