在前两篇中，我们先后回答了Agent安全的两个核心问题：攻击者想要什么（第九篇）——从数据外泄到后门植入的六类攻击目标；以及攻击者从哪里下手（第十篇）——从提示词层到供应链层的七大攻击入口。明确了“目标”和“入口”之后，接下来的问题自然就是：如何挡住这些攻击？
从第十篇梳理的七大攻击面可以看出，无论是提示词注入、RAG知识投毒，还是工具参数操纵，绝大多数攻击路径都有一个共同特征——恶意内容必须首先进入系统的数据管道，才能被LLM接触到。因此，安全防御不能等到数据被送入模型推理阶段才启动，而必须在数据准入和索引阶段就完成前置拦截。本文作为安全防御机制系列的第一篇，聚焦于这一最前置的环节，从内容净化、活动内容剥离、源端信任、完整性控制到基于ACL的权限隔离，系统梳理了五类在数据入库前即可实施的关键防护措施，帮助开发者在源头消除或削弱安全威胁。
一、数据准入与索引阶段的安全防护
这是整个防御体系中最前置的一环，发生在任何数据被送入LLM或者Agent运行环境之前。核心目标是尽可能在数据源头就消除或削弱威胁。此类防护可细分为如下5类具体措施：
1.1内容净化与标准化（Content Sanitization and Canonicalization）
具体做法：将HTML、PDF、Office等复杂格式文档转换为最简化的纯文本形式。在这个过程中，会剥离、转义或清除掉其中的标记语言（Markup）、脚本（Script）、宏指令（Macros）和嵌入式引用（Embedded Media）。
局限性：纯文本转换会丢失原文档的层级结构、表格关系及排版样式，可能影响对格式依赖度较高的任务效果。同时，也无法防御用自然语言描述的恶意指令（比如“忽略之前的指令，做XX”这类的恶意指令）。
1.2活动内容剥离（Active Content Removal）
具体做法：在文档被索引或展示前，直接剥离或禁用可执行内容，例如Office中的宏、PDF中的JavaScript、自动执行的链接等。同时，确保用于转换文档的查看器/转换器在无执行权限的环境中运行。
局限性：不同文件格式对“活动内容”的支持和隐藏方式各异，防护的覆盖度可能因格式而异，需要持续更新规则。
1.3数据溯源与源端信任（Provenance and Source Trust）
具体做法：
- 对数据源使用白名单或数字签名，只有受信来源的内容才被准入。
- 为每个分块后的数据块（Chunk）打上信任元数据标签。这是为了后续检索时可以执行如下的防护策略：
- 在检索时，降低或忽略低信任来源的权重，并将来源标签显式传递给提示词（Prompt）或策略引擎。
- 对风险较高的数据包，通过人工介入（Human-in-the-Loop，HITL） 或基于风险评分（Risk Scoring System，RRS）的限流机制进行把关。
局限性：有数字签名不代表内容本身是安全的（签名只能验证来源，不能验证语义），且所有例外情况都必须有可审计的记录。
1.4语料库完整性与变更控制（Corpus Integrity and Change Control）
具体做法：
- 采用"仅追加"或"可验证"的存储系统。前者通过权限控制禁止随意修改历史数据；后者通过密码学证明，让任何第三方都能独立验证数据是否被篡改。
- 每个数据块入库时，计算并保存其哈希值作为"数字指纹"。后续使用时重新计算并比对，能立刻发现数据是否发生变动。
- 所有数据更新操作必须经过审批，并在防篡改的日志中完整记录，确保每笔操作都可追溯。
局限性：
- 能检测数据在入库后发生的非预期"漂移"（内容缓慢变质），并可快速回滚到可信版本。但不能防御首次入库时的投毒攻击，即如果第一次录入的就是恶意数据，系统会将其视为"干净"基准，后续所有验证都会把它当作合法内容。
- 需要额外的存储空间保存哈希值和日志，同时增加了流程管理复杂度，运维工作量较大
1.5 基于ACL的分块与检索（ACL-aware Chunking and Retrieval）
ACL是Access Control List（访问控制列表）的简写。它是计算机安全领域的一个基础概念，简单来说就是“谁能对什么做什么”的一张权限清单。
具体做法：为每个嵌入向量（Embeddings）打上所属租户（Tenant）、访问角色（Role）及数据敏感度（Sensitivity）等标签，在查询时强制执行权限检查，防止不同权限主体之间的数据泄露。同时，确保分块边界与ACL边界对齐，避免将不同访问权限的内容混合在同一个块中。
局限性：
- 性能开销：ACL-aware机制在写入阶段增加了权限标签提取、追加及索引构建的耗时；在查询阶段，每次检索都需执行权限过滤运算，且权限约束可能导致向量召回范围受限，需通过扩大召回或级联重排来补偿，进而增加整体检索延迟。
- 索引膨胀：权限标签本身需存入索引并建立额外的过滤结构，当标签维度较多（如多租户+多角色+多敏感度组合）时，索引存储规模会显著膨胀，增加存储成本和查询复杂度。此外，当权限发生变更（如员工转岗、租户权限调整）时，需对已入库的向量标签进行批量更新或重新索引，维护成本较高。
二、小结
数据准入与索引阶段的防御，遵循的是“御敌于城门之外”的安全哲学——在恶意内容尚未进入检索库和LLM上下文之前，就将其识别、剥离或降权处理。本文讨论的五项措施构成了一个层层递进的防御链条：
- 内容净化与标准化解决的是“格式载体带来的可执行风险”；
- 活动内容剥离进一步清除隐藏在富文本中的可执行代码；
- 数据溯源与源端信任解决的是“来源是否可靠”的问题；
- 语料库完整性与变更控制解决的是“入库后是否被篡改”的问题；
- 基于ACL的分块与检索解决的是“谁能访问什么数据”的权限隔离问题。
这五层防御共同构筑了LLM应用安全体系的第一道防线。它们的共同特点是：前置、静态、确定性——不依赖于LLM的判断能力，也不依赖于实时推理的上下文，因此具备较高的可靠性和较低的运行时开销。当然，这套前置防御并非万无一失：它无法防御首次入库时的投毒攻击（因为系统会把第一次录入的数据当作“干净”基准），也无法拦截用自然语言巧妙包装的恶意指令（因为纯文本净化无法改变语义）。因此，数据准入防御必须与后续的检索时防御（如风险感知排序、摘要隔离等）协同配合，才能构成完整的纵深防御体系。本文是LLM应用安全防护的第一篇，下篇将聚焦于检索、生成与输出阶段的运行时防御机制。
三、参考文献
1. Ali Dehghantanha, Sajad Homayoun. SoK: The Attack Surface of Agentic AI — Tools, and Autonomy, 2026.
作者：灵栖八荒（徐宏勤）
版权声明：本文为原创内容。如需转载，请务必在文章开头标注作者和来源，并保持文章完整，否则视为侵权。
