Case Study: Prompt Injection in a US Courtroom

The case: hidden text in the filing

In August 2026, a Connecticut court offered a rare case study on artificial intelligence. Matthew Elliott filed documents with text invisible to the human eye but readable by a machine.

Judge Walter Spader Jr. discovered the maneuver. He called it a dangerous precedent.

The underlying lawsuit involved a man accusing a healthcare provider of withholding access to his medical records. The secret text aimed at a goal separate from the merits: to bend any automated reading of the file in his favor.

According to Ars Technica, this appears to be the first documented case in the United States in which a party hides text readable only by an artificial intelligence system in order to win a lawsuit. The attempt opens a new chapter for the courts.

The original idea: prompt injection disguised as a legal filing

The idea behind the move was simple and insidious. Elliott inserted instructions formatted to be invisible to a human reader, while remaining fully readable by any software that processes text, as Spader explained.

The technical trick was crude. Tiny font size, white text on a white background.

To a person's eye, it looked like a clean page. To a model, it looked like an explicit command. The instructions ordered the system to align its responses with the plaintiff's arguments, to ignore the court's previous denials, and to guarantee the desired remedy.

This scheme has a precise technical name: prompt injection. It is the same class of attack that worries anyone building assistants that read content generated by strangers. The mechanism exploits a known limitation of language models. The model receives a single stream of text. Within that stream it does not clearly distinguish between the document to be analyzed and the instructions to be executed. Whoever writes the document can therefore issue commands to the system that reads it.

The verified results

The court assessed the filing on its actual content. The hidden text had zero impact on the outcome, the judge confirmed.

Here are the facts established from the record:

• The manipulation attempt failed: the court judged the filing on its actual content.
• Elliott received modest sanctions for serious litigation misconduct.
• The Connecticut Judicial Branch does not use AI to review or decide filings.

This last detail explains why the attack fell flat. Zero models were reading those papers in the judge's place. The reading remained human from start to finish.

This fact distinguishes a verified result from a theoretical alarm. The abuse is real and documented. The actual harm, in this case, remains absent. The limit of this evidence should also be noted. The case demonstrates the attempt, not its effectiveness against a real system. No model was put to the test here. We know the attack exists. We do not know, from this record, how well it would have worked against an AI-assisted judgment.

The judge applied sanctions nonetheless. The reason lies in the conduct, more than in the effect.

The anomaly: the jokes after the warning

The most instructive moment comes after the warning. The court had already flagged to Elliott the concrete risk of penalties.

He continued to insert hidden text in new filings. He told the court these were jokes.

Among the messages were a link to a Nosferatu video on YouTube and a line reading "hi :) I hope yo ucant see me". The judge also recorded text he described as nonsensical. "That plaintiff continued to hide messages in new filings after receiving notice of this hearing is troubling," Spader wrote.

This persistence turns an isolated stunt into a pattern. And it is the pattern, more than the single line, that defines the abuse in the court's eyes. Repetition matters. A single error can pass for an oversight. Conduct repeated after an explicit warning reveals intent. It is this distinction that guided the judge's decision.

What changes for those building with AI

This case study exposes a risk that concerns every product team. Every organization that entrusts a model with reading external documents inherits the same vulnerability.

The attack surface is enormous. A contract, a résumé, an email, a support ticket, a web form: any incoming text can host hostile instructions.

The model, by design, tends to treat those instructions as legitimate commands. Here lies the heart of the problem. The system struggles to distinguish between the data to be read and the order to be executed.

The defense exists and remains architectural. Separate data input from system instructions. Sanitize incoming text. Validate outputs with human checks on critical steps. None of these measures, alone, closes the problem. Together they reduce the attack surface. Human oversight of critical steps remains the last line. It is needed precisely when automated text is not enough to guarantee the result.

The institutional and geographic boundary

One detail deserves particular attention. Spader notes that, unlike a number of judicial systems elsewhere, Connecticut avoids AI to review or decide filings.

The sentence reveals a broader truth. The adoption of AI in public institutions proceeds at different speeds by jurisdiction. Some courts already integrate it into their workflows.

Here the future risk emerges. As these tools enter judicial systems, the attack surface grows alongside adoption. Elliott hit an empty target today. Tomorrow the same trick could reach an active model, with real effects on a decision.

What to take away from this story

The transferable lesson is clear. The advantage of an AI deployment depends on the architectural decision, more than on the tool chosen.

Anyone leading an SME should map every point where a model reads text produced by third parties. Anyone leading a product should treat external input as potentially hostile by default. You can find more real-world cases in our blog.

For a board of directors the message is direct. Operational maturity is measured by the ability to anticipate abuse before it becomes a headline. The willingness to revisit one's own workflows is a sign of solidity, more than of weakness.

For a team lead, the first step is concrete: list the sources of text that your system reads automatically. Every defense starts from that list. You cannot protect an input that no one has mapped.

The open question

Elliott lost. His attempt nonetheless remains a valuable warning for anyone building systems that read documents.

The question every organization should ask itself is simple and uncomfortable. How many of your automated workflows read text that an outside person can write freely? And who verifies that text before the model interprets it as an order?

I could do it too: this time the sentence works as a defense, before it works as an opportunity.