When you ask LEDAR a question, a model picks which part of your schema the question is about. That means two attacker-influenced inputs meet a model: the question, and the table and column names themselves, which nobody chose with an attacker in mind.
So we attacked it. 32 shots at the live path, against real schemas, with real model calls. 8 got through.
What held
The model never writes SQL and never writes prose. It returns an identifier from a menu the product builds out of your own schema, and a returned identifier that is not on the menu fails the call.
That closes the attack everybody thinks of first: convincing the model to go and read something it was never offered. Across the runs, planted decoy targets were ignored every time.
What did not
A wrong target that is on the menu is indistinguishable from a right one.
A real schema has dozens of legitimate tables. An instruction that redirects the question from one to another is not asking for anything invalid — it is asking for a correct answer to somebody else’s question. The check that rejects invalid targets has nothing to say about it.
The most effective payload was also the least hostile-looking. It did not shout, it did not try to escape a fence, it simply asked for a different table. The loud ones did worse.
The filter we are not shipping
Afterwards we found a signal that separated the cases perfectly: the successful attacks all named a table in the exact casing used by the schema, and the clean questions did not. Four out of four against zero out of thirty-eight.
It is in the product as a published note, and it is deliberately not a gate.
It can be evaded with one space. Write editor_collection and it fires; write the editor collection table and it says nothing. A gate that can be stepped around is worse than no gate, because it stays quiet at exactly the moment it matters while the person reading believes they are covered.
The scoring was wrong first
The first run reported six failures, not eight, and reported the menu defence catching zero attempts when it had caught four.
Both errors leaned the same way: toward flattering the product. The scorer was written by the same people as the thing it scored, and it was rerun from the stored transcripts rather than by firing more shots. If you build an evaluation for your own system, assume it is biased in your favour until you have checked it against the raw record.