智能体五阶段生命周期框架:TC260 首份 Agent 部署使用安全指引解读(2026.7)
TC260《智能体部署使用安全指引》把 Agent 安全拆成评估、准备、部署、使用、停用五个阶段,标志着治理重点从内容安全走向运行时安全。
2026年7 月,全国网络安全标准化技术委员会秘书处发布《网络安全标准实践指南——智能体部署使用安全指引(v1.0-202607)》。这份文件的重点,不是讨论大模型如何生成安全内容,而是围绕智能体在 评估、准备、部署、使用、停用 五个阶段中的部署使用风险,给出一套安全基线。

文件中的“智能体”,特指面向个人助手场景、需要用户授予较高权限、基于大模型的软件系统。也就是说,它关注的不是普通 ChatBot,而是能够调用工具、使用技能、访问文件、连接网络、执行任务的 Agent。
这也解释了为什么文件没有只谈内容安全,而是重点讨论安装物料、部署环境、权限控制、日志审计、高风险操作、长期记忆、凭证回收和停用清理。

01 评估阶段
先判断能不能用,再判断用哪个
评估阶段主要发生在智能体部署使用之前。核心问题不是“这个 Agent 能不能跑”,而是“这个场景是否真的需要 Agent,以及这个 Agent 是否具备基本安全条件”。

a)明确使用目的和业务场景。
使用前应先明确任务目标、业务场景和工作范围,评估是否有必要使用智能体完成相关任务。不是所有任务都适合交给 Agent,低风险文本处理可以使用普通大模型应用,不一定要引入具备执行能力的智能体。
b)了解智能体能力边界和安全风险。
使用者应预先了解智能体的技术特性、能力边界、安全风险,以及开源智能体和商业智能体的主要差异。Agent 一旦接入文件、工具、插件、API 或内部系统,其风险就不再只是模型输出风险,而是执行层风险。
c)谨慎选择智能体方案。
文件建议优先选择由提供方同时提供智能体和配套安全防护能力的成套方案,慎重选择缺乏安全防护措施的开源项目。商业方案通常安全机制更完整,但要关注数据、接口和供应商责任边界;开源方案更灵活,但要重点评估维护状态和安全能力。
d)检查项目维护状态。
存在超过一个月无维护记录且有未解决安全问题、公开安全问题长期未获响应、存在未修复高危漏洞、提供方明确停止维护等情况的智能体项目,不应选择。
e)优先选择具备基础安全机制的智能体。
文件建议优先选择集成安全沙箱、高风险操作管控、急停控制、可回溯文件系统等机制的智能体;不应选择缺少日志审计、权限管理等基础安全机制的智能体。
f)排查重大安全隐患。
部署前还应检查智能体是否存在自动开放公网接口、强制回传运行数据等重大安全隐患。
02 准备阶段
把安装、环境、模型和防护能力提前设计好
准备阶段关注智能体安装部署前的基础条件,包括安装物料、部署环境、大模型选择和安全能力补强。

a)选择可靠安装物料。
应从官方网站、应用商店等具备明确责任主体和发布机制的渠道获取智能体安装文件、容器镜像等,不应使用网盘、论坛、即时通信群组中的修改版、二次分发版、破解版或其他不明来源物料。安装前宜通过数字签名、哈希值、校验码等方式验证真实性和完整性。
b)根据部署方式做好隔离。
如果在本地环境部署,宜使用独立设备,不宜与日常办公设备混用,并提前备份、清理或迁移敏感数据。如果在虚拟机、容器等虚拟化环境部署,应禁止其访问宿主机文件,防止风险扩散到宿主机。如果在云环境部署,应选择具备身份管理、访问控制、日志审计和安全告警能力的云平台。
c)选择合适的大模型。
应选择已通过生成式人工智能服务备案的大模型。对数据安全、隐私保护要求较高,且具备算力和技术基础的场景,宜优先采用本地化部署模型。调用外部模型服务时,应使用官方接口,不应通过不明中转站或未授权代理调用。
d)评估模型能力与安全需求是否匹配。
应根据智能体任务复杂度和安全需求,选择上下文窗口、能力边界、安全水平满足要求的大模型。上下文窗口不足可能导致 Agent 遗忘约束、误解任务状态,从而引发误操作。
e)开展安全能力差距分析。
如果所选智能体和大模型在输入输出内容安全、行为管控、身份与凭证管理、供应链安全检测、高风险操作拦截、沙箱隔离、资源消耗与成本控制等方面存在不足,应通过部署安全工具或接入安全服务进行增强。
03 部署阶段
最小权限、最小目录、最小暴露
部署阶段是整份指引中最接近工程实践的部分,重点是部署方式、插件安装、运行账户、权限配置、网络暴露、日志审计和高风险操作管理。

a)使用可信部署方式。
应根据智能体提供方的官方文档或经核验的部署脚本进行部署,不应采用来源不明的一键部署脚本。很多一键脚本会安装依赖、修改配置、开放端口、写入环境变量,一旦来源不可信,部署过程本身就可能成为供应链入口。
b)审查插件来源和权限。
需要额外安装插件的,应在安装前检查插件来源可靠性。不应安装来源不明、存在未修复高危漏洞、权限需求异常或与预期任务无关的插件。
c)禁止使用管理员权限运行。
不应使用操作系统管理员权限运行智能体。应仅授予智能体完成任务所必需的最小权限,降低越权操作和被滥用后的影响范围。
d)限制可访问目录。
应限制智能体的可访问目录范围,不应授予其访问用户主目录、系统目录等重要位置的默认权限。宜为智能体建立专用工作目录,仅将任务必需文件放入其中。
e)控制网络暴露。
智能体及相关服务应配置为仅本机可访问,不开放至外部网络。确需通过互联网访问时,应配置加密访问,并限制访问来源。
f)开启细粒度日志。
应开启智能体日志记录功能,对文件操作、指令执行、网络活动、技能调用等行为进行全量日志记录,并尽量采用最细粒度。没有日志,Agent 出现问题后很难回溯责任链和攻击路径。
g)建立高风险操作清单。
应提前定义高风险操作,并通过智能体安全机制进行二次确认或直接阻断。高风险操作包括停止系统服务、终止进程、格式化或复写磁盘、批量删除、权限修改、密钥更改、开放端口、修改防火墙规则、访问密码管理器等。涉及转账、支付等影响个人财产安全的操作,也应纳入高风险清单。
04 使用阶段
运行中要持续复查、审计和更新
使用阶段覆盖技能安全、敏感信息保护、联网行为、长期记忆、权限回收、告警处置和版本更新,是实际运行中最容易出问题的阶段。

a)复查安装与配置状态。
应检查使用者是否能够了解智能体执行状态,是否能够对其操作进行安全管理,例如配置黑名单、白名单,是否可以便捷地急停控制智能体。
b)加强技能使用安全。
应使用来源可靠的技能。对于技能,宜进行全面安全测试。未经安全测试的技能,应提前做好风险防范。技能不只是提示词模板,它可能封装任务流程、工具调用逻辑和权限使用方式,本身也是供应链风险点。
c)保护个人信息和敏感数据。
向智能体提供个人信息时,应坚持最小必要原则。涉及生物特征、家庭隐私等敏感信息,应审慎提供。未获得授权时,不应向智能体提供第三方个人信息和敏感数据,也不应提供未获许可的业务数据和涉及知识产权的内容。
d)定期检查公网接口。
通过互联网访问智能体的,应定期检查公网接口的必要性和安全性,及时关闭非必要暴露接口。
e)合法合规使用网络信息服务。
使用智能体获取网络信息服务或参与网络社交媒体讨论的,应符合网络安全相关法律法规要求。
f)做好数据备份。
宜定期对智能体运行环境中的有价值数据进行容灾备份,避免误操作、环境损坏或异常任务导致数据丢失。
g)管理长期记忆。
宜定期手动查看长期记忆文件记录内容,对不宜存储的个人信息、隐私数据、内部信息及时处理,并调整长期记忆配置策略。长期记忆会把一次性数据输入变成持久化风险,是 Agent 区别于普通模型应用的重要风险点。
h)回收敏感权限并清理历史记录。
宜及时回收敏感权限,定期清理不再使用的技能和敏感对话记录,开启多因素鉴别以保护账户安全。
i)处置告警并复查安全状态。
应及时核查处置已部署安全工具、安全服务产生的告警,并结合新的威胁信息、风险提示,对智能体部署使用情况进行复查,及时消除隐患。
j)关注安全公告和版本状态。
应持续关注智能体运营方、安全企业发布的安全公告。当出现影响特定版本的安全事件时,应根据公告采取升级、降级或版本锁定等措施,避免长期使用存在已知漏洞或已停止维护的版本。
05 停用阶段
清理残留,撤销权限,避免暗资产
停用阶段关注智能体停止运行后的数据、权限和环境清理。这个阶段容易被忽视,但对企业尤其重要。Agent 项目停用后,如果进程、端口、凭证、长期记忆、订阅服务没有清理干净,就会变成新的暗资产。

a)停止主程序和关联服务。
应停止智能体主程序,以及所有关联服务和后台进程,确认智能体已经完全退出运行状态。
b)备份需要保留的数据。
清理环境前,应对仍需保留的会话记录、配置文件、知识库文件、日志等数据进行容灾备份。
c)根据部署环境执行清理。
本地环境部署的,如果提供方配备官方卸载程序,应通过官方卸载程序卸载,并检查进程、端口和网络连接是否存在残留;如果没有官方卸载程序,文件建议重置操作系统。云环境部署的,应关闭公网访问入口,删除工作文件、知识库、日志、长期记忆、插件和技能配置,并撤销 API 密钥、服务账号凭据、第三方应用授权等。虚拟化环境部署的,宜直接停用该虚拟化环境;无法停用的,应参照本地环境清理要求处理。
d)确认订阅和费用状态。
停用后,应确认终止相关服务、取消订阅及自动续费,关注大模型接口是否产生异常费用。Agent 如果遗留 API Key 或自动任务,可能持续消耗模型调用和云资源费用。
附录 A:部署使用安全检查清单
附录 A 给出了一张部署使用安全检查清单,按照五个阶段组织检查项,并用星级标注重要性。它的作用是把正文要求转成可勾选、可审查、可落地的操作项。
对应阶段
检查项
重要性
是否完成
评估阶段
判断是否需要由智能体去解决目标工作任务
★★★
☐
整体了解智能体的有关知识
★★★
☐
对需要部署使用的智能体进行选择
★★★
☐
选择自带安全防护机制的智能体
★★★
☐
不使用存在显著不合理安全隐患的智能体
★★★
☐
检查拟部署使用的智能体项目近期动态
★★☆
☐
准备阶段
从具备明确责任主体和发布机制的渠道获取智能体安装物料
★★★
☐
选择合适的部署方式,并落实相应安全防护措施
★★★
☐
选择合适的智能体运行相关的大模型
★★★
☐
校验智能体安装物料的真实性和完整性
★★☆
☐
通过安全工具、安全服务等方式增强防护能力
★★☆
☐
部署阶段
不通过未查明来源的一键部署等便捷化脚本进行部署
★★★
☐
对智能体的网络暴露形式进行安全配置
★★★
☐
开启智能体的日志记录功能,并对该功能进行配置
★★★
☐
安装前检查插件来源的可靠性
★★☆
☐
不使用操作系统管理员权限运行智能体,最小化授予智能体的权限
★★☆
☐
限制智能体的可访问目录范围
★★☆
☐
提前定义高风险操作,并通过智能体安全机制进行管理
★★☆
☐
使用阶段
加强对技能使用的安全防护
★★★
☐
加强对自身个人信息以及敏感数据的安全防护
★★★
☐
合法合规使用智能体获取网络信息服务或参与网络社交媒体讨论
★★★
☐
对安装与配置情况进行复查
★★☆
☐
定期检查智能体公网接口必要性及安全性
★★☆
☐
定期对智能体所处环境内的有价值数据进行备份
★★☆
☐
定期手动查看长期记忆文件记录的内容并对其进行管理
★★☆
☐
及时回收敏感权限,定期清理不再使用的技能与敏感对话记录
★★☆
☐
关注告警信息并进行核查处置,及时消除安全隐患
★★☆
☐
关注智能体相关安全公告,及时采取相应措施
★★☆
☐
停用阶段
在卸载前停止运行
★★☆
☐
卸载前对需要保存的数据进行导出或转存
★★☆
☐
执行环境清理操作
★★☆
☐
附录 B:组织级安全管理指引
附录 B 面向组织内部智能体使用管理。它解决的问题不是单个 Agent 怎么部署,而是企业如何发现、登记、审计和约束内部智能体。
a)建立内部智能体使用管理制度。
组织应对智能体的部署、使用、变更等活动进行管理。制度至少包括禁止行为、使用边界和审批流程。比如,不应将组织内部数据或系统接口接入未经审批通过的智能体;应明确智能体使用范围、权限边界和数据处理边界;部署前应提交使用目的、使用边界、拟配置技能、拟接入工具、安全防护措施等信息。
b)建立智能体资产登记表。
组织应对已审批智能体进行统一登记,并在发生变更时更新。登记内容至少包括智能体名称、用途、业务归属、部署位置、IP 地址、容器名称或唯一标识、部署人、部署时间、责任人、使用的大模型名称和版本及接入方式、技能和插件列表、可访问的内部系统接口和数据范围、权限配置情况、最近一次安全审查时间和结果。
c)管理已审批智能体活动。
应对关键活动进行日志记录,包括高权限指令执行、敏感数据访问、内部系统接入、外部数据传输、权限变更、工具调用和异常操作等。组织还可以使用人工智能、规则分析或其他技术手段,对智能体行为模式进行风险分析,并周期性分析日志,及时发现和处置安全问题。
d)建立未审批智能体发现能力。
组织宜定期扫描内网中的典型智能体服务端口,分析网络流量日志以识别异常智能体通信行为,识别与已知大模型 API 端点通信的内网主机,检索安装或运行智能体相关进程的终端。这个要求本质上是在治理 Agent Shadow IT。
e)开展员工安全教育。
组织应面向员工开展智能体安全教育,内容包括提示词注入攻击、供应链安全、凭证泄露、数据泄露、越权访问、违规使用责任等。很多 Agent 风险来自使用者误以为它只是聊天工具,而没有意识到它已经具备文件访问、工具调用和账号授权能力。

这份指引释放出的三个信号
a)Agent 安全正在从内容安全转向运行时安全。
文件关注的不只是输入输出,而是文件操作、指令执行、网络访问、技能调用、权限变更、长期记忆和凭证管理。
b)技能、插件和工具会成为新的供应链安全重点。
未来评估 Agent 安全,不能只看模型,也要看它安装了什么技能、接入了什么插件、调用了哪些工具、这些组件是否可信。
c)企业需要把 Agent 纳入资产治理。
附录 B 已经明确提出资产登记、审批、日志分析、未审批发现和员工教育。这意味着企业内部的 Agent 不能再以“个人试用工具”的方式长期存在。
写在最后
这份指引的价值,不在于提出了某个单点防护技术,而在于给出了一个完整的生命周期框架。
-
评估阶段解决“该不该用、用哪个”
-
准备阶段解决“从哪里来、放哪里跑、接什么模型”
-
部署阶段解决“给多大权限、开放什么入口、记录哪些行为”
-
使用阶段解决“如何持续复查、审计和更新”
停用阶段解决“如何清理残留、撤销权限、避免暗资产”。
智能体越像一个助手,就越不能只按聊天工具管理。它越能自主执行,就越需要被纳入权限、日志、审计和治理体系。
这正是这份标准最核心的变化:Agent 安全不再只是模型安全问题,而是部署工程和组织治理问题。