检索增强生成（RAG）正在迅速成为企业 AI 代理接入自有知识体系的基础架构。通过将大语言模型（LLM）与高密度向量数据库和知识图谱配对，组织可以让代理利用实时运营上下文回答复杂查询、分析财务记录，并自动化客服工作流。

然而，当代理工作流从原型侧车转向核心基础设施时，将非结构化企业数据暴露给向量搜索管道，会引入严重且未被监控的安全敞口。

打开网易新闻 查看精彩图片

当 LLM 从向量存储中检索文档片段时，传统的身份管理框架会直接失效。在传统 SQL 数据库或云存储桶中配置的基于角色的访问控制（RBAC），并不能原生地映射到向量嵌入空间。如果向量存储在摄取文档时没有保留细粒度的文档级访问控制列表（ACL）或加密数据沿袭，自主代理就会在一个权限过高的上下文中运行。

缺乏治理的 RAG 架构会带来严重后果：首先是上下文注入引发的权限提升——一名只有基本读权限的员工向代理提出一个高层查询，代理的向量搜索检索到分块的财务预测或高管邮件，而这些内容在查询时并未经过授权过滤，于是机密数据便在生成的回复中暴露了。

其次是间接提示注入。恶意行为者将隐藏的指令载荷嵌入公共或共享的企业文档内部（例如 PDF 发票中的隐藏白字）。当 RAG 引擎摄取并检索到这一片段时，LLM 就会执行注入的命令，劫持代理的执行循环。

再次是过时上下文和幻觉循环。向量数据库会无限期地保留过时的文档嵌入，除非与有状态的生命周期策略绑定。代理依据过时的操作流程作出决策，便会生成幻觉性或不合规的输出。

为了在企业规模上部署可代理的 RAG，平台工程团队必须实施数据、上下文与 RAG 沿袭治理——这是一套持续架构，确保查询时授权、加密数据溯源以及自动化的上下文消毒。

在生产级受治理的 RAG 架构中，上下文处理被划分为三个不同的、可观测的安全边界。治理始于摄取阶段，在向量被写入索引分区之前。当文档片段经过解析引擎（如 Unstructured、LlamaIndex 或 LangChain 分割器）时，管线会计算一个加密哈希并附加强制性的沿袭头。这些头部信息包括片段 ID、文档 ID、源 URI、源文件的 SHA-256 哈希等，以此建立起从原始文档到向量嵌入之间不可篡改的可追溯链。

只有通过此类端到端的加密沿袭和实时授权过滤，企业才能将 RAG 从一种便利的检索增强手段，升级为支撑关键任务代理运转的安全基座。