摘要

  • NIST 将以 DevSecOps 项目作为首个实施用例，展示如何在软件开发周期内识别、认证并授权 AI 智能体。
  • 该机构称已收到 600 多份意见，披露 Gemini 协助审阅和归纳意见；消费者拥有的智能体将留到后续阶段。

NIST 已选出第一处测试场景，但还没有公布最终项目设计。NIST 在9 月 29 日公告中表示，首个实施用例将借助其安全软件开发（DevSecOps）项目，展示如何在软件生命周期内识别、认证和授权智能体。

这一步建立在 2 月发布的概念文件和后续征询上。意见摘要称，NIST 收到来自行业、政府和学界的 600 多份反馈。参与者讨论的身份不只是给智能体一个名称，还涉及其工作负载、运行环境、授权它的个人或组织，以及它在具体时点拥有什么权限。摘要称，多数意见倾向于沿用并扩展现有身份标准，而非另起一套体系；但技术选型和信任模型并未形成共识。NIST 说，下一份项目说明草案还会就范围、用例、架构和标准再次征求意见。

这份摘要也说明了整理过程：Google 的 Gemini 协助语言润色、审阅和概括意见；NIST 作者表示，他们核查了文中的主张和结论。文件没有说 Gemini 选择了 DevSecOps。公告将首个用例归于项目团队，并称这项安排依据所收到的反馈。把两件事分开看很重要：一件是摘要如何辅助编辑，另一件是机构由谁决定先验证什么。

企业软件工厂相对容易划定边界。组织能够管理智能体、运行环境、凭证，以及它可访问的代码库和服务。这能让测试先观察：现有身份机制能否把具体权限与软件开发任务绑定。但仍要看清智能体可以执行哪些动作、代表谁执行，以及授权能否被审查或撤销。证明“它是谁”并不能自动回答“它能做什么”。

消费者控制的智能体则面对另一种关系。它可能代表个人访问企业服务、使用用户提供的凭证，或者跨越多个组织各自管理的系统。NIST 摘要收录了相关疑问：服务方怎样区分真正获得授权的代理与只是声称代表用户的程序？项目页面仍在滚动收集反馈；它没有把 DevSecOps 用例描述成已完成的标准，也未将其设为行业义务。

先后顺序限定了首批证据能说明什么。NIST 的资料将企业软件开发放在第一阶段，消费者拥有或控制的智能体则安排在之后。前者可以检验组织内的身份、权限和审计做法，却不足以证明独立智能体如何向无关服务方证明授权。NIST 表示，其他用例仍待界定，下一份项目说明将再进入公众反馈环节。

600 多份反馈说明参与规模不小，却不是决定项目范围的投票。NIST 保留项目排序和测试条件的决定权，反馈提供的是材料和意见。2 月的概念文件当时询问，实操型项目是否能帮助组织把身份与授权做法用于软件智能体。9 月公告把工作推进到首个实施演示，但没有确定最终架构或更广泛的用例。

下一个公开关口是项目说明草案，NIST 预计会列出拟议范围、用例、架构和标准。该机构还安排在 10 月 28 日举行线上研讨会，介绍身份和 DevSecOps 两个项目。在草案问世前，不能把这次试点说成普适的智能体身份框架、认证体系或已采纳的技术规则。