LlamaParse完成OWASP LLM十大风险渗透测试，暴露隐藏文本提取风险

摘要：LlamaIndex 委托 Trace 使用智能体化动态应用安全测试，对 LlamaParse 的解析、分类、字段抽取、索引、检索、部署智能体及 MCP 服务进行为期四天的灰盒渗透测试，覆盖 OWASP LLM 十大风险。测试发现，白字白底的隐藏文本可被抽取模型读取并形成不同账单金额和收款账户，揭示不可信文档既可能注入指令，也可能携带人眼不可见的关键字段。LlamaIndex 称相关问题均已修复或缓解，并建议客户把第三方文档视为不可信输入，对高风险抽取结果执行业务规则校验。

---

为什么传统 API 渗透测试不够

LlamaParse 处理的对象不是表单中的几个字符串，而是供应商、申请人或投保人提交的完整文档。文件会依次进入解析、分类、字段抽取和索引阶段，随后又可能被检索系统、客户部署的智能体以及 MCP 服务再次读取。每个环节都可能成为不可信输入影响行为的入口。

传统 API 渗透测试通常用“是否缺少身份验证”一类二元检查验证端点；但 LLM 系统具有输出随机性，输入还能改变模型行为，同一请求很难通过一次调用得出稳定结论。更棘手的是，模型运行时行为并不完全体现在源代码中，攻击者需要根据每次响应动态调整载荷，并通过可复现的利用链证明风险。

测试方法与覆盖范围

Trace 的智能体化 DAST（Dynamic Application Security Testing）代理从攻击者视角进入系统：测试账号具备正常调用权限，但无法访问源代码和云配置，平台侧提供独立组织下的测试账户，以验证租户隔离边界。测试范围包括：

• Web 应用、登录流程与公开 API；
• 文档解析、分类和字段抽取；
• 索引构建与检索；
• 客户部署的 AI 智能体；
• LlamaParse 的 MCP 服务；
• OWASP LLM Top 10 全部风险类别，以及常规 Web 应用安全问题。

代理读取开发文档，创建 GitHub 仓库并编写 Python 示例，生成测试 PDF、上传文件、执行解析代码，再根据结果修改代码并重复验证。所有发现由具备 OSCP 认证的工程师审核，修复经过复测后才会形成审计报告。

这类测试的工程价值不只是自动生成攻击载荷，而是把“发现问题”推进到“证明可利用性”。对于提示注入、跨租户泄露或智能体越权等非确定性风险，人工审查和可复现证据仍是进入企业安全评审链的必要条件。

隐藏文本发票暴露了什么

测试构造了一张发票：页面主体显示常规金额和银行账户，额外字段则以白色文字印在白色背景上。该隐藏内容没有指令语句，看起来只是同一组业务字段的“修正版”。

人在 PDF 阅读器中只会看到正常发票，但抽取系统会读取页面上的全部文本，最终返回隐藏的总金额和收款账户。这不是典型的提示注入，而是一个更基础的数据完整性问题：模型看到的内容可能多于业务人员实际审核并批准的内容。

该风险在现实供应链中尤其现实。供应商可以把发票送入客户的应付账款流程；如果付款系统直接信任抽取结果，而审核界面又没有呈现或标记隐藏字段，攻击者便可能在不触发明显视觉异常的情况下改变付款金额或收款账户。

传统 OCR 或 PDF 解析系统在这里面临类似挑战，但 LLM 文档管线增加了额外风险面：隐藏文本可能同时影响分类、摘要、字段抽取、RAG 检索结果和下游智能体决策，使单点污染扩散到多个工作流。

责任边界应落在“提取”与“业务信任”之间

LlamaIndex 的处理原则是：解析层负责报告页面上存在的内容，业务管线负责决定哪些值可以被信任。该划分具有工程合理性，因为只有客户系统掌握金额阈值、账户白名单、供应商主数据、合同条款和审批流程等业务规则。

不过，责任拆分不能代替安全设计。解析层仍应尽可能保留隐藏内容检测、视觉层与文本层差异、来源页码和坐标、字段置信度等证据；业务层则应把抽取值视为不可信数据，而不是模型已经验证的事实。

生产管线至少应加入以下门禁：

1. 对金额、账户、身份证件号、合同条款等高风险字段执行确定性规则校验，而不是交给模型自行判断；
2. 将字段与页码、坐标、置信度及原始视觉内容绑定，便于人工复核；
3. 对隐藏文本、低对比度文本和重叠对象进行检测，并要求人工确认；
4. 将供应商主数据、合同关系和账户变更作为独立可信数据源进行交叉验证；
5. 在付款、账号变更等动作前加入确定性策略引擎和人工审批，避免把检索增强等同于风险控制。

租户隔离、索引污染与智能体权限

文档解析只是风险链的起点。恶意内容一旦进入共享索引，还可能通过检索影响其他查询，或者由部署智能体和 MCP 工具放大为数据泄露与越权操作。

因此，企业部署应把文档摄取视为不可信数据入口，而不是普通文件上传。索引写入权限、项目级访问控制、检索结果中的来源边界，以及智能体工具的最小权限都需要独立配置。对于可能修改收款账户、触发付款或变更索引的工具，还应设置参数约束、审批节点和可回滚机制。

同时，不能只依赖一个模型解决全部问题。模型擅长从非结构化页面中归纳字段，但并不天然适合判定“这个字段是否与可见版本一致”或“这个账户是否属于已批准供应商”。这些属于确定性规则、数据血缘和业务授权层。

企业控制与部署建议

LlamaIndex 表示，托管服务默认不使用客户数据训练模型，相关模型提供商采用零数据保留与不训练协议；上传文件默认缓存 48 小时后删除，敏感文件可通过 do_not_cache=true 跳过缓存。其部署选项包括北美或欧盟托管 SaaS、单租户 SaaS、客户自有云账户以及自托管，并提供 SAML/OIDC 单点登录和基于角色的访问控制。

这些控制降低了数据驻留、留存和身份管理风险，但不能替代应用层安全。开发团队应同时完成以下工作：

• 对共享索引实施最小写入权限和明确的数据来源标签；
• 对解析、抽取、检索及智能体工具分别设置授权边界；
• 把外部模型调用、托管解析服务和 MCP 服务纳入供应商风险管理；
• 对每次文档解析和关键字段变更保留审计日志；
• 在回归测试中加入隐藏文本、提示注入、跨租户检索和工具越权样本；
• 将安全测试纳入持续发布流程，而不是只在重大版本前执行一次。

测试结论的边界

这次测试覆盖了 OWASP LLM 十大风险，但它是四天内完成的时间点评估，不代表平台不存在未来缺陷。智能体式安全测试能扩大攻击面探索速度，却不能证明覆盖率是完备的：攻击策略受模型能力、测试预算、拒绝策略和测试账户设计影响，隐蔽的多步业务逻辑漏洞仍可能遗漏。

其更可靠的工程用法，是与人工代码审计、租户隔离测试、依赖供应链扫描、权限回归和业务规则测试组成纵深防御。安全结论也应随模型、解析器、索引架构及 MCP 权限变化而重新验证。

---

消息来源：LlamaIndex Blog (2026-11-11)

—— 完 ——

主题标签： #LlamaParse 关注 #渗透测试 关注 #OWASP LLM 关注 #文档安全 关注 #MCP 关注