企业级AI落地新焦点：AI Agent身份与授权治理

近期，关于 AI Agent 安全的讨论焦点已发生显著转移：业界不再仅仅纠结于模型可靠性与内容合规性，而是将目光投向更深层的议题——即当 AI Agent 涉及系统读取、工具调用、数据访问及动作执行时，其应以何种身份接入企业体系，并接受认证、授权、审计与追责。

这种转变在 NIST 近期的一系列标准与治理举措中尤为凸显。2026 年 2 月，NIST 正式启动 AI Agent Standards Initiative，旨在推动具备自主行动能力的 AI Agent 实现可信采用、安全代表用户运行，并促进其在数字生态中的互操作性；

紧接着，NCCoE 颁布了关于软件与 AI Agent 身份及授权的概念文件，专门针对 identification、authorization、auditing、non-repudiation 以及 prompt injection mitigation 等问题展开探讨。

与此同时，OpenID Foundation 亦于 2026 年 3 月正式回应 NIST 关于 AI Agent 安全的征询，指出：AI Agent 安全的核心痛点并非单纯的技术失效，而是信任危机——即谁赋予了该 Agent 权限？它代表谁执行任务？这种委托关系能否得到验证？

从 NIST 到 NCCoE，再到 OpenID，这些举措共同指向一个趋势：AI Agent 的发展下一阶段，比拼的不仅是能力，更是其能否被安全地融入企业身份与访问控制体系。

01

AI 安全的核心，正逐步从“内容安全”迈向“行动安全”

当前许多企业仍习惯将 AI 风险局限于“内容风险”或“模型风险”，例如担忧回答准确性、是否存在幻觉、是否生成违规内容或泄露敏感信息。

虽然这些问题至关重要，但它们主要发生于“AI 生成内容”阶段。然而，一旦进入 AI Agent 阶段，风险的性质已发生改变。

因为 Agent 不仅仅是回答问题，它还能调用工具、连接系统、读取数据、执行流程，甚至在有限人工监督下自主决策并采取行动。

NCCoE 在相关概念文件中亦提及，随着企业致力于将 AI 能力从基础生成式输出拓展至实际动作执行，Agent 的自治性与规模化能力将释放新价值，同时也伴随新风险。

换言之，AI Agent 安全的关键，不仅在于防止其“说错话”，更在于防止其“做错事”。

当 Agent 能访问 CRM、查询客户数据、调用工单系统、修改配置或触发审批流程时，其风险已不再局限于内容层，而是深入至身份层、权限层、访问层及责任层。

这也是为何征求意见文件将重点聚焦于“Identification、Authentication、Authorization、Auditing and non-repudiation，以及 Prompt Injection prevention and mitigation”等领域。

这些关键词背后的含义其实非常直接：

AI Agent 究竟是谁

它如何证明自身身份

它为何拥有特定权限

其行动能否被记录与追责

它是否会在复杂输入和工具调用中被诱导偏离原本边界

02

AI Agent 时代，身份与授权的重要性将日益凸显

从 NIST 与 NCCoE 的举措来看，标准机构关注的重点已十分明确。

它们并非单纯探讨 AI Agent 的能力边界，亦非仅关注模型安全性，而是将问题推进至企业落地层面：作为会读取系统、调用工具及执行动作的数字主体，AI Agent 应如何被识别、认证、授权与约束？

NCCoE 在概念文件中指明，启动此项目的原因在于，随着软件和 AI agents 具备有限人工监督下自主决策并行动的能力，其行为规模与影响范围可能迅速扩大。

而要真正释放这种能力的业务价值，前提是 identification、authentication、authorization 等基础身份原则能被有效应用于 agents 身上。

换言之，AI Agent 价值越大，身份与授权的重要性便越高。

NCCoE 的概念文件还明确提出，希望探索基于标准的方法，用于识别、管理与授权软件 Agent，涵盖 AI Agent 的访问与行动，并为组织安全实施 AI Agent 提供实践指南。

这并非一种保守的安全顾虑，而是 AI 从“会回答”迈向“会行动”后的必然结果。

03

从 NIST 的动作中，至少可以解读出三个明确信号

从此角度看，NIST 此次单独探讨 AI Agent 身份与授权，至少透露出三个明确信号。

1、AI Agent 被视为需单独治理的新型数字主体

NCCoE 在文件中明确将项目范围聚焦于 agentic architectures，并特意排除了纯 RAG 架构及仅依赖 LLM 及其训练数据的场景。

其关注点并非一般性 AI 接入，而是那些能动态获取外部上下文、反复调用工具与资源，并可能最终采取行动的系统。

换言之，标准机构真正担忧的并非只能回答问题的模型，而是能进入业务链路、参与系统交互、具备执行能力的数字行动者。

2、AI Agent 风险正从模型输出转向身份、授权与行动边界

过去几年，企业谈论 AI 安全时，常将重点置于训练数据、输出质量、提示词攻击等问题；但当一个 Agent 能读取 CRM、调用工单系统、触发数据库查询甚至发起流程动作时，风险已不再停留在“说错话”，而是进入“做错事”层面。

若 Agent 拥有访问能力、工具调用能力和流程触发能力，却遭遇过度授权、身份错误绑定，或在复杂上下文中发生越权调用，其影响可能远超普通脚本，且更难被第一时间察觉。

NCCoE 将 auditing、non-repudiation、delegation、least privilege 等问题摆上台面，本质上是在提醒企业：未来 AI Agent 的关键治理点不在回答层，而在访问层、授权层及责任层。

3、AI Agent 落地倒逼 IAM、API 授权、工作负载身份及审计体系升级

该概念文件未尝试为 AI Agent 另建一套全新身份体系。相反，其明确将 OAuth 2.0/2.1、OIDC、SPIFFE/SPIRE、SCIM、NGAC 以及 Zero Trust、数字身份指南等已有标准与实践纳入讨论，并提及 MCP 已将 OAuth 用于 agentic access 授权。

背后的方向已十分清晰：AI Agent 治理不会绕开现有 IAM 和 API 安全体系，而是将这些原本重要的能力推向企业 AI 落地的更前沿。

未来企业需管理的，不仅包括员工账号和应用账号，还包括越来越多能行动、能协同、能代表用户完成任务的“非人类”身份。

04

行业外部声音亦趋一致：AI Agent 身份治理，正成为生产落地的前提

行业外部声音亦朝同一方向收敛。

OpenID Foundation 在回应 NIST 关于 AI Agent security 的征询时，将核心问题概括得十分直接：谁授权了该 Agent，它代表谁行动，这种关系能否被验证。

这实际上将 AI Agent 安全问题进一步推向“信任关系”与“委派关系”层面。

在传统企业系统中，身份关系通常较为清晰：员工使用账号登录，应用通过固定凭证调用接口，系统间通过预设权限完成交互。

但在 AI Agent 场景中，这种关系变得更加动态化。

用户可能先向 Agent 发起自然语言任务；Agent 根据任务目标调用多个工具；工具继续访问不同业务系统；系统返回新上下文后，又可能影响 Agent 的下一步决策。

此时，企业真正要验证的，已不仅是“账号是否真实”，而是完整的委派关系：

该 Agent 是否真的被用户授权？

它是否仅能代表该用户在特定范围内行动？

它调用工具时，工具能否识别其真实身份及代表关系？

系统能否区分“用户本人操作”与“Agent 代表用户操作”？

当多个 Agent、多个工具、多个组织协同时，信任链条是否仍可验证？

OpenID 同时提醒，许多当前部署方式仍依赖手工维护的访问列表、未签名凭证及责任链不够清晰。在小规模试点中，这些做法似乎尚能运转；但一旦进入跨组织、跨系统、跨工具协同场景，问题便会迅速放大。

也正因如此，AI Agent 身份治理并非“以后再说”的增强项，而是正成为企业能否将 Agent 真正带入生产环境的前提。

05

真正值得关注的，非某一份文件，而是治理重心已变

若将 NIST 与 NCCoE 的动作置于更长的时间线上，这场变化值得关注的并非某一份文件本身，而是背后治理重心的转移。

标准机构当前讨论的，已非仅“AI 模型如何更安全”，而是“会行动的 AI 如何被纳入组织的身份、权限与责任体系”。

这意味着，未来企业衡量 AI Agent 是否成熟，看的可能不仅是其能做多少事，而是其是否可被识别、授权、限制、审计及追责。

谁先想通这套底层问题，谁的 AI 落地就更可能从试点走向规模化。

谁继续将 AI Agent 简单理解为“更聪明的自动化”，谁就更容易在真正接入系统后发觉：最难补的并非模型能力，而是身份与访问控制底座。

06

派拉观点：AI Agent 安全落地，需AIGS一体化安全治理底座

在企业级 AI 落地过程中，派拉软件认为，AI Agent 安全治理至少需具备以下关键能力：

1

Agent 身份识别能力

企业需为不同类型的 AI Agent 建立可识别、可管理、可追踪的身份，而非让 Agent 混用员工账号、系统账号或长期密钥。

2

Agent 认证与可信接入能力

Agent 在调用工具、访问系统、连接数据时，需能证明自身身份，并让被访问系统识别其