随着大模型和智能体进入研发、办公、客服、投研等业务场景，企业AI安全的关注范围正在持续延伸。智能体逐步具备更强的任务规划和实际执行能力，企业除了关注模型、内容和数据安全外，还需进一步关注身份、权限、外部工具和运行行为。
从企业角度看，问题已经不只是"AI有没有风险"，而进一步变成：谁负责，按什么规则上线和使用，规则怎么验证，以及如何保持持续、有效的管控。
这些变化，推动企业AI安全治理向更加体系化的方向发展。
01
AI安全治理要求正在不断细化
2026年以来，智能体相关的政策文件、实践指南和征求意见稿陆续发布，安全治理的要求进一步细化。
5月8日，国家网信办、国家发展改革委、工业和信息化部联合印发《智能体规范应用与创新发展实施意见》，将"安全可控"作为基本原则，对权限和行为管控、安全检测与评估、供应链安全和全生命周期管理等提出要求，并强调分类分级治理。
7月1日，全国网络安全标准化技术委员会（TC260）发布《网络安全标准实践指南------智能体部署使用安全指引》，从评估、准备、部署、使用、停用五个阶段提出安全指引。7月29日，TC260就《智能体交互安全要求》《AI浏览器安全实践指南》公开征求意见，关注点延伸到智能体交互和具体应用形态。
这些文件呈现出一个趋势：AI安全治理要求正从总体原则细化到具体场景、全生命周期和实际运行过程；治理对象也从模型和生成内容 ， 扩展到智能体的身份、权限、工具、数据访问、交互关系和运行行为。
对企业而言，真正需要解决的，是如何将这些要求落实到具体治理实践中，让制度、风险评估和技术管控形成协同。
02
AI安全治理是一套协同机制：制度定规则、评估验风险、技术管控促执行
AI进入业务流程后，仅靠某一种安全手段很难覆盖完整的治理需求。制度、风险评估和技术管控解决的问题不同，三者相互支撑。
1、制度定规则，首先解决"应该怎么管"
企业首先需要明确组织职责、应用和数据使用边界、权限要求、上线审批等要求，把外部法规标准和自身风险要求转化为内部可执行、可检查的规则。
没有明确规则，评估和技术管控就缺少判断依据。例如，一个Skill需要读取文件目录，技术手段可以核查其申请或实际持有的权限，但该权限是否必要、应当允许还是禁止，仍需要结合企业权限基线和具体业务场景判断
2、评估验风险，解决的是"有没有做到"
制度要求不同业务域的数据相互隔离，就需要验证检索增强生成（RAG）是否存在越权召回或跨业务域访问，工具调用是否正确鉴权。
风险评估也应结合实际场景，从模型、基础设施、AI应用、数据和内容等层面开展验证。对于重复出现的共性风险，还应进一步分析开发规范、上线准入、权限管理等方面原因，并沉淀为制度要求、安全基线或后续评估检查项。
3、技术管控促执行，解决的是"如何持续落实"
部分治理工作可以通过人工台账和审批完成；但资产、版本和调用关系不断变化时，则需要技术手段提高规则执行、变更识别和审计追踪的持续性。技术管控不是重新制定规则，而是把既有要求转化为可执行、可验证、可追溯的控制动作。
三者不是相互替代的发展阶段，而是共同构成治理闭环：**制度提供规则与依据，评估提供风险证据与验证结果，技术管控提供持续执行能力。**在实际运行和风险评估中发现的新问题，再反向推动制度、评估基线和控制措施持续调整。
03
从Agent到Skill、MCP：智能体资产边界在变化
随着智能体能力增强，企业需要管理的对象已经不只是一个模型或一个AI应用。
这里首先明确：Agent、Skill和MCP并不是同一层级 概念 ****。****从治理对象看，真正需要管理的是Agent、Skill、MCP服务器，以及它们与模型、工具、身份和数据资源之间的关系。
Agent通常是指面向具体业务任务运行的智能应用或执行单元，背后可能涉及模型、提示词或工作流、RAG与知识库、Skill、外部工具、身份凭据和运行环境等组成部分。
本文所说的Skill，是指面向特定任务封装的可复用能力单元，可能包含提示词、工作流、工具调用逻辑和相关配置，不同平台的具体实现可能存在差异。
MCP服务器可以提供工具、资源和提示模板等能力，其中工具可以执行操作，或进一步访问API、数据库、文件系统等外部资源。MCP规范为基于HTTP的传输定义了可选的授权机制，但是否启用、主体身份与业务权限如何映射，以及后端如何完成权限校验，仍取决于具体实现和业务系统的安全设计。
所以从治理角度看，真正要掌握的不是一份"Agent清单"，而是一组彼此关联的对象和关系：Agent用什么模型，加载哪些Skill，连接哪些MCP服务器和工具，以什么身份运行，获得哪些权限，能访问 什么 数据和业务系统。这些关系直接决定Agent实际能做什么，也是判断其风险边界的重要依据。
比如一个Agent，如果Skill升级版本、MCP服务器增加新的工具，或者服务账号扩大权限，即使Agent主要业务功能没有改变，它的实际能力和安全边界就可能已经发生变化。
04
技术管控如何承接治理要求
技术管控的价值，是把明确的治理要求转化为可持续执行、可验证和可追溯的控制动作。例如，制度规定"未经审核的Skill不得进入生产环境"，技术上可以落实为：注册 → 安全检查 → 审核 → 发布 → 版本管理 → 重大变更重新审核。
如果要求Agent只能使用授权工具和数据资源，就需要维护Agent与Skill、MCP服务器、工具、账号、权限和数据资源之间的关系，并及时识别调用对象或权限变化；如果要求重要操作可追溯，则需记录Agent身份、组件、调用对象和关键操作日志。
面向智能体的技术管控，可以逐步覆盖资产注册、准入审核、安全检测、版本管理、权限与使用控制、变更管理、审计追踪和退役回收等环节。
重点不在于"有没有平台"，而在于治理规则能否在复杂、动态的智能体环境中持续生效，相关控制能否随资产、版本、调用关系和权限变化及时调整，并保持可追溯。
基于这一方向，海云安正围绕Agent、Skill和MCP服务器治理探索相应的技术支撑能力，推动资产注册、准入审核、安全检测、版本管理和审计等治理动作，与企业既有AI安全管理要求有效衔接。
05
形成与AI应用阶段相匹配的持续治理闭环
AI安全治理没有适用于所有企业的固定模板。治理深度应与业务重要性、数据敏感度、智能体自主执行能力、应用规模和关系复杂度相匹配。其中，风险应当优先于规模。
即使只有少量AI应用，只要涉及敏感数据或高风险操作，也应采取相匹配的评估和技术控制措施。随着应用规模扩大、关系复杂度提高，再逐步采用更统一、自动化的管理方式。
少量低风险的内部AI应用，可以先明确使用边界、责任主体、基本评估机制，通过人工台账和审批完成日常管理。当Agent、Skill、MCP服务器和外部工具规模化使用，版本、调用关系和权限持续变化时，再通过自动化的技术手段承接资产注册、准入审核、安全检测和审计追踪等治理工作。
所以，AI安全体系化不是一次性建设"大而全"的体系，而是根据应用和风险变化持续完善治理能力。无论企业处于哪个阶段，基本逻辑都不会改变：制度定规则，评估验风险，技术管控促执行。
最终，企业需要形成的是一套能长期运行、随AI应用持续演进的安全治理机制：规则明确，风险 可 验证，要求 可 执行，过程 可 追溯，问题可反馈并推动治理持续改进。