LlamaParse 将 PDF、扫描件和其他杂乱文件转换为 AI 应用可用的结构化数据。其中许多文件都很敏感，包括财务申报文件、保险理赔单和合同。在公司向我们发送任何此类文件之前，安全团队通常会审查我们的企业就绪文档：SOC 2 报告、数据政策、DPA 以及第三方渗透测试。
传统渗透测试擅长处理 Web 应用和 API。它们并非为 LlamaParse 中模型读取客户文档的那些环节而设计，而我们希望这些环节也能得到同样彻底的测试。本文介绍我们是如何做到的，以及我们学到了什么。
文档的去向
在大多数 Web 应用中，不可信输入通过表单字段进入。而在 LlamaParse 中，它以整个文件的形式进入，通常由客户公司之外的人编写，并且几乎触及所有环节。我们解析它、分类它、提取字段，并为其建立索引以供搜索。随后，客户在 LlamaParse 上部署的智能体以及通过我们的 MCP 服务器连接的 AI 助手会再次读取它。文档可能试图操纵其中任何一个步骤。
OWASP 是一家非营利组织，以其 Web 应用风险 Top 10 榜单最为知名，它还维护着一份针对 LLM 应用的十大风险独立清单。以下是每一种风险在文档平台中可能的表现形式：
| OWASP LLM 风险 | 在 LlamaParse 中可能的表现形式 |
|---|---|
| 提示注入 | 文档内的文本试图改变解析、提取或聊天所做的事情 |
| 敏感信息泄露 | 查询返回了来自其他用户、项目或组织的数据 |
| 供应链 | 我们所依赖的模型、库或数据集出现意外行为 |
| 数据和模型投毒 | 有人在索引中植入内容，之后该内容被当作可信内容对待 |
| 输出处理不当 | 提取出的值未经检查就流入其他系统 |
| 过度代理 | 智能体或 MCP 工具能做的事情超出其任务所需 |
| 系统提示泄露 | 模型泄露其配置或内部指令 |
| 向量与嵌入弱点 | 搜索返回了本不该返回的内容，或者有人能更改索引中的内容 |
| 错误信息 | 输出看起来正确，实际却是错的，而有人据此采取了行动 |
| 无界消耗 | 用户将使用量推过预期限制，导致其他所有人的使用变慢 |
为什么 AI 功能需要另一种测试
经典的 API 渗透测试会检查，例如，是否有任何端点在没有认证的情况下响应。你在没有令牌的情况下调用每个端点。每个端点要么拒绝请求，要么不拒绝，因此一次测试就能给你一个是或否的答案。
模型不是这样运作的。同一个请求可能得到不同的响应，而输入本身就能改变系统的行为。扫描源代码也没什么帮助，因为模型的行为并不在代码里。要测试一个 LLM 功能，测试人员必须在每次失败尝试后不断调整，然后重复任何有效的方法以证明其可靠性。对每个 AI 功能的所有十个风险类别都这样做，所需的耐心超出了几周手动测试所能允许的范围。
这就是 Trace 的用武之地。Trace执行智能体式 DAST（动态应用安全测试）。它的 AI 智能体攻击正在运行的应用，根据每个响应决定下一步尝试什么，并用可用的漏洞利用证明其发现。一位 OSCP 认证的工程师在发现结果到达我们之前审查每一项发现，一旦修复得到验证，Trace 会出具一份可供审计的报告，这正是我们客户的安全团队所要求的那类证据。
我们给 Trace 提供了攻击者在注册后会拥有的相同起点：可用的凭据，但没有源代码或云访问权限。
| 方法 | 灰盒：可用的凭据，无法访问源代码或云配置 |
| 环境 | LlamaParse 生产环境 |
| 租户隔离 | 不同组织中的测试账户，因此客户之间的边界从两侧都得到了测试 |
| 平台 | Web 应用、登录、公共 API |
| AI 功能 | 解析、分类和提取 索引、检索 已部署的智能体 MCP 服务器 |
| 覆盖范围 | 全部十项 OWASP LLM 风险，加上标准的 OWASP Web 应用风险 |
| 时长 | 4 天 |
LlamaParse 的一些功能只有在你真正用它构建出东西之后才有意义，所以 Trace 的智能体就这么做了。它们从头到尾读完了我们的文档，创建了一个 GitHub 仓库，编写了 Python 代码，生成了示例 PDF，上传了这些 PDF，让它们跑过代码，然后修改代码再跑一遍。它们并行地走完了这些流程，这就是它们能在四天内覆盖整个平台的原因。我们还告诉了它们平台本该如何表现，这样它们就能区分真正的问题和预期行为。
Trace 通过 Anthropic 的Cyber Verification Program和 OpenAI 的Daybreak项目，在前沿模型上运行其智能体；这两个项目为经过审核的安全公司提供模型，这些模型对它们获授权测试的系统会给出更少的拒绝。智能体始终停留在我们商定的目标上，只使用我们设置的账户，在不调取真实记录的情况下证明问题，并且从未运行拒绝服务或暴力破解攻击。Trace 的员工可以暂停任何会话。
我们学到了什么
我们的发现涉及业务逻辑、组织之间的边界，以及当文档试图操纵我们的模型时模型会如何表现。我们已修复或缓解了平台本身的所有问题。
有些发现让我们重新思考我们的职责到哪里结束、客户的职责从哪里开始。这里举一个例子。
测试构造了一张发票，在白色页面上用白色字体多印了几行，给出了一个“更正后”的总额和一个不同的银行账户。这些隐藏的行并没有指示模型做任何事。它们只是看起来像是相同字段的更正式版本。任何人打开这个 PDF 看到的都是正常发票，但提取结果返回的是隐藏的值，因为它会读取页面上的所有内容。
在真实攻击中，那张发票会来自第三方，比如供应商把账单送进客户的应付账款流程。那么，判断一份文档到底写了什么，究竟是谁的职责：是我们的，还是客户围绕它构建的流水线？
我们认为提取应该报告页面上的内容。决定哪些值可信，属于客户的流水线，因为业务规则就在那里。我们是这样划分的：
| LlamaParse 负责 | 客户负责 |
|---|---|
| 保持每个客户的数据相互隔离 | 哪些文档会进入他们的工作流和索引 |
| 控制对项目和资源的访问 | 哪种解析层级适合他们的文档 |
| 让解析和提取按文档所述的方式运行 | 他们如何检查结果并据此采取行动 |
企业级控制
渗透测试只是安全团队审查的一部分。其余内容在我们的企业就绪度文档：
| 领域 | LlamaParse 提供什么 |
|---|---|
| 合规 | SOC 2 Type II 审计、HIPAA 支持、欧盟部署，以及欧盟数据处理协议 |
| 模型训练 | 我们默认不使用客户数据训练，我们的托管服务所使用的 LLM 提供商与我们签订了零数据保留和不训练协议 |
| 加密 | 静态数据采用 AES-256，传输中采用 TLS 1.2 或更高版本 |
| 保留 | 上传的文件会缓存 48 小时，然后删除。你可以随时通过 API 或 UI 删除数据，或通过以下方式跳过缓存do_not_cache=true |
| 部署 | 北美或欧盟的托管 SaaS、单租户 SaaS、你自己的 AWS、Azure 或 GCP 账户，或自托管 |
| 登录与访问 | 通过 SAML 或 OIDC 实现 SSO，外加基于角色的访问控制 |
| 文档 | 一个信任中心，包含我们的子处理商列表和安全文档，以及需签署 NDA 才能获取的渗透测试摘要 |
如果你处理第三方文档
将来自供应商、申请人或保单持有人的文档视为不可信输入。限制谁可以向共享索引添加文档，在对支付等高风险事项采取行动前检查提取的值，并对你最敏感的文件使用do_not_cache=true。
下一步
这是一次时间点测试，而每个新功能都会改变可被攻击的范围。我们预计安全测试将转向人与 AI 协同工作，并最终转向每次发布时都运行的测试。
如果你正在为敏感工作评估 LlamaParse，请从企业就绪度文档开始。你可以通过信任中心申请我们的渗透测试摘要，或与我们讨论单租户和自托管部署。