Hidden Prompts in Court Filings: The First AI Evidence-Tampering Warning
Hidden Prompts in Court Filings: The First AI Evidence-Tampering Warning
A legal filing with invisible AI instructions sounds like a courtroom oddity. It is actually a preview of a much larger enterprise security problem: the records your agents ingest can now carry instructions for the agents themselves.
In August 2026, a Connecticut court sanctioned a self-represented litigant after finding hidden prompt-injection instructions inside court filings. The text was formatted to be nearly invisible to a human reader while remaining legible to software. The court said it does not use AI to decide filings, but that detail is almost beside the point. Lawyers, clerks, compliance teams, insurers, investigators, auditors, and enterprise review teams increasingly use AI systems to summarize and route documents.
That means the document is no longer passive evidence. In an agentic workflow, it can become an instruction source.
The security lesson
Prompt injection is crossing from “someone tricked a chatbot” into “someone tampered with the machine-readable layer of a business record”. That changes ownership from AI product teams to security, legal, compliance, records, and governance.
The incident is small. The pattern is not.
According to public reporting, the hidden instructions were placed in court filings using tiny white text. Court staff noticed unusual whitespace and the judge later issued sanctions, including revoking electronic filing privileges. Coverage from 404 Media, Ars Technica, CT Insider, SC World, and legal analyses all converge on the same core facts: the attempt did not affect the court outcome, but it showed that adversarial parties are starting to write documents for both humans and AI systems.
This is the same primitive security teams have seen in emails, webpages, resumes, PDFs, pull requests, logs, tickets, and support chats. The difference is the institutional context. In legal, compliance, procurement, audit, HR, and risk review, the input is supposed to be authoritative. Review systems are often designed to preserve fidelity, not neutralize instructions.
That creates a nasty inversion:
The attack does not need code execution. It does not need a vulnerable library. It does not even need the target institution to officially deploy AI in the decision loop. It only needs one downstream actor to use an AI assistant on the record.
Why security teams should care
Most enterprise AI controls still assume a clean separation between “instructions” and “documents”. The system prompt gives the policy. The user gives the task. The retrieved documents provide facts.
That separation is fiction once the documents are adversarial.
Consider the normal flow for a high-stakes review:
- A document is uploaded to a portal.
- OCR or text extraction turns it into model-readable text.
- A retrieval system chunks and stores it.
- An agent summarizes, classifies, compares, or routes it.
- A human reviews the AI output and treats it as a productivity layer.
At every step, the hidden prompt can survive. White text, tiny text, metadata, comments, alt text, hidden layers, zero-width characters, footnotes, and OCR artifacts can all become part of the agent context. If the agent has tools, the issue is larger than a biased summary. The payload can try to influence which matter is escalated, which clause is marked risky, which invoice is approved, which customer record is updated, or which evidence item gets prioritized.
| Old assumption | What agentic workflows require | Security consequence |
|---|---|---|
| Documents are content | Documents are untrusted instruction carriers | Screen invisible and machine-only text before model ingestion |
| A human can spot abuse | The AI sees bytes the human may not see | Render human view and model view side by side for sensitive flows |
| Summaries are low risk | Summaries influence decisions, routing, and approvals | Treat AI recommendations as decision-support artifacts with audit trails |
| Prompt injection is an app bug | Prompt injection is records integrity risk | Bring legal, compliance, records, and security into one control model |
The OWASP Agentic Top 10 lens
The OWASP Top 10 for Agentic Applications (2026) is useful here because the failure is not only “bad prompt handling”. It is a chain across goal control, tool use, memory, oversight, and accountability.
The closest mapping starts with ASI01: Agent Goal Hijack. The hidden text attempts to redirect the agent from the user’s legitimate goal, such as “summarize this filing neutrally”, toward the document author’s preferred outcome. It also touches ASI05: Inadequate Human Oversight, because the human reviewer may see the formatted document while the agent sees a different text layer. If extracted text is stored for future matters, it becomes a persistence problem. If the agent can update records or trigger workflow actions, it can become tool misuse.
The right response is not “ban AI from document review”. That is unrealistic, and in many teams it is already too late. The right response is to stop treating document ingestion as a neutral preprocessing step.
Practical rule
Any content that came from an adversarial or incentive-bearing party must be passed to agents as data, never as authority. The agent should know where the text came from, what trust tier it has, and what actions it is allowed to influence.
What to change this quarter
This incident gives security teams a clean tabletop scenario. It is easy to explain, easy to simulate, and likely to show gaps fast.
[CTRL] Ingestion controls
- Detect white-on-white, tiny-font, hidden-layer, comment, metadata, and zero-width text.
- Normalize extracted text and preserve a diff between visual rendering and model-visible text.
- Label adversarial sources before retrieval, especially filings, contracts, claims, resumes, support messages, and external tickets.
- Strip or quarantine instructions addressed to AI systems when they appear inside evidence or records.
[POL] Runtime controls
- Give agents explicit policy that retrieved records are evidence, not commands.
- Block document-originated text from changing system behavior, output policy, tool selection, or approval thresholds.
- Require human confirmation for any action that changes case status, risk score, payment state, customer record, or access rights.
- Log source attribution for each material recommendation so reviewers can inspect the exact evidence trail.
Security teams should also test the controls with realistic payloads. A useful exercise is to seed hidden instructions into a harmless sample filing, contract, diligence PDF, vendor questionnaire, or HR document. Then run it through the actual review path. Do not only ask whether the model repeats the instruction. Ask whether the instruction changes ranking, risk language, escalation, tool choice, or human confidence.
The strongest signal is not “the AI was fooled”. The strongest signal is “the AI output became more favorable to the adversarial document author, and nobody could explain why”.
The board-level version
The Connecticut case will be remembered because it is concrete. A person hid prompt instructions in a formal filing. A judge found it. A sanction followed.
But the enterprise version will be quieter. It will look like a vendor risk summary that underweights a clause. A claims workflow that routes a file to the wrong queue. A diligence assistant that misses a conflict. A procurement agent that treats a self-serving assertion as verified. A support agent that escalates based on text the customer could hide from the human reader.
The question for CISOs is not “are we using AI in court filings”. It is:
Where do we ingest adversarial documents into AI-assisted workflows, and can the document author influence the agent beyond the facts in the document?
If the answer is “we do not know”, the document pipeline is now part of the security boundary.