文章总结: 本文深入分析CAG(上下文感知生成)在AI安全中的攻击面,指出其风险重心从RAG的检索阶段转向预处理、缓存层和运行时状态复用。核心发现包括CAG的七层技术实现(资料收集至Agent执行)和六大攻击面(输入面至执行面),重点揭示缓存污染、KV缓存跨租户复用、语义缓存投毒等机制风险。可操作建议强调缓存边界需与信任边界对齐,并通过安全设计降低状态复用带来的信息泄露和污染扩散风险。 综合评分: 85 文章分类: AI安全,应用安全,云安全,数据安全,安全建设
CAG攻击面详解:从预加载上下文、KV缓存复用到语义缓存投毒的机制风险研究
原创
林之冰寒 林之冰寒
Security for AI
2026年5月19日 10:30 沙特阿拉伯
在小说阅读器读本章
去阅读
本文全文下载链接:https://wwaop.lanzn.com/ipXIW3pt51sh
引言
如果把CAG放到AI安全语境里重新定义,它已经超出单纯替代RAG的提效技巧范围,逐步演化成一套围绕长上下文、前缀复用、状态复用、上下文持久化与跨请求缓存建立起来的运行时体系
CAG是什么,为什么它的攻击面不能只按RAG思路理解
CAG的可以简单理解成在知识库规模有限且可管理的前提下,将相关资源预加载到长上下文中,并缓存运行时参数,推理阶段直接基于这些预加载状态回答问题,从而绕开实时检索延迟、检索错误与系统复杂度
在早期定义偏向知识任务效率与精度对比,后续实践吧CAG补成了更完整的运行方案:将完整子系统或较大规模代码上下文装入长上下文,再配合缓存减少重复prefill开销,用整体依赖图替代随机相似片段召回。然而,在现实里的CAG往往不止一层:
第一层是资料预加载。也就是把固定知识、代码库、工作流说明、历史会话与企业级规范提前塞进上下文。
第二曾是前缀复用。系统把共有前缀做成可重用前缀块,在后续请求里直接命中。
第三层是KV缓存复用。模型在prefill阶段得到的中间状态被保存,在后续相同或部分相同前缀上重用。
第四层是持久存储。
第五层是语义缓存。一部分云平台与中间层会直接缓存查询和响应对,依据语义相似度复用结裹,很多场景下缓存条件已经从严格相同前缀扩展到语义相似。
这意味着,CAG的攻击面不等于把RAG里的向量库那么简单。RAG的核心安全问题常集中在文档污染、检索召回偏差、间接提示词注入与工具链调用污染。CAG把风险重心向另外几个位置转移:
- 预加载材料是否可信。
- 预加载材料进入上下文后的优先级与可覆盖性
- 前缀缓存是否跨甪户、跨租户、跨会话复用
- 共享KV块是否形成时序侧芯道
- 持久缓存是否被投毒、过期、错误命中或错误隔离。
- 长上下文本身是否带来新的服从性与信息定位能力下降问题。
也正因为如此,分析CAG攻击面时,单看提示词注入四个字远远不够。更准确的划分应该覆盖六个平面:输入面、缓存面、隔离面、时序面、持久化面与执行面。
CAG与RAG在攻击面上的结构差异
RAG把风险暴露在检索时刻。检索器会决定哪些片段进入上下文,因此问题常出在召回、排序、切片与来源控制。CAG把更多风险压缩道预处理与运行时缓存层。资料一旦进了长前缀,后续查询会持续共享这段上下文,问题从一次性检索错误,变成可重复命中的共享状态错误
从安全角度看,这个变化非常重要。因为共享状态一旦建立,攻击者追求的目标也从让某一次回答偏转,转向让后续很多请求在没有再次接触恶意资料的情况下继续带投毒的内容继续运行
CAG的技术实现
从大模型的运行周期生命来看,得先把它分别拆成层。现有资料通常把CAG理解成把知识放进上下文这么简单,实际运行时比这复杂得多。下面来逐层简单分析
第一层是资料收集层。这里可能接收聊天记录、网页、OCR文本、工具返回结果与用户上传内容。只要进入预加载候选集合,就进入CAG信任链。
第二层是预处理与切分层。材料可能被去重、拼接、摘要、排序、加标签、转成中间格式,甚至做知识图谱构建。
第三层是上下文装配层。开发者要决定系统提示、静态知识、动态上下文、工具结果与用户问题的顺序。提示结构本身会直接影响缓存复用与泄露风险。
第四层是prefill与长上下文推理层。这里完成大前缀编码,生成中间状态。CAG性能收益大多出在这一步,因为重复计算非常昂贵。
第五层是prefix缓存与KV缓存层。前缀缓存以块为单位,根据前缀与块内容做哈希,完整块才会进入缓存。
第六层是外部缓存与共享存储层。跨多LLM共享KV缓存、CPU offload、Redis、RESP、S3、共享存储与控制器等能力。
第七层是Agent执行层。只要CAG被Agent继续用于工具调用、代码修改、消息发送、工单操作、邮箱处理,风险就会从信息完整性升级到外部行为风险。
输入面攻击面
输入面是CAG攻击面的起点。只要系统允许把外部资料、工具输出、代码片段、工单或记忆内容预加载进上下文,就有机会被间接影响。这里的核心是,CAG虽然减少了实时检索,但并没有减少不可信内容进入上下文的机会,很多时候它只是把注入时刻从在线检索阶段前移到了预加载阶段。
在CAG里,预加载本身就鼓励开发者尽可能多地把背景资料塞进共享前缀。攻击者未必需要控制系统提示,也未必需要拿到高权限配置入口,只要能把内容送进模型可见上下文,就有机会争夺模型后续行为。RAG里的恶意文档能否生效,往往取决于某次查询时是否被召回。但是CAG里的恶意材料只要进入静态前缀并写入缓存,后续很多查询就可能都在共享这段带毒前缀,这种风险尤其容易出现在把最近工单与聊天记录合并为团队公共上下文等间接提示词注入常见场景。在这些系统中,攻击者不再需要每次都投递恶意内容,更看重的是首个写入窗口。
与此同时,上下文装配顺序本身也是安全控制点。提示结构会影响缓存复用,也会影响泄露暴露面,。如果多个租户共享静态前缀,且用户可控内容紧跟其后,攻击者就更容易通过构造相同前缀试探缓存命中
缓存面攻击
缓存面是CAG最核心的安全转折点。只要系统为了节省prefill成本而跨请求复用前缀,就必然要面对隔离、失效、污染与推断问题。
CAG缓存体系已经形成了几个稳定特征:
- 缓存用于复用提示前缀,默认存在分钟级到小时级TTL
- 缓存条目围绕prefix hash和cache breakpoint工作
- 系统在断点位置没命中时还会向前回看一定数量的块
- 大量上下文内容可以被缓存并在后续请求中引用
- 超过阈值的长前缀还会被自动缓存,并在组织或账户边界上做隔离。
这里的安全问题在于,这些机制的默认设计目标优先落在性能与成本,并不天然等于安全边界。前缀一旦被缓存,它就不再只是某个请求里的临时输入,而成为可复用对象。若前缀里本身含有系统指令、租户级知识、内部文档、工具说明、隐私样本或安全策略,这个缓存对象就已经具备敏感性,风险也会立刻上升为三个问题:谁能命中它,谁能推断它是否存在,谁能让它继续刷新TTL并长期驻留。因为缓存使用时会刷新有效期,这意味着缓存对象不仅可能被读,还可能因持续命中而长期驻留,若条目已经被污染或误隔离,这种刷新就会放大影响面。
换个角度看,缓存边界本质上应与信任边界对齐。若把用户输入、时间戳、外部返回结果和租户特定数据一起放进共享断点前缀,缓存共享范围就会被扩展到不该共享的位置。若断点只覆盖稳定静态前缀,而把高风险动态内容留在缓存边界之外,攻击面则会明显缩小。
自动缓存虽然方便,却也更容易让开发者误以为缓存边界天然合理,而现实情况恰好相反,缓存系统并不理解业务信任域,它只理解可缓存前缀。若开发者没有主动声明安全边界,系统就会用性能边界代替安全边界。再往前一步看,只要缓存条目有生命周期,攻击者就可能借助延迟、命中率、过期时刻与刷新行为间接感知缓存状态
KV缓存与多租户复用攻击面
前面的输入面与缓存面,风险重点主要落在不可信内容进入上下文、缓存边界划分失当,以及共享状态被错误复用这几类应用层问题。到了KV缓存共享阶段,问题的重心会进一步下沉到推理服务基础设施层与多租户隔离机制,核心风险也会转向缓存键构造、复用判定条件、时序可观测性与底层资源共享安全。这个变化之所以重要,是因为KV缓存复用已经不再只是上层应用怎样组装提示词的问题,它同时决定推理服务如何识别相同前缀、如何隔离不同请求、如何管理共享块,以及攻击者能否借助时间差与命中状态反推出其他租户的输入痕迹
就公开实现来看,前缀缓存通常按块管理,只有完整块会进入缓存。块标识通常由父块哈希、当前块token序列以及额外区分项共同构成,额外区分项可以包含LoRA ID、多模态输入哈希与cache_salt。默认哈希算法也在逐步转向更稳妥的方案,用来降低碰撞带来的错误复用风险。
如果继续采用非加密安全哈希,理论上会提高碰撞概率,在多租户场景下还可能放大私有信息泄露面。而cache_salt的作用,则是把缓存复用范围限制在相同信任域内部,避免攻击者借助响应时延差异对他人缓存状态进行枚举和推断。从实现角度看,这里真正需要关注的,不只是缓存有没有命中,更多的是缓存键里到底包含哪些区分信息、这些区分信息能否覆盖租户边界、模型配置、多模态输入和会话隔离需求,以及复用判定是否会把原本不应共享的请求状态错误归并到同一个缓存命名空间里。
进一步看,KV缓存共享会天然暴露两类信号。第一类是存在性信号,也就是某段前缀此前是否已经被别人计算过。第二类是活跃度信号,也就是这段前缀最近是否还驻留在缓存中、是否被反复访问、是否已经被淘汰。只要攻击者能稳定观测首token延迟、prefill耗时、命中与未命中的响应差异,就有机会把这些性能差异转译成关于其他请求状态的推断信息。多租户服务中的KV cache sharing已经被公开研究验证会引入新的side channel attack vectors,攻击者能够在不同先验条件下逆向恢复其他用户的prompt。这里的关键点不在于攻击者一定能直接读到缓存内容,而在于缓存命中本身会改变服务的执行路径和资源消耗,只要这种差异足够稳定,它就会变成侧信道的可观测输出。
再往基础设施层看,KV缓存问题还会随着外部存储和跨实例共享而继续放大。当前实现已经支持把KV缓存外移到CPU、Redis、S3等后端,并支持跨多个LLM实例共享KV状态,这意味着攻击面已经不再只在GPU显存内部,而是扩展到了远端缓存后端访问控制、缓存条目序列化与反序列化、控制器接口、跨实例与跨模型共享规则,以及缓存淘汰与迁移过程。只要缓存块的生命周期跨过单进程、单卡或单实例边界,问题就会从本地复用风险扩展成分布式资源隔离风险。性能受益确实会更高,但缓存驻留时间、迁移路径、淘汰顺序与共享范围也会同步变得更复杂。
在这个背景下,LRU或类似淘汰机制也不再只是性能优化细节,而是会直接影响可观测信号强弱。只要缓存淘汰依赖近期使用情况,攻击者就可能把命中与未命中和最近活动联系起来,进一步推断某类前缀是否近期被访问、某个租户是否活跃、某类系统提示是否仍驻留,甚至推测服务是否刚处理过某类高频任务。换句话说,KV缓存阶段真正暴露的风险已经不止是内容泄露,还包括业务活动侧写、租户活跃度推断、共享提示存在性确认,以及底层缓存命名空间划分不当带来的跨请求状态污染。这也是为什么KV缓存与多租户复用问题必须被当成推理基础设施安全问题来处理,而不能仅仅把它看成普通的提示复用优化
语义缓存投毒攻击:当缓存条件从严格前缀相等变成语义相似
严格前缀缓存的问题,核心还停留在相同前缀是否被错误共享。但语义缓存不再要求后续请求与历史请求拥有完全相同的输入结构,而是允许系统依据语义相似度直接复用已有结果。这样一来,风险重心就不再只是缓存键碰撞或前缀边界误设,而会进一步转向相似度判定标准、跨用户复用条件、响应对象完整性以及缓存命中后的可审计性。语义缓存一旦进入生产链路,缓存对象就不再是中间状态,而会直接上升为面向用户返回的最终答案,这意味着它对正确性、隔离性和可回溯性的要求都会明显高于KV块这类底层复用对象。
更具体地说,语义缓存面临的是一类和传统Web缓存投毒相似、但判定逻辑更隐蔽的问题。传统缓存投毒依赖显式URL、Header或Cache Key,攻击者与防守方至少能看到命中规则的外形。语义缓存的复用条件却由嵌入模型、相似度阈值、归一化策略、租户隔离粒度、候选排序逻辑以及请求上下文裁剪方式共同决定。开发者很难凭肉眼判断两条输入是否会进入同一语义,安全审计也很难仅凭日志复盘一次命中到底是因为语义相近、阈值过宽、标准化失当,还是租户边界没有真正进入判定条件。正因为复用判定的不透明性更强,攻击者就有空间通过多轮试探,逐步逼近系统的相似度边界,并在边界附近寻找足以触发错误复用的表达方式。
语义缓存投毒真正危险的地方,在于它缓存的对象已经是攻击者希望别人接收到的答案,而不只是模型内部的一段状态。如果攻击者先提交一条经过精心设计的请求,并诱导系统生成特定响应,这个响应一旦被写入语义缓存,后续用户只要提出在系统看来足够接近的问题,就可能直接命中这个条目,拿到攻击者预先塑造的结果。到了这一步,问题已经不再是模型临时答偏,而是系统把带偏结果升级成了可复用资产。由于缓存命中后有时甚至不会重新进入完整的生成流程,许多依赖生成阶段的上层防护也可能被直接绕开,响应过滤、提示加固、工具前置校验等机制都未必还能在命中路径上发挥原有作用。
对CAG来说,这类风险还会被进一步放大,因为很多系统会把大型静态上下文的前缀缓存与问答结果的语义缓存叠在一起使用。此前缀已经通过长期驻留塑造了模型的答案空间,语义缓存又会把其中一次生成结果进一步固化成可跨请求复用的终态对象。这样一来,攻击链就会同时拥有两次干预机会:第一次发生在预加载上下文和共享前缀阶段,攻击者尝试影响模型生成方向。第二次发生在答案写入语义缓存阶段,攻击者尝试把一次偏移结果固化为长期可命中的缓存条目。只要第二步成功,后续用户即使问题表达不同,也仍有机会落入同一个缓存响应面上。
持久上下文、记忆与Agent执行:为什么污染会跨时间、跨动作扩散
CAG一旦从请求级缓存继续向上延伸,最容易被低估的就是持久上下文与记忆层。请求级缓存处理的是一次或数次请求之间的状态复用,记忆层处理的却是跨时间、跨轮次、跨任务的长期状态保留。这两者虽然都属于状态复用,但安全后果完全不同。前者更多影响同一时间窗口里的多个请求,后者会把一次污染扩展成跨时间持续生效的背景变量。只要系统会从对话中抽取摘要、偏好、用户画像、工具解释结果,并在后续会话中自动重新注入,这些对象就已经从临时上下文变成了具备长期影响力的控制材料。
这类问题的关键,不在于记忆里是否保存了原始恶意文本,而在于系统是否把一次受污染的上下文进一步提炼成更高权重、更短路径、更靠前位置的持久对象。大型静态前缀中的一段恶意文本,仍然要与其他上下文竞争注意力;一旦它被错误抽取为持久记忆,它就可能以更短的提示片段、更加稳定的格式、更加靠近系统控制信息的位置反复进入后续会话。这样一来,攻击者需要维持的内容量会更小,系统为这段内容赋予的默认可信度却会更高,污染也会从一次会话偏差转成长期行为偏差。
当记忆层与Agent执行叠在一起时,风险会继续升级。只要模型能访问私有数据、接触不可信内容,又拥有外部操作能力,污染就不再只是文本输出偏差,而会转成真实动作偏差。一个常见的攻击常见是:投毒上下文先影响当前判断,随后模型把这种判断转成工具调用决策,工具再去读取私有数据、触发外部通信或修改远端状态,最终把一段原本停留在上下文里的偏移扩展成可观测的系统行为。二到了这一步,系统真正面临的已经不是模型是否答错,而是共享状态是否会在跨时间、跨任务与跨动作的链路中被持续放大
总结
CAG攻击面并不是若干互不相关的点,而是一条从内容进入、状态复用、缓存共享、长期驻留再到动作执行的连续传播链:
- 输入面负责决定什么资料能进入系统
- 长上下文面负责决定这些资料在模型里以什么强度参与竞争
- 缓存面负责决定哪些状态会被跨请求复用
- KV面负责决定底层推理服务如何共享中间结果
- 语义缓存面负责决定哪些最终答案会被升级成可复用对象
- 持久层面负责决定哪些影响会被保留到未来会话
- 执行面则决定这些影响最终能否变成现实动作。
通过这些攻击面,我们会发现:
第一,CAG并没有消灭RAG时代的不可信内容风险,它只是把这类风险从检索阶段迁移到了预加载、缓存与长期状态管理阶段。
第二,CAG最有特点的新风险来自共享状态对象化,也就是原本应该短暂存在于单次请求中的上下文、前缀、中间状态、结果对象与记忆摘要,被系统逐步提升成可命中、可刷新、可驻留的复用资产。
第三,一旦状态被对象化,风险判断就不能再只停留在回答内容,而要看状态写入条件、状态复用范围、状态生命周期、状态回收链路以及状态是否能触发下游动作。
第四,真正难治理的问题并不只是模型答偏,而是答偏结果会不会被缓存、被记忆、被再次注入,甚至被直接用来执行工具调用。
因此,CAG安全的核心并不是一句抽象的提示词注入防护,而是共享状态治理。谁能写入共享状态,写入的依据是什么,哪些条件下允许跨用户复用,哪些状态只能在单会话或单租户内存在,状态过期后如何清理等等问题
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:Security for AI 林之冰寒 林之冰寒《CAG攻击面详解:从预加载上下文、KV缓存复用到语义缓存投毒的机制风险研究》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。









评论