By Alexios vdSK and Iris Ng On behalf of the LegalQuants RED TEAM.
I planted a rigged agreement in a stack of contracts. It says it's governed by Delaware law. You can read it. Your AI chatbot can read it (and probably spot the issue). Your lawyers can read it. But your search engine can't find it.
This is the third in a series on lexploits, good old "hacking techniques" recycled to fool defenseless AI pipelines. You can read the previous two episodes here and here.
If you work in a big corporate under pressure to deliver with AI, you have probably set up a database that centralizes all your documents, with a search engine on top, before anything ever reaches your AI. And if you are a litigator or an M&A professional, your pipeline routinely uses that search to query documents produced by third parties, for example in a due diligence or a disclosure exercise in arbitration.
So you ask "show me all the contracts governed by Delaware law", the engine searches "Delaware", and flags every document that is. You probably trust this. But should you? This article explains why you should not.
I will cover, in plain terms, how search pipelines work (1), how the attack works (2), what we observed (3), who it hits (4), a preliminary conclusion (5), and how this compares to earlier Noroboto attacks (6).
1. How search pipelines usually work
When your AI searches for "Delaware", it does not read the page the way you do. It does not look at what the text looks like on screen. It works with what the text is underneath, and underneath, every character is stored as a number. Your search turns your query into those numbers and scans each document for the same sequence. This is how most enterprise-grade search works, including, most likely, the one inside your AI pipeline. It just compares numbers.
That works as long as the numbers in the document really are the characters you think they are. But what if they aren't? Who is responsible then?
2. How the attack works
Cyrillic and Latin scripts share characters that look identical but carry different codes. The Latin "a" is one number. The Cyrillic letter drawn exactly like it is another. To your eye they are the same character. To the search engine they are as unrelated as "a" and "7".
So take "Delaware" and swap a couple of Latin letters for their Cyrillic look-alikes. On screen, in print, in a PDF viewer, it still reads "Delaware". Underneath, the engine sees Del[-]w[-]re. You don't even need many. One swapped letter is enough to break the match.
Try it yourself. Put "Delaware" (with a Cyrillic letter or two) in a settlement agreement, save it as a PDF, upload it to your document system, and search "Delaware". See what happens.
3. Our empirical observations
For full transparency, we asked Claude Code to build the test and report what happened, in its own words:
“We set up a small document system the way a real one works. Ten contracts in a folder, with a search on top that does what every search does, namely turn your query into numbers and look for the same numbers in each file. Four of the ten contracts were genuinely governed by Delaware. One of those four was the rigged one. Its governing-law clause reads "Delaware" on screen, but four of its eight letters (both e's and both a's) are stored as their Cyrillic twins. One substitution would have been enough. We used four to leave no doubt.
We searched "Delaware", the way your AI tools would. The search returned three contracts and missed the fourth, the rigged settlement agreement, even though it says "State of Delaware" right there in its text. No error, no warning, no "did you mean". It was simply gone.
The only search that found it was one we built on purpose to fold look-alike letters back to Latin before comparing, and to flag any word that mixes two alphabets. That one returned all four and marked the rigged one as suspicious. So a defense exists. But it is a deliberate one you have to build in. A standard search will not do it for you, whatever the subscription costs.”
Better still, try it on your own systems, your enterprise search, or even your Google Drive.
4. Who this hits
Contract management, e-discovery and disclosure, conflict checks, deduplication. And, more generally, anyone who no longer puts armies of juniors on reading every document.
Imagine your pipeline ingests 5,000 contracts. You search "Delaware". It returns 848. There are actually 849. One was authored with Cyrillic in its governing-law clause, so it does not appear. You don't know it exists. You tell the board that every Delaware-governed contract has been reviewed. It hasn't. When that surfaces, whose fault is it? Aren't you assumed to have read the documents?
Or a litigation requires disclosure of every document mentioning, say, "Project Falcon". Some never surface. The disclosure is incomplete. If you are later accused of misleading the tribunal, are the accusations unfounded?
Or a competition authority combing your files for evidence of price-fixing or environmental damage. Or an associate at 2am searching opposing counsel's production for a single technical term. If the document is missed, who is to blame?
You are probably thinking whoever did this would get caught. In cybersecurity the motivation is obvious. There is outside attacker injecting malicious code. But legal documents are a different threat model. The obfuscation can be defensive and perfectly benign. A party hides clauses in its own documents for its own reasons, never meaning them to reach you. But documents move. They get produced in litigation, loaded into data rooms, seized by a regulator. Who carries the risk is rarely obvious, and there is ample room for plausible deniability.
5. A preliminary conclusion
Most people assume that if a document contains a specific word, the pipeline they pay their "AI LegalTech" vendor handsomely for will find it. It won't, necessarily. The text is only what its bytes say it is, and a search engine compares bytes. Substitute them and the match fails silently. By the time the results reach your AI, it is too late. As far as the search was concerned, "Delaware" was never there.
A pricier search engine won't necessarily fix this. What does is a search taught to fold look-alike characters and flag mixed-alphabet words as it indexes a document. Short of that, the only safe assumption is to stop trusting the text layer of documents you didn't create, and read them.
6. Noroboto, Episode 3 (Cancelled)
The earlier Noroboto attacks and this one exploit the same gap. What your eye sees and what the machine stores are not always the same thing. They differ in where they strike.
Noroboto goes after the reading. The AI's parser trusts the text it pulls out of a file over the picture on the page, because rendering the image and checking it is slow and expensive. Noroboto rigs the file so the extracted text says one thing while the page shows another. The document is retrieved and read as normal. The AI just reads the wrong thing and repeats it back to you with a straight face.
This attack goes after the finding, one step earlier. Nothing about the reading is wrong. Extract the text and you get exactly what is stored, honest Cyrillic and all, and it looks right. The catch is that those honest characters are the wrong alphabet, so the index never matches them to the word you typed. The contract is never retrieved, never served to your AI at all.
That is why "my AI would catch it" misses the point. Hand it the contract and it might. Claude Opus 4.8 and the free ChatGPT both flagged it on my phone. Gemini Flash calmly reported that the contract was governed by Delaware law but without flagging the Cyrillic.
But an AI can only catch what reaches it, and this attack makes sure the document never does. Noroboto lets it through and poisons the reading. This stops it at the door, one floor down, in the dull, forgotten search index in the agentic loop that only decides which documents your very expensive AI is ever allowed to see.
We won't be releasing a build for this one. There is nothing to release. It is a plain character swap anyone can do in a text box, with no code at all. Which is exactly why you shouldn't wait for a tool to take it seriously. Start reading your documents, and put real defenses on your search pipeline.