LlamaParse 如何针对敏感文档强化 AI 应用安全测试

LlamaParse turns PDFs, scans, and other messy files into structured data that AI applications can use. Many of those files are sensitive, including financial filings, insurance claims, and contracts. Before a company sends us any of them, security teams usually review our enterprise readiness documentation: SOC 2 reports, data policies, DPAs, and third-party pen tests.

Traditional pen tests are good at web apps and APIs. They aren’t built for the parts of LlamaParse where a model reads customer documents, and we wanted those tested just as thoroughly. This post covers how we did that and what we learned.

Where a document goes

In most web apps, untrusted input comes in through a form field. In LlamaParse, it comes in as a whole file, often written by someone outside the customer’s company, and it touches almost everything. We parse it, classify it, pull out fields, and index it for search. Then it gets read again by agents that customers deploy on LlamaParse and by AI assistants connected through our MCP server. A document could try to steer any of those steps.

OWASP, the nonprofit best known for its Top 10 list of web app risks, keeps a separate list of ten risks for LLM applications. Here’s how each one could show up in a document platform:

Why AI features need a different kind of test

A classic API pen test checks, for example, whether any endpoint responds without authentication. You call every endpoint without a token. Each one either rejects the request or it doesn’t, so one pass gives you a yes-or-no answer.

Models don’t work that way. The same request can get different responses, and the input itself can change how the system behaves. Scanning the source code doesn’t help much either, since a model’s behavior isn’t in the code. To test an LLM feature, a tester has to keep adjusting after every failed attempt, then repeat whatever works to show it’s reliable. Doing that for ten risk categories across every AI feature takes more patience than a few weeks of manual testing allows.

That’s where Trace came in. Trace does agentic DAST (dynamic application security testing). Its AI agents attack a running app, decide what to try next based on each response, and prove what they find with a working exploit. An OSCP-certified engineer reviews every finding before it reaches us, and once fixes are verified, Trace issues an audit-ready report, which is the kind of evidence our customers’ security teams ask for.

We gave Trace the same starting point an attacker would have after signing up: working credentials, but no source code or cloud access.

Some LlamaParse features only make sense once you build something with them, so Trace’s agents did that. They read our docs end to end, created a GitHub repo, wrote Python code, generated sample PDFs, uploaded them, ran them through the code, then changed the code and ran it again. They worked through these flows in parallel, which is how they covered the whole platform in four days. We also told them how the platform is supposed to behave, so they could tell real issues from expected behavior.

Trace runs its agents on frontier models through Anthropic’s Cyber Verification Program and OpenAI’s Daybreak program, which give vetted security companies models with fewer refusals for systems they’re authorized to test. The agents stayed on targets we’d agreed on, used only accounts we set up, proved issues without pulling real records, and never ran denial-of-service or brute-force attacks. Trace staff could pause any session.

What we learned

Our findings reached business logic, the boundaries between organizations, and how our models behave when a document tries to steer them. We fixed or mitigated every issue in the platform itself.

Some findings made us rethink where our job ends and the customer’s begins. Here’s one.

The test built an invoice with a few extra lines printed in white on a white page, giving a “corrected” total and a different bank account. The hidden lines didn’t tell the model to do anything. They just looked like a more official version of the same fields. Anyone opening the PDF saw the normal invoice, but extraction returned the hidden values, because it reads everything on the page.

In a real attack, that invoice would come from a third party, like a supplier sending bills into a customer’s accounts-payable process. So whose job is it to decide what a document really says: ours, or the pipeline the customer builds around it?

We think extraction should report what’s on the page. Deciding which values to trust belongs in the customer’s pipeline, where the business rules live. Here’s how we split it:

Enterprise controls

The pen test is one part of what a security team reviews. The rest is in our Enterprise Readiness docs:

If you process third-party documents

Treat documents from suppliers, applicants, or policyholders as untrusted input. Limit who can add documents to shared indexes, check extracted values before acting on anything high-stakes like a payment, and use do_not_cache=true for your most sensitive files.

What’s next

This was a point-in-time test, and every new feature changes what there is to attack. We expect security testing to move toward people working alongside AI, and eventually toward tests that run every time we ship.

If you’re evaluating LlamaParse for sensitive work, start with the Enterprise Readiness docs. You can request our pen test summary through the Trust Center, or talk to us about single-tenant and self-hosted deployments.