When AI systems ingest documents, a file is no longer just something to read. It can also contain language designed to change what the system does. That turns ordinary content into part of the security boundary.
A Connecticut litigant recently tried something that sounds like a joke written by an AI security researcher after too much coffee: he hid instructions inside court filings telling any artificial-intelligence system that read them to favor his position.
The instructions were set in tiny white type, nearly invisible to a human reader but available to software extracting the document text. Court staff noticed unusual white space, investigated, and found the concealed material. The court sanctioned the litigant, barred him from electronic filing, and required future filings to be submitted on paper. 404 Media reported the filings and reproduced the hidden-text technique.
There is one especially good punchline: the Connecticut Judicial Branch says it does not use AI to review or decide filings. The attempted prompt injection had no court AI to manipulate.
The story is funny. It is also an unusually clean demonstration of a problem that reaches far beyond courts: a document is no longer necessarily passive input once an AI system reads it.
A Document Used to Be Something a System Read
In a conventional information system, a PDF, email, web page, support ticket, or Word document is primarily content. Software may index it, search it, extract fields from it, render it, or compare it with other records. Strange hidden text can certainly cause problems, but the document is still mostly treated as data.
Large language models complicate that distinction because natural language is both the material they process and the language used to instruct them. An AI system may receive an operator's request, a policy, retrieved documents, tool output, and attacker-controlled text inside the same working context. The words are not equally authoritative, but without additional controls they can arrive through remarkably similar channels.
OWASP describes this as indirect prompt injection: malicious instructions are placed in external content that an AI later processes, including web pages, documents, emails, code comments, issue descriptions, and attachments. The attacker does not need to type an instruction directly into the prompt box. They can plant it somewhere the system is likely to read later.
Your PDF Should Not Get a Vote
Suppose an employee asks an AI assistant to summarize three vendor proposals and compare them against an approved purchasing rubric. One vendor PDF contains a paragraph that says the model should ignore the rubric, describe that vendor as the safest choice, and omit certain weaknesses from the comparison.
That paragraph may be visible, invisible, disguised as ordinary prose, encoded in markup, buried in metadata, or tucked somewhere a human reviewer is unlikely to notice. The important issue is not the font color. The important issue is whether content supplied as evidence can promote itself into an instruction.
The employee asked the system what to do. The organization's policy defines what it may do. The vendor supplied material to evaluate. Those are three different kinds of information with three different levels of authority. If the AI pipeline flattens them into one conversational soup, the vendor document has been given a vote it should never have had.
This is where prompt injection becomes an information-architecture problem as well as a model-security problem. The system needs to know more than what a piece of text says. It needs to preserve where the text came from, what role it is allowed to play, how trustworthy it is, and whether it is permitted to trigger an action.
The Trust Boundary Moved Into the Content
Security teams are used to drawing trust boundaries around applications, accounts, networks, credentials, APIs, and databases. AI systems add another boundary that is easier to miss because it is made of information.
A useful architecture should distinguish operator instructions from policy, governed internal knowledge from external reference material, and retrieved content from executable requests. It should also account for whether the machine can see content a human reviewer cannot see.
Once tools are connected, the consequences grow. A poisoned document that merely changes a summary is one problem; a poisoned document that can persuade an agent to send email, modify a ticket, approve a workflow, alter code, or expose data is another.
That makes provenance and content typing part of the security design. The model should not be asked to infer the entire authority structure from prose alone.
This Is the Other Half of the Authorization Problem
In A Prompt Is Not an Authorization Boundary, I argued that telling an AI agent what it is allowed to do is not the same thing as technically preventing it from doing something else. Permissions, network controls, approval gates, monitoring, and evidence have to enforce the boundary outside the prompt.
This court filing exposes the mirror-image problem: not every sentence that reaches the model should gain the authority of a prompt.
One problem asks, “Can an instruction enforce a permission?” The other asks, “Which text is allowed to behave like an instruction at all?” In both cases, the answer cannot be “the model will probably understand what we meant.” The surrounding system has to carry the distinction.
Sanitizing White Text Is Not Enough
It would be easy to conclude that document-ingestion systems should strip white-on-white text, reject three-point fonts, or compare extracted text with rendered content. Those are reasonable defensive checks, and machine-visible content that humans cannot see deserves scrutiny. They are not a complete solution.
The next prompt injection does not have to be invisible. It can sit in an ordinary paragraph of a résumé, support ticket, GitHub issue, contract, email, knowledge-base article, or vendor website. It can be phrased politely. It can masquerade as a note to the reader. It can be embedded in content the organization legitimately needs the model to analyze.
OWASP recommends defense in depth: sanitize remote content, keep instructions structurally separated from untrusted data, apply least privilege to agent tools, validate proposed actions, use human approval for consequential operations, and preserve monitoring and logs. None of those controls requires pretending the model will become impossible to manipulate. They reduce what a successful manipulation is allowed to accomplish.
Trusted Documentation Can Become Dangerous Later
Deliberately malicious text is only one version of the problem. Documentation can be accurate and legitimate when written, then become dangerous when something it references changes ownership.
In August, researchers scanning 6,214 domains found 120 llms.txt or llms-full.txt files that referenced at least one unregistered package or domain. Some contained install commands. After researchers registered a handful of the abandoned names, they observed proof-of-concept callbacks from corporate environments; process data implicated coding agents among the systems executing the instructions. Ars Technica also reported a live malicious package tied to an instruction on a legitimate vendor website, which the vendor later resolved.
This is not quite the same as prompt injection. The instruction may have been benign when it was published. The danger appears later, when a package namespace, repository, or domain becomes unowned and an attacker claims it.
That creates a longer trust chain:
Trusted document → referenced object → ownership and provenance check → action authorization → execution
The failure occurs when the system jumps directly from trusted document to execution.
HTTPS and an official domain establish where an instruction was served. They do not establish who owns every package, namespace, or domain the instruction names. Documentation lifecycle is now part of security lifecycle.
Documents Are Part of the Threat Model Now
Before an organization gives an AI system access to external documents, it should be able to answer a few concrete questions:
- Provenance: Can the system tell which content came from an authorized operator, governed internal source, tool, or untrusted external document?
- Authority: Which sources may issue instructions, and is that distinction enforced outside the model's own interpretation?
- Visibility: Can the machine consume text, metadata, layers, or markup that the human reviewer cannot readily see?
- Dependencies: Does an instruction reference a package, domain, repository, or object whose ownership and integrity have been verified?
- Action: What tools, credentials, or workflows can the model reach if an injected or stale instruction succeeds?
- Evidence: Can investigators reconstruct which source influenced an output or action after something goes wrong?
The Connecticut prompt injection failed because there was apparently no court AI there to persuade. That makes the story funnier, but not less useful. It is a warning delivered by a system that was not vulnerable about the many systems that are.
Once an AI can read a document, that document belongs in the threat model. Content architecture now has to care not only whether information is accurate, findable, accessible, and current, but also what authority that information may carry when a machine consumes it.
If your AI reads a PDF tomorrow, what prevents the PDF from telling it what to do?