ITU智能体安全议程：接入权限也要进入评估

摘要

设想一个助手起初只能读取服务记录、提出处理建议，后来通过新接口获得了写入权限。它的模型版本可以完全不变，能够影响的业务状态却已经不同。旧测试没有因此失去全部价值，但“同一模型”也不能证明新增操作已经受到同样约束。

ITU的研讨会草案议程把这种区别放到了系统接入环节。第三场讨论拟考察集成方应当向智能体、工具和模型供应商要求什么安全证据。前一场关注智能体内部的机制，后一场讨论实际产品中的能力、安全和成本取舍。把三者并列，意味着内部防护、组合后的表现和现实中的代价不是同一个问题。

截至9月3日，会议尚未举行。公开邀请索引所列通知日期为7月14日，7月15日上网；当前议程页面没有说明这段具体文字何时加入。不能把一次会前议程阅读写成刚刚发布的强制标准，更不能预告讨论必将达成什么结论。

接入环境重要，并非一个新的技术发现。值得关注的是，标准化工作准备如何让不同供应商提供的证据能够被同一个部署决策使用。

NIST的身份与授权概念稿已经把问题拆得很具体：智能体取得新的工具或资源时，授权政策如何随情境改变？被汇集的数据应如何判断敏感程度？代表某人执行操作，依据的授权又是什么？这些是征询问题，不是已经验证完毕的答案。项目现状仍为审阅意见，意见征集已经结束。

证明“是谁”，不同于证明“这一步可以做”。身份真实的智能体仍可能面对不适合当前任务的权限配置；在一种工具组合下表现良好，也不等于换一组连接后仍有同样表现。NIST概念稿的初始范围以较可控的企业环境为主，明确不处理来自不可信来源的外部智能体。因此，它不能被拿来证明开放环境中的智能体信任问题已经解决。

ITU的FG-TIDA页面也区分身份与可信行动条件，同时明确焦点组技术报告、技术规范不等于ITU-T建议书。这里存在有价值的研究方向，但还没有可以代替部署判断的通用合格证明。

要求集成方负责，并不意味着供应商可以把问题全部交给客户。供应商最了解组件的版本、限制、测试条件和已知失效方式；集成方掌握连接、身份策略、数据范围和业务流程。双方都只提供自己的一半，最终使用者便可能在没有人看清整体的情况下获得操作能力。

更可行的分工，是说明哪些发现能够沿用，哪些必须在部署中补证。新增写入工具，应该重新考察受影响的操作与审批边界；不相干的界面调整，则不应自动使全部模型测试作废。这是一种按变化影响范围组织评估的建议，不是ITU已经确定的测试程序。

必要的证据也不必全部公开。任务范围、测试适用条件和负责作出使用决定的角色可以清晰说明，敏感提示、凭据、个人数据和可被利用的日志仍应受到保护。透明不等于把运行细节无差别公开。

Lu Heng在关于现实层与象征性权力的笔记中强调，不要让描述代替可执行的能力。把这个区分有限地用于智能体安全，就是不能让一个评价标签遮住系统实际拥有的权限。这不是对ITU或供应商动机的指控。

SG17的现行职责覆盖开发、部署和运行等阶段。重庆讨论的价值，将取决于后续工作能否在这些阶段之间保留证据的适用条件。会议可以帮助形成可比较的要求；真正允许哪个智能体执行哪项操作，仍须在具体系统中决定。