1. AI安全正在变成“主赛道”但传统手段已经带不动了1.1 为什么多模态AI把安全问题的复杂度直接拉爆这两年大模型一路从纯文本卷到图文、音视频再到能自己调用工具、操作软件的AI智能体整个行业都在追“多模态”这个概念。但说实话大多数人关注多模态是因为应用效果好、交互体验强而站在安全的角度看多模态带来的不是简单的“多几种输入格式”而是把整个安全评估的复杂度直接拉爆了。先说个最简单的例子。纯文本模型时代我们检测恶意输入主要看的是提示词层面的注入和越狱一句话进来跑一遍规则或者分类器基本能拦住大部分问题。但到了多模态阶段一张图片里可以嵌入肉眼看不见的对抗扰动一段语音里可以藏人耳听不出的引导指令甚至一帧视频画面里的一小块像素区域就能让模型产生完全不同的行为。输入通道多了攻击面就呈指数级增长。更麻烦的是多模态交互会带来信息交叉验证的问题。比如给模型看一张看起来完全无害的图片但配合一段文字提示图片里的物体语义就完全变了模型可能在毫不知情的情况下把原本禁止的行为当成合法指令执行。这种跨模态的语义重组攻击传统的规则引擎和内容审核几乎是完全无效的。也正因为如此我在看到“AI安全公司悬镜原创多模态AIST新品——问境AIST发布”这个消息时第一反应是行业终于开始做正经的多模态AI安全基础设施了而不是继续拿着文本安全的老一套去硬套多模态场景。1.2 传统内容安全/规则引擎卡在了哪里很多团队聊AI安全第一反应还是内容审核过滤色情、暴力、政治敏感词拦截辱骂言论加上一些关键词黑名单和安全提示词库。这套方案在移动互联网时代确实够用但在大模型时代处处是漏洞。规则引擎最大的问题有三个。第一是可穷举性失效。关键词库是有限的但攻击者的话术是无限的。同一个攻击意图可以有十万种变体更有无数绕过方式比如谐音、拆字、拼音、表情包、双层编码。你永远堵不完因为规则库的更新速度远追不上攻击样本的生成速度。第二个是上下文缺失。规则引擎只能看到局部文本无法理解完整的对话语境和意图链路。一个词单独看是安全的放在特定上下文里就是攻击指令一段话单独看是正常的结合前面的对话历史就变成了越狱输入。没有上下文理解能力就没有真正的安全判断力。第三是模态孤立。传统内容安全对图像、音频、视频的处理基本是各管各的图像用图像分类器文本用文本过滤器。但在多模态AI的场景里攻击者恰恰可以利用模态之间的转换缝隙——比如将恶意指令通过图片里的文字传入或者用音频里的特殊指令触发模型行为。模态之间没有统一的安全分析视图就永远存在“漏网之鱼”。1.3 悬镜为什么要在这个时间点推出“问境”悬镜做软件供应链安全和DevSecOps在业内已经扎根很多年了积累了大量代码审计、漏洞检测、风险治理的能力。但今年的形势已经很明显——大模型不再只是聊天机器人而是深入到业务系统、操作系统、工具链里的“准生产力设施”。安全如果还停留在应用层、不深入到模型层那卡口就会漏掉最大的风险变量。从一个从业者的角度看问境AIST这个产品名称里其实能读出两层意思。“问境”两个字可以理解为“询问AI的安全之境”也就是对AI系统进行主动探测和深度拷问而后缀“AIST”按AI安全测试的通用逻辑来理解对应的是AI安全测试与评估体系AI Security Testing Assessment。换句话说这不是一个外挂式的过滤器而是一套针对AI系统本身的检测评估基础设施。现在这个时间点做发布也是很典型的行业信号释放——大模型已经在千行百业跑起来安全事故开始密集出现监管侧对AI安全的要求也在快速收紧。谁先拿出真正适配AI原生产物的安全评估能力谁就掌握了下一阶段的市场话语权。2. 问境AIST的分层探索多模态AI安全测试的产品化思路2.1 AIST到底测的是什么模型层、数据层、应用层很多朋友一听到“AI安全测试平台”下意识会觉得就是个给大模型打分的评测工具。但实际上真正要支撑企业安全运营AI安全测试必须形成分层体系。以问境AIST这类产品通常会覆盖的范围来看大致可以分成三个层面。模型层评估的是模型自身的安全素养。这里面既包括基础的对抗鲁棒性——也就是给模型加一点点微小扰动比如图片改几个像素它会不会被诱导产生错误输出也包括对齐安全度——模型在多大比例上能抵抗住越狱提示词的攻势。这个层面的测试在训练阶段和上线前应该反复执行相当于对模型本身做一次“安全出厂质检”。数据层主要查的是大模型的记忆安全和数据合规风险。多模态大模型会学习海量图文、音视频数据这些数据里是否包含敏感个人信息、商业秘密、违规内容模型在生成时是否会“记起来”并复述出来都是安全底线问题。更隐蔽的是数据投毒——攻击者在训练数据里植入特定样本让模型在特定触发词下输出恶意结果这种深度后门在常规黑盒测试里极难发现。应用层则是把模型放到真实业务场景中去测。一个系统集成AIGC客服、多模态内容生成、知识库问答以后攻击者会不会通过外部接口绕过安全限制会不会利用提示词注入套取系统内部知识会不会借助模型工具调用链发起间接渗透这些是上层应用风险。所以你会发现一个好的AI安全测试平台本质上是要用一组测试资产和检测引擎把这三层风险都覆盖住。如果只测模型本身而不管数据层和应用层那安全评估依然是残缺的。2.2 多模态安全检测的技术路径对抗样本、越狱、投毒、隐私再往下拆问境AIST这类产品要做多模态安全检测至少要覆盖四条核心技术路径。第一条是对抗样本检测。多模态模型的视觉、语音模块大多依赖深度学习网络这类网络天然容易受到对抗扰动影响。评估人员需要构造出既让人感知不到差异、又能让模型输出失控的对抗样本来检验模型边界。这项工作难度在于一方面是攻击样本生成本身另一方面是检测响应速度你总不能在用户已经收到错误结果后再给出告警。第二条是跨模态越狱测试。这是多模态AI安全区别于文本AI安全最明显的地方。测试系统得像一个经验丰富的攻击者那样组合使用图片、文字、语音、视频观察模型能不能被“绕进去”。比如一个常规文本攻击被拦截换成把恶意指令写进图片的OCR区域模型会不会照单全收再比如让模型“看图说话”完成一个任务任务本身是合法的但结果导向是不安全的这种隐性风险能不能被识别出来第三条是投毒样本检测与追溯。针对数据投毒需要构建专门的探测任务链通过设计特定的触发词、触发行为来反向判断模型内部是否存在异常记忆。这一块涉及的数学方法和数据工程很深但落地上最关键是样本库构建——没有足够丰富且带标签的恶意样本库投毒检测就无从谈起。第四条是隐私泄露评估。多模态模型拥有记住训练数据的能力这也意味着它可能在生成时泄露训练集中的个人信息。系统需要通过精心设计的探针问题、成员推断攻击等手段测评模型对私密信息的“记忆强度”并给出风险等级。这四条路径在一个产品里并不是孤立运行的而是会形成一套集成的检测编排流程先给模型做静态体检再上动态攻击测试最后汇总出综合风险评估报告。2.3 闭环设计测试、修复、复测、持续监测市面上不少安全测试工具的问题是“测完就完了”测试报告出了但风险是否修复、修复后有没有引入新问题一概不管。真正到了生产环境这远远不够。问境AIST这类做平台级产品的方案大概率会强调一个闭环测试—修复—复测—持续监测。具体拆开来看流程是这样的。首次评估后系统输出多维度的风险报告包括严重程度、受影响的模态类型、复现步骤、修复建议等。开发团队拿到报告后对模型进行微调或对齐加固再提交复测。复测阶段系统不仅要验证原问题是否消除还要做回归测试——确保针对旧漏洞的修复没有减弱原有能力也没有引入新漏洞。通过复测之后才进入持续监测阶段也就是定期自动扫描配合新出现的攻击样本做增量评估。这个闭环的价值在于把AI安全从“一次性验收动作”变成“持续运营能力”。我见过太多团队上线前找了外部红队测一轮测完很兴奋三个月后模型迭代了五六版当年测出的问题早就不适用了新引入的风险又没人管。真正有运营思维的团队应当把AI安全当成一个长期工程持续投入。3. 从“测试工具”到“安全体系”评估一个AI产品不能只看红队报告3.1 安全评估对象边界模型、Agent、应用系统聊到AI安全评估很多人第一反应是“我的模型够不够安全”。但模型安全只是起点不是终点。问境AIST作为一个以AIST命名的产品其评估对象边界应该明显大于单一模型。现在业界讨论最热的方向之一是AI智能体AI Agent。智能体的特点是能自主规划、调用工具、执行任务比如让智能体帮忙订机票、操作数据库、写代码、打理后台系统。这种产品形态的安全风险已经远远超出“输出内容是否合规”而是涉及“行为是否可控”“越权操作是否能被阻断”“决策链路是否可审计”。所以在评估一个AI产品时至少要划分三个评估边界。第一是模型底座——无论是开源模型还是闭源API模型本身的对抗鲁棒性和对齐安全度是先决条件。第二是Agent编排层——智能体如何解析任务、如何选择工具、如何执行每一步动作在哪个环节可能被误导或劫持。第三是外部系统交互面——AI系统对外输出指令、调用API后会不会对业务系统造成实际损害。拿这半年业界频繁提醒的“间接提示注入”来说攻击者不需要直接与被攻击的AI对话而是把恶意指令隐藏在网页内容、文档、邮件中AI在处理正常任务时读到这些内容就被劫持了。这种风险只测模型本身是发现不了的必须从应用系统层面做完整的链路测试。3.2 衡量检测能力的几个核心指标如果你是企业方正在考虑引入AI安全测试平台那么有几个核心指标值得特别关注。这些指标也是我评估这类产品时习惯用的参考维度。覆盖率是最容易被低估的指标。一个平台的测试覆盖不光是看模板数量有多少更要看它覆盖了多少种攻击手法、多少个安全风险类别、多少种输入模态。比如文本攻击涵盖不涵盖多轮越狱、角色扮演式诱导图像攻击涵盖不涵盖对抗贴纸、语义混淆音频攻击涵盖不涵盖隐藏指令、语音伪造检测精度取决于误报和漏报的平衡。安全产品最容易犯的毛病是宁可错杀不可放过——检测结果全是高危告警但人工复核后发现八成不相关这种“狼来了”式的高误报比不检测还可怕会让团队迅速产生告警疲劳最终真的高危机告警来了也没人看。可解释性是很多平台容易忽视、但实际使用中极为重要的一点。检测系统不光要告诉我“这个模型有风险”更要告诉我“为什么有风险、攻击路径是什么、触发样本是什么、修复方向在哪”。没有可解释性的测试企业只能拿到一个分数却不知道该如何改进。可扩展性和自动化程度决定这个平台能不能融进研发流程。能不能集成进CI/CD流水线能不能在每次模型更新后自动跑一轮安全回归能不能与既有漏洞管理系统打通这些看似“工程细节”的问题实际上决定了安全平台是能常态化运作还是仅仅做个孤立的测试玩具。3.3 企业落地AI安全评估的四个步骤具体到企业怎么把AI安全评估这件事落地我建议分四步走这也是我们跟客户推方案时最常采用的路径。第一步理清资产清单。把公司所有正在使用、正在研发的大模型和AI系统盘点出来明确每个系统的数据流向、权限边界、对外暴露面。这一步看起来基础但实际执行时很多公司连自己有多少个AI实例都没完全搞清楚。第二步建立安全基线。选一套覆盖了模型、数据、应用三层的安全评估体系对现有AI系统做一轮全量基线评估。不要追求一轮全绿那不现实关键是摸清现状排出优先级。第三步融入研发流程。把AI安全评估从“上线前的一次性测试”变成开发流程里的必备环节模型训练完成之后、部署到生产之前必须跑一轮自动化安全检测。这一步至关重要因为大模型行业更新迭代实在太快了不建立流程安全就跟不上版本节奏。第四步持续运营与回溯。建立检测记录基线每一次版本迭代都做一次安全对比及时发现新的风险增量。持续运营的意义不仅是防守也是在积累数据——长期的安全检测记录反过来能为业务侧提供模型安全能力的客观依据。4. AI智能体安全度量L1-L5分级框架与AIST的关系4.1 智能体分级的意义安全评估也要“分级”最近行业里讨论得比较密集的一个话题是“通用型AI智能体L1-L5分级安全框架”。这个框架概念参照了自动驾驶的分级思路把AI智能体的能力层级与安全要求做了一一对应。这种分级思路的好处是让安全评估不再是一刀切而是能根据智能体的自主程度来匹配不同的检测深度和控制强度。简单梳理一下L1级别大致对应基础辅助工具型AI人主导、AI执行具体指令这种场景下安全重点是内容合规和数据隐私到了L3级别AI开始具备一定的规划和记忆能力可以自主完成多步任务这时候就要重点评估决策链路透明度和越权操作风险而L5级别的完全自主智能体人只剩下监督权安全评估的重心就要全面转向系统鲁棒性、价值对齐、紧急熔断机制等深层能力。这个分级框架的现实价值在于一个只做到L2的客服机器人和一个目标做L4的自动驾驶决策系统安全评估的要求完全不是一回事。硬套同一套标准要么该严的没有严起来要么过度建设浪费资源。4.2 分级框架怎么和AIST检测能力进行映射如果问境AIST这类平台要跟L1-L5分级框架深度配套那么它的检测能力应当跟分级维度形成清晰映射。L1-L2这个区间系统需要重点检测的内容包括基础内容违规、提示词注入、数据泄露、越狱攻击等偏向传统AI安全测试技能到了L3需要叠加工具调用安全、多步推理任务中的误导检测、权限边界验证以及跨模态攻击在任务链中的传导L4-L5则要上升为行为级安全评估——不只看“单个回答安不安全”而是看“智能体完成整个任务链条时会不会做出有害行为”。我个人的判断是未来真正一流的多模态AI安全平台一定会在产品里内置这种分级能力映射逻辑。企业方只需要告诉平台“我的智能体当前设计目标大概是哪个级别”平台就应该自动适配对应的测试策略和评估指标体系。这种分级自适应机制是把安全评估从“技术服务”变成“治理工具”的关键一步。4.3 谁适合先上L4/L5的安全评估铺垫这么多抽象概念后说说落地。如果你所在的公司还在做普通内容生成型AI产品那现阶段老老实实把L1-L2的风险点堵住就行不用急着上重武器。但以下几个方向我认为应该尽早启动高等级安全评估。第一类是金融决策辅助类智能体。这种AI需要访问用户资产信息、交易权限一旦被注入攻击操纵后果极其严重。这类系统至少应当按照L3偏L4的标准去做评估。第二类是代码生成与运维自动化智能体。代码生成本身风险已经不小如果智能体还能直接提交代码、操作运维平台攻击面就从“生成错误建议”升级成了“可以对生产系统造成实际影响”安全等级必须拉满。第三类是深度接入企业核心业务系统的通用助手。这类智能体往往拥有包括邮件、文档、OA审批、CRM等系统的多处权限权限越广被劫持后的危害越大。它不一定是L5级别但按L4级别的深度来做安全评估能有效降低企业整体的攻击暴露面。5. 给实战团队的建议多模态AI安全项目落地避坑指南5.1 最容易踩的三个坑在做AI安全评估项目的过程中我发现团队最容易踩的坑有三个而且基本都是“心态”问题。第一个坑是把AI安全当成合规负担。很多项目是监管要求来了、客户招标条件变了才临时启动安全评估。这种心态下做出来的测试基本走形式——报告能交差就行风险是否真正闭环没人管。但攻击者不会因为“合规已完成”就不打你。第二个坑是过度依赖单一检测方案。有些团队认为买了先进的AI安全平台就万事大吉了。但现实是任何平台的测试用例库都有边界真正的攻击思路是活的。我的建议是平台检测与内部红队、外部众测结合使用三者互为补充才可能形成立体防护。第三个坑是忽视多模态数据的伴随风险。很多团队在整理多模态训练数据时只关注了数据的数量和质量没关注数据本身是否携带敏感信息。比如从互联网抓取的图片数据集里是否包含真实人脸、车牌号、门牌号码、内部文档截图这些数据如果没有做清洗和脱敏模型训练完以后天然就是一个隐私泄露风险源。安全评估一定要在数据准备阶段介入而不是等模型上线后亡羊补牢。5.2 数据与环境的准备工作如果你正打算启动一次AI安全测试前期准备工作里最关键的一块是测试环境搭建。安全测试不宜直接在真实生产环境上做因为对抗样本和攻击载荷可能在测试过程中引起系统的非预期行为影响线上业务。正确的做法是搭建一个独立的影子环境拷贝模型副本、搭建同等配置的服务链路并把测试流量和真实流量隔离。如果需要测试Agent类系统还需要准备好模拟业务服务和仿真工具避免智能体在测试中真的操作了外部系统。测试数据集这块也建议提前花大心思。好的安全测试不全是自动生成的攻击模板还需要一批人工梳理的高质量种子样本这些样本必须结合你自身业务场景来构造。比如你做的是医疗健康问答攻击样本就应该围绕疾病误导、就医诱导、隐私套取等场景设计而不是拿通用攻击包直接跑。5.3 我对这个赛道的一点个人判断写到最后聊聊自己的感受。从悬镜推出问境AIST这个动作能明显感受到AI安全正在从“细分赛道”变成“基础设施赛道”。前两年讨论AI安全大家关注的是模型会不会说错话、会不会泄露数据现在讨论到多模态AI和智能体安全话题已经变成了系统能不能在复杂任务链中保持可控、决策过程能不能审计、跨系统操作能不能阻断。我个人觉得这类AIST产品的价值不是在“检测越多越好”而是在“真正帮助组织和开发团队建立起安全的底线思维”。安全不是拖慢创新的绊脚石而是在模型能力不断增强、自主程度不断加深的进程中确保创新不会失控的刹车系统。刹车不是为了不跑而是为了跑得更稳、跑得更远。问境AIST这类产品后续的演进方向大概率会从“检测工具”走向“安全运营底座”——也就是说它不仅仅是帮你发现风险更应该在风险处置、策略下发、模型加固、持续监测整个链条上形成能力。对于已经深度应用大模型、并且对安全有刚需的团队来说现在开始搭建AI安全评估能力时间不算早但也绝对不算晚。