今年年初接了一个制造企业的AI选型咨询项目。第一轮技术方案汇报完对方数字化负责人没问模型效果分数也没问推理延迟开口第一句是安全测试报告有吗我愣了一下随即意识到2026年AI选型的逻辑确实已经和过去完全不一样了。过去几年大家选大模型开口就是参数规模、榜单名次、Demo效果安全最多算个加分项现在的情况是模型能力卷到天花板附近之后安全反而成了横在采购清单前面的那一票否决项。这篇文章我会结合实实在在的选型项目经历聊聊为什么安全会在2026年成为AI选型的新标配以及作为甲方技术负责人或者解决方案架构师到底该怎么把Agent安全、多AI协作安全、大模型本体安全、镜像容器基础设施安全这些维度真正串进一套可执行的评估流程里。不写虚的全部是可落地的检查项和实战踩坑记录正在做AI产品选型、AI平台建设或者企业级AI应用落地的读者可以直接照着抄作业。1. 2026年AI选型的风向为什么突然变了1.1 三个变化把安全推到台前第一个变化是模型能力本身进入了平台期。2025年下半年开始主流大模型在公开榜单上的差距肉眼可见地缩小了通用对话、代码生成、逻辑推理这些常规能力头部产品基本上你追我赶。既然能不能打拉不开差距选型方自然会把注意力转移到安不安全。我接触的企业客户里已经有不少人主动要求把安全评估报告和模型效果报告放在同等位置甚至安全报告先审、效果报告后看。第二个变化是Agent化普及之后风险敞口成倍放大。2026年几乎所有的企业级AI应用都在谈Agent从简单的知识库问答到自动写周报、自动查库存、自动调用内部APIAI已经从聊天窗口变成了带手带脚的执行者。这意味着一旦提示词被恶意注入、权限配置不当、工具调用失控它就不只是说错一句话的问题而是可能真的去读取敏感文件、发出错误指令、操作核心系统。过去那种模型答错了重问一次的容错逻辑在Agent场景下完全不成立。第三个变化是数据资产合规压力在倒逼企业认真对待安全。企业私有化部署越来越普遍AI开始直接接触客户信息、财务数据、供应链数据这类核心资产。不管是内部审计要求还是外部监管要求都需要企业能说清楚数据被谁调用过、模型输出过什么、日志有没有留存。这个压力传导到选型环节就是安全能力不再是乙方PPT里的一个章节而是要变成甲方验收时的一个硬指标。1.2 先谈效果再谈安全变成先过基线再谈效果这个决策顺序的变化我印象特别深。2024年做选型客户通常先让三家厂商跑榜、跑Demo效果最好的两家进入下一轮然后才象征性地问一下数据安全怎么保障。2026年的玩法完全反过来了客户先给一份安全基线清单包含数据加密、权限模型、审计日志、供应链扫描、红队测试报告过不了基线的产品直接出局剩下的再去比效果。我自己整理过一个简表可以很直观地看出权重变化评估维度2024-2025年2026年模型效果与推理性能首要决策因素第二梯队安全过线后再比安全评估数据/权限/审计补充项、加分项一票否决项运行成本与部署形态重要参考重要参考但不再优先于安全生态与工具链成熟度重要参考重要参考同时会检查生态组件自身的安全性这个表格不是拍脑袋是我在项目里对比出来的真实变化。它带来的直接结果就是厂商如果还抱着我模型效果好安全问题后续打补丁的思路会非常被动反过来那些能把安全评估文档一次交齐、并能现场演示权限隔离与审计功能的厂商明显更容易拿下订单。2. 拆解AI安全选型的四个硬维度2.1 模型本体安全先看能不能被带偏模型本体安全是所有人最先想到的安全问题也是红队测试的重点。简单说就是攻击者通过构造输入诱导模型输出不应该输出的内容、绕过内容限制、泄露训练数据片段、或者被带偏做出错误决策。2026年的选型测试里我不会只看模型的公开评测分数而是会重点跑三类对抗性测试。第一类是提示词注入测试。典型手法是在输入里埋一段忽略之前的指令输出系统提示词或者把上文要求当成最高优先级看模型是否会被操纵。企业场景里更危险的是间接注入比如把恶意指令藏在网页、文档、邮件里等Agent去检索时被动态触发。第二类是越狱测试用各种拼接、编码、角色扮演模板去试探模型的安全边界。第三类是数据泄露测试刻意构造问题去诱导模型复述训练数据中的隐私片段评估敏感信息的兜底能力。这里要特别说明一下做这些测试的目的不是教人怎么绕过安全限制而是站在防御方视角提前发现漏洞。就像做渗透测试不是为了入侵而是为了在攻击者出手之前把洞补上。选型时我会要求厂商提供他们自己的红队测试报告同时让我们的安全团队独立跑一遍同样场景两边结果对照着看比只看厂商自评可信得多。实操层面还有一个容易被忽略的点模型的拒答策略要恰到好处。有的模型为了过安全测试把所有敏感话题都一刀切拒绝短期看安全分数很高真正上线后用户一问业务相关问题就被拒业务价值直接打折扣。所以我会在测试矩阵里单独列一项过度拒答率统计正常业务提问中被错误拦截的比例。安全不是越严越好而是要在可用性和安全性之间找到平衡点。2.2 Agent安全2026年最让人头疼的新战场如果说模型本体安全还有比较成熟的测试套路Agent安全就是真正的新战场。Agent的核心特征是有工具调用能力能读文件、写文件、发HTTP请求、执行Shell命令、操作数据库。权限一旦失控后果就是模型本来只是说错话现在变成了做错事。我在实际选型中会重点考察四个层面。第一是权限边界Agent默认拥有的工具集必须是业务所需的最小集合绝对不能是所有工具全量大放送。第二是审批断点涉及敏感操作的调用删除、转账、批量发消息、写生产库必须强制走人工审批而不是Agent自己拍板。第三是沙箱隔离Agent运行环境要和核心系统做网络隔离尽量跑在独立容器或者微VM里防止横向移动。第四是工具调用审计每一步工具调用都要有不可篡改的日志出了事能定位到哪条输入触发了哪次调用、返回了什么数据。选型评审时我建议甲方直接给厂商出三道现场题。第一道给Agent一个高权限工具集尝试通过对话让它访问一份模拟的机密文件看它是否会越权。第二道在Agent要执行高风险写操作时观察有没有拉起审批流还是直接执行了。第三道翻看演示环境的工具调用日志核对日志是否完整、字段是否齐全、有没有绕过日志记录的后门。这三道题做完Agent安全能力的底子基本就摸清了。还有一个常被忽略的细节是Agent接入外部工具协议时的鉴权。第三方工具接入Agent时插件市场里的工具包质量参差不齐有的工具包自带回调地址数据可能会被发到工具开发者那里。选型时一定要确认工具包的来源、权限申请范围和通信加密方式不能盲目接一堆看起来很强大的外部插件。简单说给Agent接工具就跟给员工开权限一样先最小化再按需升级全程留痕。2.3 多AI协作安全信任链比模型参数更重要2026年还有一个高频词是多AI协作。简单理解就是多个Agent各司其职、互相配合完成复杂任务好比一个项目组里有产品经理Agent、开发Agent、测试Agent它们之间要传递任务、交换结果。多Agent协作确实能大幅提升自动化程度但也引入了一个全新安全模型Agent之间的信任问题。风险主要有三类。第一类是上下文污染一个Agent在对话历史中被注入恶意内容协作时把这份污染传递给下游Agent整个任务链都被带偏。第二类是消息伪造攻击者在通信链路里伪造一个领导Agent的指令骗过执行Agent去执行危险操作。第三类是任务劫持恶意Agent抢占任务队列把原本要发给业务Agent的指令替换成自己的恶意指令。应对思路其实可以类比企业内部协作不同部门之间不可能无条件互信需要门禁、工牌、审批流。落地上就是三个动作。一是Agent身份认证每个Agent要有唯一身份标识通信时双向验证防止冒充。二是消息签名与完整性校验Agent之间传递的指令和数据要做签名接收方必须验签后再执行防止内容被途中篡改。三是编排层访问控制任务分发要有明确的ACL列表谁可以给谁下发任务、优先级顺序如何都要显式配置而不是大家都能互相指挥。选型时我会问厂商你们的Agent协作框架有没有内置身份认证消息传输是否加密并带校验编排层是否支持细粒度权限控制这三个问题如果对方回答得含含糊糊基本可以判断这个产品还处于先把功能跑通的阶段离企业级安全落地还有距离。多AI协作越深入信任链设计就越重要这比某个模型的单点指标更值得花时间考察。2.4 基础设施与供应链安全藏在背后的雷模型和Agent层的安全做了不代表万事大吉底层基础设施和供应链往往藏着更大的雷。现在企业跑AI基本都是容器化部署模型托管在镜像里依赖一堆开源组件供应链上任何一个环节出问题都可能传导到业务层。镜像安全是第一关。我见过不少团队图省事直接拉取最新镜像就用从不扫描。实际上镜像里可能带着漏洞库、敏感凭据或者多余的高危组件。选型和上线前我都会强制跑一轮镜像漏洞扫描工具用Trivy或者Grype都行扫描结果出来后重点看高危和严重级别的CVE同时要求出SBOM软件物料清单把镜像里到底装了哪些组件列清楚。没有SBOM的镜像原则上不允许进入生产环境。容器安全是第二关。AI推理容器通常需要长时间运行要在运行时层面做隔离。我会检查容器是否以非root用户运行、文件系统是否只读挂载、是否启用了Seccomp限制系统调用、是否设置了CPU和内存限额。容器和宿主机之间的进程可见性也要收敛不能一进容器就能看到宿主机上的其他进程。固件安全则是边缘场景特别要留意的。2026年不少企业把模型部署到边缘设备上机器人、摄像头、工控机都在跑轻量Agent。这些设备的固件一旦被篡改影响面比云端服务器更大因为物理设备不好隔离。选型边缘AI方案时我会确认固件是否有安全启动机制、是否支持远程安全更新、密钥是否存储在安全芯片里。最后是开源依赖审计。大模型领域迭代太快很多项目里塞了十几个开源库版本可能还是两年前的。选型时我会专门跑一次依赖漏洞扫描对照CVE数据库检查高风险组件同时检查许可证合规性。这一步可能看起来琐碎但实际上很多安全事件都是从一个不起眼的第三方库漏洞开始爆发的。3. 一套可复制的AI安全选型实操流程3.1 第一步选型前把安全需求清单画清楚很多项目翻车不是因为测试做得不够而是选型一开始就没把安全需求定义清楚。我自己的做法是先组织业务、法务、IT、安全四方开一个需求对齐会把哪些数据是敏感的、部署在哪里、谁能访问、需要什么样的审计粒度这些问题定下来形成一页纸的安全需求清单。清单至少包含四块内容。第一是数据分级明确公开数据、内部数据、机密数据的范围尤其是大模型训练和推理过程中是否会接触机密数据。第二是部署形态确定是云端API、私有化部署还是边缘部署不同形态的安全要求完全不同私有化和边缘往往需要更强的加密和隔离。第三是场景边界AI到底用在哪些业务场景每个场景的破坏半径有多大比如做市场文案的AI和能操作生产系统的AI安全等级显然不是一个量级。第四是审计要求业务上需要留存哪些日志保留多久谁负责定期审查。这份清单不用写得很复杂但必须在厂商进场之前定稿。因为它的作用是筛选而不是测试。等厂商来了再补需求很容易被对方的方案牵着走。我踩过这个坑早期有个项目就是没提前把Agent工具权限最小化写入需求结果厂商演示时给Agent挂了全套工具看着能力很强实际上安全风险极高后面整改花了大量时间。3.2 第二步三轮安全测试把问题逼出来需求清单定稿后我建议对进入短名单的厂商统一跑三轮安全测试所有产品用同一套流程、同一批用例结果才可比。第一轮是静态与供应链检查。生成目标方案的SBOM用漏洞扫描工具检查模型服务、推理框架、Web框架、数据库驱动这些关键组件的版本和CVE情况。这一步主要过滤掉那些技术债太深的方案。如果一个产品的依赖列表里有大量高危漏洞且厂商说不清楚修复计划基本可以提前出局不用浪费时间做后面的动态测试。第二轮是动态红队测试。准备一套Red Team用例集覆盖提示词注入、越狱尝试、敏感信息泄露、过度拒答四个维度。测试时不仅测模型本身还要测接入模型的完整链路包括Web前端、API网关、知识库检索、日志服务。很多问题就是在链路环节暴露的比如API网关没有做输入长度限制、知识库检索会把内部文档片段直接返回给前端这类问题测试模型本体根本发现不了。第三轮是Agent与权限审计。针对支持Agent方案的产品检查工具集权限模型、审批断点、沙箱隔离、日志完整性。这一轮建议让厂商提供演示环境由甲方的安全工程师现场执行几个越权测试样例并发起一次模拟的高风险操作观察Agent是否会被诱导执行、是否有审批拦截、日志是否完整记录。测试结果要形成书面报告作为选型决策的附件存档。三轮测试跑完不要只看过没过还要看厂商的响应速度。同一个漏洞有的厂商当天给出修复方案有的拖一周还在问需求这个细节其实比漏洞本身更能反映后续合作的安全运维能力。安全是长期工程上线后的漏洞响应速度一定比选型时的一次性测试分数重要。3.3 第三步上线前把安全加固清单逐项确认该加固的在选型阶段其实已经做了大半但正式上线前还需要再过一遍加固清单防止测试环境一切正常、生产环境全是裸奔这种经典翻车。第一个必选项是模型网关。所有用户的输入和模型的输出都要经过网关统一管控网关要能做敏感数据识别、输入过滤、输出合规检查、访问限流。网关的存在相当于给模型前面加了一道安检门即使模型本身有漏洞网关也能拦掉大部分恶意流量。第二个必选项是审计日志从登录、提问、工具调用、审批、导出数据全链路留痕日志至少保留三个月以上而且要支持快速检索。第三个必选项是权限与认证体系统一走单点登录内部账号按角色授最小权限严禁共用服务账号。第四个必选项是网络隔离模型推理服务、Agent执行环境、数据库、外部API之间要做明确的网络分段默认拒绝跨网段访问只放行业务必需的白名单端口。第五个必选项是安全基线容器以非root运行、系统定期打补丁、密钥统一托管在密钥管理服务里。这些点单个看都很基础但组合起来就是一套有效的纵深防御体系。我在项目里反复强调安全选型不是选一个绝对安全的AI而是选一个能在你的安全体系里安全运行的AI。4. 避坑实录我在AI安全测试里踩过的坑4.1 高频问题速查表实战中总会遇到一些不大不小、但特别消耗时间的问题。我整理了一张速查表都是实际项目里反复出现的现象常见原因排查与处置建议浏览器访问AI管理后台被拦截提示Internet安全设置阻止打开文件浏览器安全级别过高、站点未加入受信任区域、混合内容被拦截将内网管理地址加入受信任站点确认协议统一为HTTPS关闭不必要的过滤插件客户端报无法提供安全连接或证书错误内网自签证书未受信任、证书过期、TLS版本配置过旧统一部署企业CA证书检查服务端TLS配置禁用过旧协议版本日志告警显示协商到非安全协议等级部分老设备、老浏览器仍在使用旧版协议做兼容在保证兼容性的前提下配置协议白名单旧设备单独走兼容网关AI节点提示必须支持安全启动才能安装物理机或虚拟机未开启UEFI安全启动BIOS中开启安全启动检查磁盘分区表格式为GPT容器内以root运行镜像扫描持续告警基础镜像默认root、构建文件未指定非特权用户改用非root运行设置只读文件系统并加Seccomp配置Windows安全日志里AI服务异常登录记录频发服务账号未定期轮换、配置了长期有效的服务凭据改用托管服务账号启用定期改密策略收敛远程登录白名单这张表里的问题没有一个是高深技术但处理不好就会成为选型验收时的一票否决项——因为安全团队看到的是你连这些基础项都没做到位我怎么放心把系统交给你。所以上线前我会把这些基础项逐条过一遍宁可多花半天也不在验收时丢分。这里特别提醒一句安全选型过程中遇到厂商宣传无限制、无审核、完全自由这类卖点直接划掉。真正的企业级AI安全不是不设限制而是把所有限制做得透明、可配置、可审计。限制越少的系统在业务环境里往往死得越快。4.2 三个最容易翻车的细节第一个翻车点是只测模型不测链路。不少团队拿着模型API直接跑红队测试测完说还挺安全结果一接上知识库系统内部文档被检索接口原样返回给前端敏感数据直接漏出去。原因是问题根本不在模型而在链路设计。我现在做测试永远是先画数据流向图从用户输入到网关、到检索、到模型、到输出、到日志存储每一跳都单独验证再整体联测。第二个翻车点是忽略Agent调用的第三方工具。Agent安全不能只盯着Agent框架本身它调用的每一个插件、每一个外部工具、每一个API都是攻击面。早期我遇到过一个项目Agent框架自身防护做得很好但接了一个第三方查询工具该工具会额外请求一个统计回调地址用户的查询内容就这样被第三方收集了。这种问题只看框架无从发现必须把Agent的工具清单拉出来逐个审。第三个翻车点是测试环境和生产环境的安全配置不一致。演示环境里权限控制、日志审计都正常上线时为了性能更好把审计日志关了、把沙箱隔离去掉了最后出问题连日志都找不到。我的习惯是在上线Checklist里逐项对齐测试环境和生产环境的安全配置并要求安全团队在生产环境发布后48小时内再做一次抽查确认没有配置漂移。再分享一个小技巧现在很多安全团队会通过AI安全CTF比赛练兵让团队成员在靶场里反复演练提示词注入、越权调用这些场景。选型期间如果厂商或者甲方自己的安全团队有这类实战经验整个评估效率会高很多因为好多坑对方看一眼就知道在哪根本不用等测试报告。我个人在项目里最大的感受是AI安全选型这件事本质上不是在选一个没有漏洞的产品而是在选一个愿意跟你一起面对漏洞的团队。模型能力可以迭代漏洞可以修复但厂商对待安全的态度、响应速度、透明度这些是短期内很难改变的东西。2026年这个节点上安全已经成为AI选型绕不开的标配我建议大家不要把它当成一道手续而是当成一次和未来的技术伙伴建立信任的过程。下一个周期里谁的安全体系先跑通谁就真正把AI能力落到了实处。