The compile-time vs runtime safety tradeoff is worth calling out. For infrastructure tooling where correctness matters more than iteration speed, the upfront cost pays dividends in reduced production incidents.
Fraudulent misrepresentation is a tort claim, typically arising in the field of contract law, that occurs when a defendant makes a intentional or reckless misrepresentation of fact or opinion with the intention to coerce a party into action or inaction on the basis of that misrepresentation.
To determine whether fraudulent misrepresentation occurred, the court will look for six factors:
A representation was made
The representation was false
That when made, the defendant knew that the representation was false or that the defendant made the statement recklessly without knowledge of its truth
That the fraudulent misrepresentation was made with the intention that the plaintiff rely on it
That the plaintiff did rely on the fraudulent misrepresentation
That the plaintiff suffered harm as a result of the fraudulent misrepresentation
Like most claims under contract law, the standard remedy for fraudulent misrepresentation is damages.
That would be an open question in every jurisdiction. There wasn't really a representation here, but it might be something more like the doctrine of "mistake". It's also not clear "your honor I never read the contract but my LLM told me it was okay to sign" is a great argument either. Doubly-true for your $1,500/hour law firm duped by something like this.
[Edit: by "nullify" you probably mean "void" or "voidable" which are remedies in equity, and the "never read it" argument carries even more burden there. As the citation notes the traditional remedy for contract issues is damages (i.e., cash payment).]
Wouldn't ligatures be a more effective attack vector for the "Maryland -> Delaware" case? That's all that ligatures do -- render a specific sequence of characters as something else.
We're definitely not TrueType experts and took the relatively "straightforward" approach of generating a small custom font for each mapping. If it's possible to render "Maryland" with ligatures while mapping the same string to "Delaware" in Unicode, then that's just another example of the vector. Really interesting stuff, and we'll be checking it out!
At that point you can just paste a screenshot of your doc into word and celebrate.
Also, the mitigation can probably be fooled with ligatures since they are only verifying the letters alone as far as I skimmed.
I don’t even understand the threat model. Is my opponent in a court case going to use this on the PDF they give the court? Surely the judge will be pretty annoyed since you can’t even ctrl+f in the files then.
That's true for the full obfuscation, but not for the replacement. For replacement there's really nothing like it. We just shared the full obfuscation as just a PoC.
[Edit: The point here is not to prove some massive "gotcha", but rather demonstrate that there are a whole class of vulnerabilities that these pipelines are subject to. There will be follow-up posts that pack much more punch.]
Assuming you’re the author since you also posted it: I just stealth-edited my comment, could you maybe talk about the threat model a bit more? I am not a lawyer so I don’t really see when I would want to do this.
Also, I hope the „lame exploit“ I just edited out was not too offensive, it’s always great when people try to find attacks to make systems more safe.
Absolutely, and we definitely agree this particular attack is "lame" in the sense of not allowing CVE, etc.
But, we're working on a lot of these (as we encounter them in developing Tritium), and the point really is just to demonstrate that LLMs can be blind to ineffective implementations of the specs and other tricks.
As mentioned in the accompanying LegalQuants post, we see a lot of these available in the pipelines of applications like Claude for Legal, Harvey, Legora and others.
The most nefarious case here requires crafting a number of custom fonts to do character-swapping. It's less discoverable but may be sanctionable to your point.
But bear in mind this particular "attack" was vibe coded in a day or two and most of the frontier models fail to pick up on it. As "AI native" firms come on line, and aim to be increasingly end-to-end automated, these will become real legal issues.
It seems like the main attack scenario for this + legal AI would be during discovery: if opposing counsel gave you a poisoned PDF, and you threw it into one of these products to help you sift through it and got bad answers.
However, wouldnt this be a rather risky move? Courts authorized the discovery, so I imagine the judge might loose their marbles and throw the hammer at them if this came to light.
Yes, this particular vector is probably better in contracting than discovery. There is a duty of candor to the court and court rules that might come into play. In the case of contracting the attacker would be exposed to the jurisdiction's law of contracts. That might call it a "misrepresentation" or fraudulent thus making the contract void or voidable, but it's not clear "your honor I never read the contract but my LLM told me it was okay to sign" is a great argument either.
The compile-time vs runtime safety tradeoff is worth calling out. For infrastructure tooling where correctness matters more than iteration speed, the upfront cost pays dividends in reduced production incidents.
I think that this is an attack on the understanding of the LLM _potentially_ but it doesn't seem like it's likely to standup to legal scrutiny?
Seems like this is pretty clearly a case of fraudulent misrepresentation (https://www.law.cornell.edu/wex/fraudulent_misrepresentation) which kinda nullifies the contract, if I understand correctly:
That would be an open question in every jurisdiction. There wasn't really a representation here, but it might be something more like the doctrine of "mistake". It's also not clear "your honor I never read the contract but my LLM told me it was okay to sign" is a great argument either. Doubly-true for your $1,500/hour law firm duped by something like this.
[Edit: by "nullify" you probably mean "void" or "voidable" which are remedies in equity, and the "never read it" argument carries even more burden there. As the citation notes the traditional remedy for contract issues is damages (i.e., cash payment).]
Wouldn't ligatures be a more effective attack vector for the "Maryland -> Delaware" case? That's all that ligatures do -- render a specific sequence of characters as something else.
We're definitely not TrueType experts and took the relatively "straightforward" approach of generating a small custom font for each mapping. If it's possible to render "Maryland" with ligatures while mapping the same string to "Delaware" in Unicode, then that's just another example of the vector. Really interesting stuff, and we'll be checking it out!
These are some very extreme examples of this that push the feature's limits:
https://news.ycombinator.com/item?id=47256810
https://news.ycombinator.com/item?id=26495059
Came here to say this, I saw the initial video and thought they used ligatures, and then I was surprised the actual post was much more complicated.
At that point you can just paste a screenshot of your doc into word and celebrate.
Also, the mitigation can probably be fooled with ligatures since they are only verifying the letters alone as far as I skimmed.
I don’t even understand the threat model. Is my opponent in a court case going to use this on the PDF they give the court? Surely the judge will be pretty annoyed since you can’t even ctrl+f in the files then.
That's true for the full obfuscation, but not for the replacement. For replacement there's really nothing like it. We just shared the full obfuscation as just a PoC.
[Edit: The point here is not to prove some massive "gotcha", but rather demonstrate that there are a whole class of vulnerabilities that these pipelines are subject to. There will be follow-up posts that pack much more punch.]
Assuming you’re the author since you also posted it: I just stealth-edited my comment, could you maybe talk about the threat model a bit more? I am not a lawyer so I don’t really see when I would want to do this.
Also, I hope the „lame exploit“ I just edited out was not too offensive, it’s always great when people try to find attacks to make systems more safe.
Absolutely, and we definitely agree this particular attack is "lame" in the sense of not allowing CVE, etc.
But, we're working on a lot of these (as we encounter them in developing Tritium), and the point really is just to demonstrate that LLMs can be blind to ineffective implementations of the specs and other tricks.
As mentioned in the accompanying LegalQuants post, we see a lot of these available in the pipelines of applications like Claude for Legal, Harvey, Legora and others.
The most nefarious case here requires crafting a number of custom fonts to do character-swapping. It's less discoverable but may be sanctionable to your point.
But bear in mind this particular "attack" was vibe coded in a day or two and most of the frontier models fail to pick up on it. As "AI native" firms come on line, and aim to be increasingly end-to-end automated, these will become real legal issues.
And there will be a lot of them available.
It seems like the main attack scenario for this + legal AI would be during discovery: if opposing counsel gave you a poisoned PDF, and you threw it into one of these products to help you sift through it and got bad answers.
However, wouldnt this be a rather risky move? Courts authorized the discovery, so I imagine the judge might loose their marbles and throw the hammer at them if this came to light.
Yes, this particular vector is probably better in contracting than discovery. There is a duty of candor to the court and court rules that might come into play. In the case of contracting the attacker would be exposed to the jurisdiction's law of contracts. That might call it a "misrepresentation" or fraudulent thus making the contract void or voidable, but it's not clear "your honor I never read the contract but my LLM told me it was okay to sign" is a great argument either.
Someone could also just make a font file that swaps all of the characters around. So like an A looks like a Z, and a Z looks like an A.
Covered in the post! It's the more aggressive approach for sure.