企业 AI 安全预警:LLM 微调 + RAG 藏数据泄露风险,微软提出访问控制新方案
本文探讨了大型语言模型(LLM)在企业多用户环境中的安全风险,特别是微调过程和检索增强生成(RAG)技术可能导致的敏感数据泄露问题。研究发现,现有防御措施(如输入净化、输出过滤和差分隐私)均无法提供确定性保护。作者提出以细粒度访问控制为核心的安全框架,要求微调数据和RAG检索内容必须对所有交互用户可见。该方案将模型安全转化为访问控制问题,通过双团算法实现安全微调,并在推理阶段严格验证用户权限。目前
大型语言模型(LLMs)正越来越多地应用于企业场景,在此类场景中,模型需与多名用户交互,且训练或微调过程会用到敏感的内部数据。微调虽能通过内化领域知识提升模型性能,但也带来了关键安全风险:机密训练数据可能泄露给未授权用户。当大型语言模型与检索增强生成(RAG)流程结合时,这类风险会进一步加剧——RAG 流程在推理阶段会动态获取上下文文档。
本文展示了针对人工智能助手的数据泄露攻击:攻击者可利用当前微调与 RAG 架构的缺陷(即缺乏访问控制机制),实现敏感信息泄露。研究表明,现有的防御手段(包括提示词净化、输出过滤、系统隔离及训练级隐私保护机制)本质上均为概率性方法,无法为抵御此类攻击提供可靠保护。
本文主张,唯有在微调阶段和基于 RAG 的推理阶段,均确定性且严格地实施细粒度访问控制,才能可靠防止敏感数据泄露给未授权接收者。为此,我们提出一个以“大型语言模型在训练、检索或生成过程中使用的所有内容,均需获得交互中所有用户明确授权” 为核心原则的框架。该方法为构建安全的多用户大型语言模型系统提供了一种简单却极具变革性的范式—— 它以经典访问控制为基础,同时适配现代人工智能工作流程的独特挑战。目前,该解决方案已部署于微软 Copilot 微调(MicrosoftCopilot Tuning)产品中,企业可通过该产品使用自身特定数据微调模型。
大型语言模型(LLMs)正日益融入企业工作流程,为代码补全、文档生成、邮件撰写等任务提供支持,例如通过 Cursor AI、微软 Copilot、谷歌Gemini Advanced 等现代人工智能生产力工具实现上述功能。
这些工具常部署于多用户企业环境中,而此类环境中的数据受严格访问控制机制保护,该机制与单个用户的权限绑定。为提升人工智能工具的有效性,企业通常会采用基于内部数据训练或微调的模型—— 这些内部数据敏感度各异,且通常按部门或用户形成数据孤岛。尽管微调能融入宝贵的领域特定知识,但也带来了关键风险:机密信息可能泄露给未授权用户。
基于敏感信息(如人力资源记录、内部政策或高影响力业务战略)微调的模型,在用户与人工智能工具交互、向模型发起查询时,可能会无意间泄露此类信息,尤其在用户权限不均的环境中风险更高。更严重的是,此类泄露不仅可能通过针对性提取攻击发生,还可能在日常交互(如撰写邮件或向助手查询个人及共享文档)中无意间发生。多个业务部门的反馈表明,数据泄露风险及缺乏可靠安全控制,仍是企业采用人工智能工具的主要障碍。
当微调后的模型与检索增强生成(RAG)流程结合时,上述风险会进一步放大。在这类系统中,用户提示词会结合基于查询上下文检索到的文档进行扩充,从而提升响应质量。然而,若检索机制未对交互中所有用户严格执行访问控制列表(ACLs),则可能将受限内容引入模型上下文,导致未授权信息泄露。例如,假设爱丽丝使用基于RAG 的工具起草给鲍勃的邮件回复:若未对爱丽丝和鲍勃的访问控制列表(ACLs)进行妥善配置,恶意的鲍勃便可利用检索过程泄露敏感数据 —— 他可在邮件中嵌入隐藏指令,再通过隐写术解码模型的响应内容。更令人担忧的是,即便鲍勃的incoming 邮件及助手的输出均经过人工审核,此类攻击仍可能成功。
本文主张,在企业等多用户环境中安全部署大型语言模型,必须确定性且可验证地实施细粒度访问控制。这与概率性防御手段(如输入净化、输出过滤、系统级隔离及训练级技术)形成鲜明对比—— 尽管这些概率性方法有一定作用,但由于缺乏严格的端到端保障,本质上无法满足安全需求。我们倡导一项简单且可靠的原则:RAG 流程与微调模型必须在处理的每个阶段实施访问控制,确保模型输出中包含的所有内容,均已获得所有目标接收者的访问授权。
通过将大型语言模型的数据安全问题重构为基于原则的访问控制问题,我们提出了一种新的设计范式 —— 该范式优先考虑可审计性和可验证的安全保障。同时,我们还提出一个框架,说明如何在微调阶段及RAG 流程的推理阶段均实施访问控制。
概述:首先,我们将证明,若未对微调数据和微调模型访问实施确定性保护,微调后的模型易受数据提取攻击,而现有防御手段无法缓解此类风险。随后,我们将介绍支持访问控制的微调模型——在这类模型中,微调过程会继承底层训练数据的权限与访问控制列表(ACLs)。具体而言,我们严格规定:用户仅在有权访问微调所用全部数据的前提下,才能获得对微调后模型的访问权限。若简单地将企业内所有受细粒度访问控制保护的私有数据用于微调,可能导致最终模型无用户可访问(或仅有极少数用户可访问)。为解决这一问题,我们将训练数据选择与模型授权用户选择的联合问题,转化为在二分图中寻找双团(bicliques)的问题。目前,我们的初步解决方案已部署于微软Copilot 微调产品中,客户可通过该产品使用敏感数据微调模型。最后,我们将研究多用户场景下大型语言模型辅助系统在推理阶段的信息泄露问题,并探讨如何通过实施确定性访问检查,为消除信息泄露提供系统性解决方案(第4 节)。关于数据泄露攻击、现有防御手段及其局限性的相关研究,将不再单独设节阐述,而是融入相关章节及场景的讨论中。
针对微调模型的数据提取攻击
微调是指以预训练机器学习模型(如大型语言模型)为基础,在规模较小的任务特定数据集上继续训练的过程。通过微调,模型能适应特定应用或领域的细微需求与要求,从而提升在该场景下的性能。企业可利用微调技术,基于自身私有(且通常敏感)的数据打造定制化模型—— 例如,利用内部代码库实现代码补全,或依据公司特定模板生成文档。尽管检索增强生成(RAG)技术能在推理阶段为模型提供应用特定上下文,但研究表明,微调在将领域知识嵌入模型方面效果更优。因此,RAG更适合作为辅助手段支持微调后的模型,而非替代微调。此外,微调可减少推理阶段所需的上下文量,从而降低推理成本。
尽管微调为企业场景带来了巨大价值,但也引入了独特的安全风险。由于员工对敏感数据的访问权限通常存在差异,微调后的模型可能会无意间暴露受限信息,进而成为数据泄露的潜在攻击向量—— 已有研究表明,模型可能通过推理输出泄露训练数据。
微调模型导致的内部数据泄露
考虑以下场景:某企业使用内部数据微调模型 M,其中包含员工鲍勃无权访问的敏感信息 D。若之后向鲍勃开放对微调模型 M 的访问权限,鲍勃可能会在与模型交互的过程中(无论有意或无意)提取D 中包含的特权信息,导致内部数据机密性受损或数据泄露。例如,假设 D 包含完整的人力资源数据(如薪酬政策),而鲍勃是非人力资源部门员工,无权访问这部分信息。若模型M 基于 D 微调,则可能会在推理阶段向鲍勃隐含编码并潜在泄露这些敏感人力资源政策,从而绕过已建立的访问控制机制。
此类泄露源于微调的核心目标:通过内化训练数据分布的特征提升模型性能。尽管已有研究证明模型在推理阶段可能会记忆并逐字复述敏感训练数据,但本文需强调,即便不存在精确记忆,数据泄露仍可能发生。模型对受限训练信号的泛化能力,可能导致更隐蔽的泄露形式(如以改写方式披露敏感内容)。需特别注意的是,本文所讨论的敏感信息范畴不仅限于个人身份信息(PII),还包括对业务至关重要的数据(如内部政策、战略计划或机密部门沟通内容)——这些数据在不同组织单元内的访问权限通常是受限的。若模型基于来自多个此类单元的数据微调,且未实施访问控制,则会实质上打破内部数据孤岛,导致企业内所有用户(无论其授权级别如何)均可访问受限信息。
目前存在多种旨在获取训练数据相关信息的攻击方式,包括可直接提取训练数据的基于查询的攻击,以及用于判断特定数据是否属于训练集的成员推理攻击。令人担忧的是,研究表明,随着当前大型语言模型在规模上的发展趋势—— 无论是模型尺寸增大还是训练数据集扩大,模型的记忆能力都会随之增强。这在多用户场景下构成了严重风险:若基于受访问控制保护的数据微调的模型对所有用户开放访问权限,数据泄露风险将显著升高。关键在于,数据泄露不仅可能通过针对性攻击发生,还可能在合法用户的正常交互中无意间发生。因此,基于敏感数据微调的模型必须被视为潜在的数据泄露源。
现有防御机制的不足
尽管存在上述风险,现有防御机制仍无法有效防止敏感微调数据泄露 —— 在企业场景中尤其如此,因为企业的微调数据往往包含复杂、结构化的信息,远超可记忆的事实或个人身份信息(PII)的范畴。根据干预阶段的不同,防御策略可大致分为三类:(1)数据中心式方法,通过预处理微调数据降低泄露风险;(2)输出级方法,对模型预测结果进行事后净化或过滤;(3)训练级技术,通过修改学习过程或损失函数提升模型抗泄露能力。
数据中心式方法旨在通过微调前对训练数据进行预处理或净化,降低泄露风险。N 元组去重通过消除重复序列减少模型记忆,数据清理技术则专注于移除个人身份信息(PII),混淆方法通过注入噪声干扰输入分布。尽管这些技术能降低模型记忆特定数据点的可能性,但无法提供任何形式化保障。此外,在企业场景中—— 微调数据通常包含敏感的结构化信息 —— 这些方法不仅效果不足,还常常难以适用。
输出级方法侧重于在推理阶段对模型输出进行后处理或控制,以降低敏感信息泄露风险。置信度掩盖等技术通过向模型输出注入噪声,隐藏可能被记忆的内容,但往往会在降低泄露风险的同时损害模型可用性,且无法提供可靠的泄露防护保障。数据防泄漏(DLP)工具试图通过模式匹配或基于规则的分类,检测并阻止个人身份信息(PII)、受保护健康信息(PHI)或财务数据等敏感内容的暴露。然而,数据防泄漏(DLP)方法存在根本性局限:它们无法判断模型对特定用户(如鲍勃)的响应,是否源自该用户无权访问的训练数据。关键问题在于,这类方法无法追踪从训练数据到特定模型输出的细粒度信息流。
通过修改训练过程以降低信息泄露的方法,包括正则化和差分隐私(DP)。正则化技术旨在减少过拟合,从而限制模型记忆单个训练样本的倾向。然而,在本文关注的场景中——目标是防止模型学习企业内大规模的隐性敏感信息 —— 应用正则化技术需要过度激进的正则化策略,这会严重损害模型对授权用户的可用性。差分隐私为限制信息泄露提供了一种更形式化的方法:若一个随机算法在处理仅相差一个数据点的两个数据集时,输出分布保持相似,则该算法被认为满足差分隐私。尽管差分隐私在概念上具有吸引力,但在大型模型微调场景中存在诸多局限。首先,即使是满足差分隐私的训练算法,也允许有限度的信息泄露(由隐私参数ε 衡量),而要维持模型可接受的可用性,ε 值往往需要设置得较大。其次,标准差分隐私仅能保护单个数据样本。但在实际场景中,企业敏感数据可能涉及相关的记录组,而某一用户可能无权访问所有这些记录。要保护此类大规模信息,需要采用组差分隐私,这会进一步增加隐私预算ε,导致模型可用性下降到无法实际部署的程度。
小结
在多用户场景中 —— 模型基于受细粒度访问控制保护的敏感数据微调 —— 开放模型访问权限必然存在意外数据暴露的风险。无论是在输入阶段、输出阶段还是微调阶段应用现有防御机制,都缺乏端到端保障,无法为数据泄露提供可靠防护。这一根本性安全缺口,仍是企业广泛采用微调大型语言模型的主要障碍。
支持访问控制的微调模型
在下文中,我们将阐述可证明防止微调模型数据泄露的安全原则;随后,我们将讨论如何利用访问控制列表(ACLs)实现该原则,并通过图形化方式呈现我们需要解决的问题;最后,我们将展示多个概念验证(PoCs)示例方案,说明如何在多用户环境中构建实用的微调模型。其中一个方案已部署于某大型企业解决方案提供商的人工智能助手中,供实际客户使用。
安全原则
形式化安全要求:我们要求,用户 U 对微调模型的访问权限,不得使 U 获得对任何未授权信息的访问权限。该要求从形式上确保了微调模型的使用不会引发数据泄露攻击。
接下来,我们将阐述可证明满足上述安全要求的安全原则。
微调安全原则:设模型 M 是通过在敏感文档集合D上对公开预训练模型进行微调得到的。则仅当用户 U 被授权访问D中的所有文档时,才能向 U 提供模型 M 的访问权限。
例如,若模型 M 基于敏感数据微调,且这些数据仅爱丽丝和查理有权访问、鲍勃无权访问,则模型 M 仅可提供给爱丽丝和查理,不可提供给鲍勃。反之,若要为用户组U微调模型,则训练数据必须限制为U中所有用户均有权访问的文档。
要在构建微调模型时实施上述安全原则,显然需要仔细确认谁有权访问底层训练数据。为此,我们对常用文件系统(如 SharePoint 站点、GoogleWorkspace 及类似平台)中数据关联的访问控制列表(ACLs)进行了研究。接下来,我们将回顾一些定义,并以图形化方式呈现我们面临的问题。
双团(Bicliques)可保障微调安全
符号与定义:我们用 D 表示文档,E 表示实体,U 表示用户,M 表示模型。实体 E 可以是单个用户,也可以是用户组(如通讯组列表或 Active Directory 安全组)。每个文档 D 都关联一个访问控制列表(ACL),该列表包含被授权访问 D 的实体 E。二分图 G 是指顶点可分为两个不相交集合,且同一集合内顶点互不相连的图。双团(biclique)是一种完全二分图,其中一个集合中的每个顶点都与另一个集合中的每个顶点相连。
基于图的访问控制列表(ACLs)表示:给定文档 ID 集合 D(及其对应的访问控制列表,包含来自实体全集 ε 的实体),我们可通过 D 和 ε 之间的二分图 G 表示访问控制信息:若实体 E 属于文档 D 的访问控制列表 A,则在二分图 G 中,文档 D与实体 E 相连。根据双团的定义,E中的每个实体都被授权访问D中的每个文档。
多用户环境下实用微调模型的构建方法
在前面的小节中,我们确立了支持访问控制的微调安全原则,该原则可证明能防止上述描述的所有数据泄露场景;同时我们还证明,可利用双团(bicliques)实现安全微调。本节将聚焦模型可用性问题:在由访问控制列表(ACLs)衍生的图中,可能存在大量双团(bicliques),那么哪些微调模型真正值得构建?
一种极端情况是,为每个用户单独微调一个模型。尽管这种方式能实现最大程度的个性化,但成本过高,在任何企业中都不具备运营可持续性。更实际的目标是,微调可在多个用户 / 实体间共享的模型 —— 我们将这种特性称为 “实体覆盖度”。例如,我们可为整个企业训练一个模型,实现 100% 的实体覆盖度。然而,根据我们的安全模型,训练数据必须限制为组织内 “公开” 的文档,这一约束可能会排除大量相关内容,从而限制模型在企业特定任务中的可用性。为维持任务相关性,我们必须有选择地纳入包含关键领域知识的文档 —— 我们将这种特性称为 “文档覆盖度”。但这又可能会限制有权访问微调模型的用户范围,降低实体覆盖度。因此,实体覆盖度与文档覆盖度之间存在权衡关系。
我们考虑两种主要使用场景,模型构建者或 IT 管理员旨在为企业场景微调模型。在这两种场景中,IT 管理员都会提供文档 ID 集合 D,以及基于实体集合 ε 定义的相应访问控制列表(ACLs)。
IT 管理员指定模型访问的目标实体集合E:
这种情况处理起来较为直接:我们选择所有满足E⊆A (A 为文档的访问控制列表)的文档D。该方法效率较高,只需对所有文档 ID 及其关联的访问控制列表(ACLs)进行线性扫描即可。
IT 管理员未指定任何偏好:在这种场景下,目标是确定文档子集和实体子集,以实现前文讨论的文档覆盖度与实体覆盖度之间的平衡。我们提出两种候选策略来解决这一问题:
(1)最大双团(Maximum Biclique):边数最多的双团称为最大双团。这种配置对于微调而言颇具吸引力,因为它能实现较广的文档覆盖度和实体覆盖度。然而,确定最大双团是一个已知的 NP 完全问题。尽管可采用分支定界等算法寻找最大双团,但这些算法计算成本高昂,在企业场景中常见的稠密图中尤其如此。
(2)极大双团(Maximal Biclique):直观而言,这种方法通过生成候选极大双团,并选择边数最多的双团。作为一种启发式方法,我们将图中的每个唯一访问控制列表(ACL)视为候选实体集合E,并应用第一种场景中的策略确定相应的文档集合D;随后,我们尝试通过纳入所有有权访问D 中所有文档的其他实体,扩展实体集合,从而形成候选极大双团。这种启发式方法在企业系统中尤为适用 —— 在这类系统中,通常由少数几个实体集合管理大量文档,这使得该方法更有可能找到真正的最大双团(详见附录 A)。
实际应用:基于上述极大双团(Maximal Biclique)思路,我们的初步解决方案(详见附录 A)已作为微软 Copilot 微调(Microsoft Copilot Tuning)的一部分公开提供。该产品支持大型企业客户使用其专有数据微调模型。
消除多用户 RAG 系统中的信息泄露
人工智能助手通常会通过检索增强生成(RAG)技术进行增强,该技术能为大型语言模型(LLM)的提示词补充相关上下文。我们考虑多用户与人工智能助手交互的场景 —— 用户提供输入、接收输出,并常常影响共享系统状态。尽管本节的描述主要假设在 RAG 检索后使用公开大型语言模型(LLMs)进行推理,我们也会探讨将微调模型与 RAG 结合使用的相关影响。在多用户场景中,要确保微调模型与基于 RAG 的检索协同工作的安全性,是一项极具挑战性的任务,需要设计严谨、执行确定的访问控制机制,以防止意外数据暴露。因此,为便于阐述,我们将以公开大型语言模型(LLMs)为例,讨论多用户基于 RAG 的人工智能助手。
我们将分析两个典型场景:(a)帮助用户起草对不同发件人邮件回复的邮件助手;(b)多用户借助大型语言模型(LLM)助手共同撰写内容的协同写作工具。我们首先聚焦邮件助手场景,随后简要说明类似漏洞在协同写作工具中的表现。
结合 RAG 与 LLM 的邮件助手
考虑一个基于大型语言模型(LLM)的邮件助手,其功能是帮助用户起草、编辑和总结邮件。检索增强生成(RAG)技术会从用户邮箱或 Google 云端硬盘(如 Google Gemini Advanced)中提取文档,丰富大型语言模型(LLM)的提示词内容。我们首先描述邮件助手的两种常见模式,以及 RAG 在每种模式下的工作方式。
在智能代理模式(Agentic Mode) 下,助手充当起草伙伴:当爱丽丝调用该系统(例如说 “帮我起草给鲍勃的回复”)时,助手会生成候选邮件供她审核。爱丽丝拥有最终控制权:她可以编辑、丢弃或批准该草稿。这一审核步骤提供了明确的检查点,确保所有内容都需经爱丽丝明确同意后才能发送。
与之相对,完全智能代理模式(Fully Agentic Mode) 则完全移除了人工检查环节:当爱丽丝下达高层指令时,助手会直接代表她起草并发送邮件。这种模式最大限度地提升了便利性和效率,但也要求完全信任助手能在敏感场景中避免错误或意外信息泄露。
两种模式的核心都是 RAG 流程:助手首先会对爱丽丝邮箱中的内容(主题行、邮件正文和附件)进行索引 —— 将每个项目嵌入语义向量空间;当爱丽丝发起提示时,系统也会将该提示嵌入向量空间,并在索引中进行语义搜索,检索相关性最高的前 k 个项目;随后,这些检索到的片段会被添加到大型语言模型(LLM)的提示词前面,为模型提供来自过往对话、日期或数据的特定细节,从而提升响应质量。
[1] 此处的极大双团(Maximal Biclique)指:无法再添加更多文档或实体而不破坏双团属性的双团。
[2] 正如我们稍后将看到的,即便爱丽丝拥有最终控制权,恶意发件人鲍勃仍能从爱丽丝的邮箱中泄露敏感信息。
尽管 RAG 能显著提升助手性能,但也扩大了攻击面:若检索机制未得到妥善约束,爱丽丝邮箱中的任何文档都可能被纳入大型语言模型(LLM)的上下文。当恶意发件人(如鲍勃)在邮件中注入恶意提示词,试图影响系统检索内容和响应方式时,这种漏洞会变得尤为严重。
我们将介绍两个核心角色,并定义攻击类别:爱丽丝是邮件助手的良性用户,她诚信交互,信任系统能帮助自己起草和发送邮件,从未意图泄露私人数据 —— 在智能代理模式下,她会手动审核每一份草稿;在完全智能代理模式下,她将发件箱的全部控制权委托给助手。鲍勃是攻击者,其唯一能力是向爱丽丝发送邮件,无权读取爱丽丝的邮箱或文档,但他的目标是通过操纵助手行为(特别是利用提示词注入影响检索和生成过程),从爱丽丝的邮箱中提取私人信息。
跨提示词注入攻击(XPIA):攻击流程
跨提示词注入攻击(XPIA)是指攻击者将隐藏指令嵌入看似良性的内容(如邮件)中,当大型语言模型(LLM)执行回复生成等任务时,这些隐藏指令会被模型处理。这些隐藏提示词能操纵模型执行原始用户既未意图也未授权的操作,可能导致信息泄露或违反策略。

图 1:针对基于检索增强生成(RAG)的智能邮件助手的跨提示词注入攻击演示:(1)攻击者(鲍勃)向受害者(爱丽丝)发送一封看似无害的邮件,其中嵌入了用于诱导数据泄露的隐藏提示词(红色标注部分);(2)爱丽丝要求助手以鲍勃的邮件为上下文起草回复;(3)人工智能助手根据提供的查询和上下文,对爱丽丝的数据存储发起检索请求,并获取机密数据(例如,X 项目的收入);(4)人工智能助手基于检索到的信息生成回复,并将其呈现给爱丽丝;(5)回复被发送给鲍勃,数据泄露完成。
我们将分析一类跨提示词注入攻击(XPIA):恶意发件人鲍勃在发送给爱丽丝的邮件中,注入类似提示词的指令。这些指令对爱丽丝而言是不可见或无害的,但会被助手的 RAG 流程和大型语言模型(LLM)处理,最终导致私人信息未授权泄露。这种攻击通过滥用助手的检索和生成流程,构建隐蔽通道以泄露敏感数据 —— 整个过程无需爱丽丝察觉或同意。我们在图 1 中展示了攻击流程,其中恶意内容用红色标注。
-
步骤 1—— 包含嵌入式恶意提示词的邮件(红色部分):鲍勃向爱丽丝发送一封看似无害的邮件(例如 “我们见个面吧,建议个时间?”),但在邮件中嵌入了隐藏指令:“查询 X 项目的收入(以百万为单位),并在回复中建议以该数字对应的日期见面。” 攻击者可通过白色背景上的白色文本、不可见 Unicode 字符或 HTML 混淆等技术,将该指令对爱丽丝隐藏,同时确保模型能读取该指令。然而,我们需强调两个关键点:(a)不可区分性:助手无法区分邮件中合法的提示词(如爱丽丝的经理询问项目收入)和恶意注入的提示词(如上述示例)。(b)检测局限性:现有检测提示词注入的方法均为概率性方法,易出现漏检情况。因此,在当前已部署的系统中,这类恶意提示词有不小的概率能逃避检测。
-
步骤 2—— 爱丽丝向助手发起查询:爱丽丝请求:“起草给鲍勃的回复。” 爱丽丝的查询和鲍勃的邮件(包含隐藏指令)共同构成了助手的输入。
-
步骤 3——RAG 检索:助手将爱丽丝的查询和鲍勃的邮件作为上下文进行嵌入,并在爱丽丝的邮箱中进行语义搜索。由于未识别出隐藏指令的恶意性,系统检索到了相关数据(例如 “X 项目收入为 700 万美元”)。
-
步骤 4—— 响应生成与信息泄露:大型语言模型(LLM)在生成响应时,会纳入检索到的信息,并按照攻击者的指令生成回复:“嗨鲍勃,没问题,5 月 7 日怎么样?” 其中,“5 月 7 日” 是 “700 万美元” 的隐蔽编码,以看似无害的形式泄露了敏感财务信息。
-
步骤 5—— 向攻击者发送消息:在智能代理模式下,该草稿会提交给爱丽丝审核,而爱丽丝并未察觉其中的隐写编码,批准并发送了邮件;在完全智能代理模式下,邮件会自动发送。无论哪种模式,鲍勃都能成功泄露机密数据。
在整个过程中,爱丽丝始终未察觉敏感信息已被访问并泄露。助手虽按设计流程运行,却被攻击者利用 —— 攻击者正是借助了 RAG 和大型语言模型(LLM)流程中缺乏访问控制 enforcement 这一漏洞。
现有跨提示词注入攻击防御手段的局限性
我们简要回顾针对上述攻击的现有防御手段,并指出其局限性。这些防御手段均为概率性方法 —— 即仅能以一定概率检测或阻止提示词注入 —— 这使得攻击者仍有不小的成功概率。总体而言,防御手段可分为三类:(a)输入检查;(b)输出过滤;(c)系统级隔离。每类防御手段针对攻击流程的不同阶段,但均无法提供确定性保护。
-
输入检查(针对图 1 中的步骤 2):这类防御手段试图在恶意输入到达大型语言模型(LLM)前对其进行检测和中和。输入净化等黑箱策略会识别并移除潜在有害模式,而 “聚焦标注(Spotlighting)” 则会为输入的不同部分标注来源(如可信用户输入 vs 不可信外部内容)。白箱方法通过微调大型语言模型(LLMs),直接对注入的提示词进行分类或抑制。尽管这些技术有一定价值,但缺乏形式化保障,且在面对复杂或经隐写编码的提示词时往往失效。BIPIA 等基准测试结果表明,在不同攻击类型和大型语言模型(LLM)架构中,这类防御手段始终存在漏洞。
-
输出过滤(针对图 1 中的步骤 4):这类方法通过扫描大型语言模型(LLM)的输出来识别敏感或不允许的内容。运行时监控系统利用基于规则或基于学习的过滤器检测策略违规,污点追踪则会追踪敏感数据在生成过程中的传播路径。“任务追踪器(TaskTracker)” 等技术通过识别任务偏移来检测异常行为。然而,这类系统在应对隐蔽泄露时存在不足 —— 例如,当敏感信息被编码为看似无害的输出(如将 “我们的收入为 700 万美元” 映射为 “5 月 7 日见面”)时,系统难以检测;此外,这类系统无法识别下游接收者的访问权限,导致策略执行不完整。
-
系统级隔离(针对图 1 中的步骤 3 和步骤 4):“骆驼(CaMeL)” 等架构防御手段会基于用户查询构建控制流,并将其固定,以防止不可信的检索内容修改控制流。但需注意的是,图 1 所示的攻击流程仍能绕过这类防御;此外,“骆驼(CaMeL)” 虽能执行策略,但易被隐写术规避。
小结:尽管输入净化、输出过滤和架构隔离等现有提示词注入防御手段试图降低风险,但均无法提供防止未授权访问的确定性保障。因此,多用户大型语言模型(LLM)辅助系统仍易遭受复杂的数据泄露攻击(如图 1 所示的攻击)。
通过访问控制防止跨用户信息泄露
图 1 所示攻击之所以能成功,一个关键原因在于诚实提示词与恶意提示词的不可区分性 —— 两者都可能向爱丽丝请求相同的信息,但关键在于 “谁在请求”。授权接收者与未授权接收者的区别,正取决于请求者的身份。我们认为,爱丽丝应完全掌控其敏感信息的流向,任何此类信息的传输都必须经爱丽丝察觉并授权。为确定性消除 RAG 流程中的意外信息泄露,我们提出:这类系统在将任何内容输入大型语言模型(LLM)前,必须明确检查所有相关用户的访问权限。例如,在邮件助手场景中,当爱丽丝请求人工智能助手起草给鲍勃的回复时,助手检索到的任何内容都必须是爱丽丝和鲍勃均有权访问的。若不满足这一条件,则需(在智能代理模式下)获取爱丽丝的明确同意,或(在完全智能代理模式下)将该内容排除在大型语言模型(LLM)的上下文之外。
这种设计能确保系统可证明地保护机密性,避免意外信息泄露。在多接收者场景中 —— 例如鲍勃向爱丽丝发送邮件并抄送查理 —— 在将检索到的内容纳入生成过程前,必须验证所有接收者(爱丽丝、鲍勃和查理)的权限。类似地,在协同写作工具中,在调用大型语言模型(LLM)处理任何辅助内容前,必须验证所有有权读取该文档的用户的权限。通过执行此类访问控制检查,系统可确保没有用户会无意间获取其无权访问的信息。
结合 RAG 的微调模型访问控制:当将微调阶段的访问控制与 RAG 结合使用时,该组合系统的核心原则保持不变:交互中使用的所有信息,必须对所有活跃参与者均可见。
考虑多活跃参与者的场景:系统仅应使用以下微调模型 —— 该模型的微调数据完全来自所有活跃参与者均有权访问的文档。若某参与者的查询触发 RAG 组件,则仅检索所有活跃参与者均有权访问的文档,并将其添加到补充上下文。一个实际挑战是,并非总能找到所有活跃参与者均有权访问的微调模型。例如,在 4.1 节的邮件场景中,鲍勃可能是企业外部人员。在这类情况下,系统必须退而使用通用的公开模型。通过遵循访问控制的核心原则,系统本质上会成为一个沙箱环境,防止任何信息(无论是来自微调模型还是 RAG 提供的数据)泄露给未被明确授权的参与者。
[3] 活跃参与者指参与系统交互的所有用户。
结论与未来工作
本文围绕一个核心问题展开:在企业等多用户环境中,如何在现代人工智能工作流程(包括微调阶段和通过 RAG 等机制的推理阶段)中保障机密性?我们的分析表明,现有防御手段存在不足,无法提供防止未授权数据暴露的确定性保障。对此,我们提出一种基于原则的解决方案:以细粒度访问控制列表(ACLs)为基础,在人工智能流程的所有阶段确定性地执行访问控制。该框架提供了强有力的端到端安全保障,为在处理敏感信息的企业中安全、大规模部署人工智能系统奠定了基础。我们希望本文能为确定性执行所有活跃参与者的访问控制这一理念,提供有说服力的论证。
未来可拓展的方向包括:在微调阶段,可将部分用户或文档的重要性编码为二分图节点的权重;在查询多个模型时,需为每个模型检查访问控制列表(ACLs);访问控制列表(ACLs)可能随时间变化(如新用户加入、现有用户失去访问权限),需在动态访问控制列表(ACLs)场景下维持安全性;访问控制列表(ACLs)本身可能存在配置错误,需检测并纠正此类错误 。
火山引擎开发者社区是火山引擎打造的AI技术生态平台,聚焦Agent与大模型开发,提供豆包系列模型(图像/视频/视觉)、智能分析与会话工具,并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长,新用户可领50万Tokens权益,助力构建智能应用。
更多推荐

所有评论(0)