2026-05-11 06:37:53 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： CSAAISMMv3.7企业AI安全成熟度模型提供了五级成熟度框架（L1初始至L5高效）和12个安全域的分层实践路径。核心发现包括：L2需建立基础制度与资产台账，L3实现标准化流程与注册表，L4强调平台化运营与自动化联动，L5聚焦持续治理。建议企业根据风险等级选择目标层级，中大型企业应以L3为基线，高风险行业需达L4，并需避免仅关注提示词注入等单一风险。 综合评分： 87 文章分类： AI安全,安全建设,技术标准,解决方案,安全运营

cover_image

CSA AISMM v3.7：企业AI安全成熟度模型的结构、标准与实践路径

原创

林之冰寒林之冰寒

Security for AI

2026年5月10日 10:30 韩国

在小说阅读器读本章

去阅读

0x01 AISMM在描述什么

1. 基本结构

通过控制目标按等级分布如下

AISMM的详细控制从L2才开始。按照这个设计，L1只能说明企业已经在使用AI，还没有形成可审计的AI安全能力。

2. 12个安全域如何划分

这12个域分成三组

1）基础域 Foundational Domains

Governance
Organization Management
IAM
Security Monitoring

这一组决定企业有没有统一管理AI的能力

2）结构域 Structural Domains

Infrastructure Security and Resilience
Model Security
App Security
Data Security

这一组覆盖AI系统本身，包括基础设施、模型、应用、数据四层

3）程序域 Procedural Domains

Risk Assessment
AI Dev and Supply Chain
Privacy and Compliance
Incident Response

这一组负责让体系持续运转，重点落在风险评估、研发与供应链、合规、应急响应

0x02 五级成熟度怎么理解

L1：Initial

这一阶段的常见特征如下：

员工和开发者自行选择AI工具
依赖厂商默认配置
没有AI专项制度
没有AI资产可见性
没有围绕模型、Agent、RAG、提示词、工具调用建立差异化防护

判定标准可以理解为，企业已经在使用AI，但安全侧没有专门控制目标，没有登纪，没有审批，也没有审计证据

L2：Repeatable

L2是开始纳入监管的起点。这一层共有24条控制，主要要求包括。

建立AI可接受使用政策
明确AI采购与上线审批责任人
建立基础AI资产发现与台账
企业AI应用接入SSO与MFA
对主要AI项目执行初始风险评估
对RAG数据源、向量库、日志留存设定最低要求
在事件响应计划中加入AI相关内容

L2的达标标准可以归纳成三点

有书面制度，政策、审批、基线要求都存在
有对象台账，知道哪些AI服务、应用、模型、数据源在运行
有最低控制面，身份、日志、数据源、供应商、事件响应已经纳入管理

L3：Defined

L3是真正进入体系化建设的分界点。企业到了这一层，需要从零散动作转向标准化管理。

典型要求包括：

建立AI Council或AI CoE
建立权威AI部署注册表
建立按角色划分的AI培训体系
对AI开发助手、模型、数据源、供应商建立统一准入要求
MCP和Tool调用使用OAuth与命名scope
Prompt、Response、Agent Action接入SIEM
AI基础设施采用IaC与标准基线
模型版本固定，供应链纳入库存管理
关键AI应用在CI/CD中执行专项安全检查

L3的判断重点是标准化、注册化、可追踪

L4：Capable

L4开始进入平台化运营阶段。此时关注点已经从单个控制项扩展到全链路一致性。

主要要求包括：

多云、多平台一致性策略
AI-SPM、CSPM、CNAPP、SIEM、SOAR之间形成联动
Agent身份、委托链、工具授权进一步细化
用中央AI Gateway管理生产流量与策略
对模型进行签名、来源证明、对抗测试、漂移告警
对RAG启用权限感知检索
合规证据自动采集
根据威胁情报更新响应规则

这一层的重点，在于控制是否已经贯穿部署、运行、监测、审计、处置全过程。

L5：Efficient

L5对应高度自动化与持续治理阶段，代表能力包括：

治理证据和例外处理自动流转
AI服务发现结果自动进入风险流程
Agent使用JIT临时凭证
多Agent委托链校验
高危AI事件自动遏制
RAG源持续状态监测与投毒扫描
AI-BOM、依赖、漏洞情报联动
合规仪表板和监管变化影响分析联动

这一层的重点是自动化已经进入主流程，人工更多承担审批、监督和例外处理工作。

0x03 12个安全域解读

1. Governance

这一域共有10条控制，重点包括以下几点

GOV-02.1 企业AI可接受使用政策
GOV-02.2 AI采购和重大部署审批权
GOV-03.1 AI用例目录与provider、data mapping
GOV-03.2 权威AI部署与应用注册表
GOV-04.2 高风险AI用例伦理与安全评审
GOV-05.1 自动化治理证据与例外管理

实践标准

明确允许使用哪些AI、哪些数据可以进入哪些模型、谁负责审批上线
所有生产AI应用都在注册表中留痕
对高风险场景执行单独的伦理、安全、合规评审

最佳实践有

设立跨部门AI治理机制，至少覆盖安全、法务、隐私、研发、业务
用用例目录管理典型场景，并映射模型、数据等级、上线条件
治理要求要能进入技术控制，不停留在文档层面

2. Organization Management

这一域处理企业级AI可见性与统一管理。

实践标准

识别企业在用的AI SaaS、PaaS、代码助手、Agent平台
明确允许的平台与禁止路径
对主要云上的AI服务设置组织级策略限制
用独立账户、订阅或项目隔离AI工作负载

最佳实践包括

用账单、DNS、CASB、IdP登录记录、终端日志数据做交叉发现
对GitHub Copilot、Cursor、Claude Code等工具执行企业级配置与审计
尽早建设AI-SPM或云原生策略能力，避免只有发现能力，没有控制能力

3. IAM

IAM是AISMM中非常重要的一块，它把Agent、MCP、Tool、委托链都纳入身份体系。

实践标准通常有包括

人员访问企业AI应用统一走SSO与MFA
AI工作负载使用独立NHI，禁止共享人类凭证
MCP和Tool接口使用OAuth与细粒度scope
Agent授权与用户授权分离，形成双身份链路
高阶段引入JIT临时凭证和多Agent委托校验

最佳实践为

把用户意图、Agent身份、资源访问串成完整审计链
对高风险工具调用采用默认拒绝策略
把Agent身份生命周期纳入CI/CD和上线审批流程

4. Security Monitoring

这一域关注AI相关日志、监测与检测能力

L2保留主要AI平台调用数据
L3采集Prompt、Response、Agent Action
L4增加端到端委托链审计与AI专项检测
L5加入自动响应和跨部署行为基线

实践标准蛀牙有

日志覆盖身份、模型调用、工具调用、上下文来源、输出结果、异常事件
敏感数据做脱敏或分级留存
日志进入SIEM，不能只留在厂商后台

最佳实践为

Prompt与Response日志和DLP规则联动
为Prompt Injection、越权工具调用、异常Token消耗、越界检索建立检测规则
让IR团队能够直接读取AI取证所需日志

5. Infrastructure

AI基础设施需要重视

实践标准

AI开发、训练、生产环境分离
AI承载主机纳入漏洞管理
通过IaC供应AI基础设施
训练与推理网络隔离，并控制出站
高阶段引入运行时安全、零信任、机密计算

最佳实践

把模型服务、向量库、推理网关、任务队列视为AI重点面
对能够访问模型权重、系统提示词、长期记忆的组件设更高隔离等级
基础设施韧性评估同时覆盖prompt、agent config、memory store等状态组件

6. Model Security

模型需要作为生产组件纳入管理

实践标准

建立模型清单与预部署评审
固定生产模型版本
跟踪模型安全性、鲁棒性、漂移、偏见与异常输出
对自托管模型执行签名、加载校验、来源证明
模型变更进入CI/CD与变更门禁

最佳实践

把模型切换视为高风险变更
区分模型本体风险与应用集成风险
对开源模型重点核验来源、许可证、已知安全问题和行为稳定性

7. App Security

AI应用层往往直接暴露在攻击面上

实践标准

建立AI应用清单，并记录AI专属风险字段
对高暴露应用设置guardrails与prompt separation
Tool采用allowlist
高风险Agent运行在沙箱
使用中央AI Gateway管理生产流量
对Agent执行边界施加确定性约束

最佳实践

测试范围覆盖系统提示词边界、工具执行边界、记忆污染、跨租户上下文
把AI Red Team与常规应用安全测试结合，区分问题所在层面
对具备写权限、外部工具调用能力、内部知识库访问能力的Agent提高审批门槛

8. Data Security

RAG与训练数据是AI攻防中的重点区域

实践标准

RAG数据源有库存、审批、分类
向量库必须认证、加密、默认拒绝公网暴露
新数据源接入前执行敏感数据扫描
启用权限感知检索
输出执行敏感信息过滤
高阶段增加引用、源状态监测、投毒与对抗样本扫描

最佳实践

把谁能检索什么内容前移到检索层处理
对外部知识源、网页抓取源、第三方文档库建立信任等级
为训练集、微调集、RAG语料分别设独立安全检查流程

9. Risk Assessment

供应商、模型、业务场景都需要单独评级

实践标准

建立AI provider registry
项目启动前完成AI风险评估
用统一方法评估供应商
对开源与第三方模型做来源和许可评估
供应商模型更新、条款变化、事故披露时触发再评估

最佳实践包括

为风险评估设置SLA
将AI风险分级结果同步到企业应用风险登记库
对frontier model版本切换建立快速评审通道

10. AI Dev and Supply Chain

AI时代的SDLC需要扩展

实践标准包括

开发者只使用批准的AI编码助手
配置企业版隐私与训练退出选项
建立AI组件库存，覆盖模型、库、MCP、Agent、外部服务
通过包代理和版本固定控制依赖
在CI/CD中加入AI专项SAST、SCA、策略检查
生成AI-BOM或ML-BOM

最佳实践包括

把AI生成代码风险纳入常规代码审查与安全门禁
重点关注LangChain、transformers、agent framework、MCP server等高频组件
将模型、提示词模板、工具schema一并纳入版本管理与审计

11. Privacy and Compliance

AI合规不能只看隐私声明

实践标准包括。

每个生产AI部署都要识别适用法规
明确模型和数据集许可证
涉及个人数据的AI部署执行AI专项PIA
对外部AI应用准备AI-CAIQ或等效材料
高阶段实现自动化证据采集与监管变化影响分析

最佳实践包括。

将合规证据与部署注册表绑定
将EU AI Act、行业监管、州法、合同义务一起纳入规则视角
对高风险AI单列审核流程，不与普通SaaS审批混用

12. Incident Response

AI事件响应需要单独成册。

实践标准包括。

在企业IR计划下增加AI专项附录
保留Prompt、Response、Identity、Tool Invocation等取证线索
建立Prompt Injection、数据泄露、Agent劫持、Tool滥用等专项playbook
引入Break-Glass、SOAR自动遏制、规则回灌

最佳实践包括。

演练至少覆盖一次恶意提示词到工具越权再到数据外传的完整链路
响应人员预先具备日志、部署、身份、模型登记的只读权限
取证日志应具备防篡改能力，便于事后重建过程

0x04 这份模型关联了哪些具体标准

AISMM大量引用现有标准和框架。主要有

1. 治理与管理体系

CSA AICM
CSA AI-CAIQ
NIST AI RMF
ISO/IEC 42001

这一组适合用来建设制度、职责、评估方法和管理体系

2. 攻击面与技术防护

OWASP Top 10 for LLM 2025
MITRE ATLAS
NIST SP 800-207 Zero Trust

这一组适合做威胁建模、检测规则、授权设计

3. 研发与供应链

NIST SSDF
NIST SP 800-218
CycloneDX ML-BOM

这一组适合处理AI研发过程、依赖库存、构建与发布安全

4. 隐私与监管

GDPR DPIA
NIST Privacy Framework
EU AI Act
行业规则如HIPAA、GLBA、PCI-DSS、SR 11-7

这一组适合处理个人数据、高风险AI、行业监管和客户证明要求。

0x05 企业至少应该做到哪一层

最低合格线：L2

对刚开始大规模使用AI的企业来说，最低应达到L2

L1连资产都不清楚
没有审批、分类、日志，很难应对审计与事件调查
对客户、内审、法务、监管都缺少基本说明能力

推荐基线：L3

对大多数中大型企业来说，L3才是可运营的起点。因为到了这一层，企业已经具备了一下几点：

治理企业
标准化准入
权威注册表
关键日志集中管理
初步供应链与模型管理
项目级风险评估

如果企业已经上线RAG、Copilot、Agent、AI Coding Assistant，建设目标通常不应停留在L2。

高风险行业建议：L4

金融、医疗、云平台、数据密集型SaaS、跨境业务企业，更适合把目标设在L4，原因包括以下几点

需要自动化证据
需要一致性策略
需要细粒度身份控制
需要中央网关
需要运行时监测
需要更快的事件响应

L5适用场景

L5更适合以下企业

AI使用范围很广，内部有大量Agent自动执行任务
多云、多团队、多地区并行
审计、监管、客户证明要求较强
具备建设自动化平台的能力

0x06 常见误区

误区1：把AI安全理解为提示词注入防护

提示词注入很重要，但它只是攻击链中的一个环节。更常见的高风险组合包括。

提示词注入加Tool过权
提示词注入加RAG越权检索
模型升级加策略失配
开发助手泄露代码
Agent审计链断裂

误区2：只看模型安全，不看应用安全

很多问题出在应用编排、工具调用、身份边界、数据授权和日志缺失，不出在foundation model本身。

误区3：只看合规条文，不看运行证据

AI合规最终要落到证据上。没有注册表、没有日志、没有策略执行记录，制度很难证明已经落地。

误区4：把AI开发工具排除在治理范围之外

AI Coding Assistant、Code Review Agent、MCP Server都在改变代码流、构建流和密钥暴露面，不能只盯生产应用

原表格下载链接：

https://wwaop.lanzn.com/iC9D73p4vwcd

密码:guxj

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Security for AI 林之冰寒林之冰寒《CSA AISMM v3.7：企业AI安全成熟度模型的结构、标准与实践路径》