The disclosure
When you ask a question in plain language, LEDAR sends your question and a list of your table and column names to a language model, and the model picks which part of your database the question is about. It does not write the answer: every sentence you read was written by LEDAR, and every number in it came from a query LEDAR ran against your own database.
No rows of your data are ever sent. Before anything leaves your machine LEDAR shows you the destination, how many identifiers are going, how many bytes, and the full list of table names — and waits for you to agree.
You supply your own model key. LEDAR ships with none, and if you never set one the scanning, the entity map and the interview all work with no AI involved at all.
To report AI output you believe is wrong or inappropriate: Write to [email protected].
What the model is allowed to decide
The model is given a menu the product builds from your own schema, and it returns identifiers from that menu. It does not write prose, it does not write SQL, and it does not decide whether anything is wrong.
| Decision | Made by |
|---|---|
| Which table your question is about | The model, from a fixed menu |
| Which relationships to follow from there | The model, from a fixed menu |
| What SQL runs | LEDAR |
| What the numbers are | Your database |
| Every sentence you read | LEDAR |
| Whether something counts as a problem | You |
A returned identifier that is not on the menu fails the call rather than being followed. That closes one specific attack: asking the product to aim at something it never offered.
Where this has been shown to fail
The menu defence does not close every case, and the measurements say so. We fired 32 prompt-injection attempts at the live question path and 8 of them succeeded.
- Aiming outside the menu is closed.
- Aiming at the wrong table inside the menu is open. A real schema with dozens of tables has plenty of legitimate places to point at, and a wrong-but-valid target is not distinguishable from a right one by the check that rejects invalid ones.
- A published signal detects the shape of question that produced those failures, and it is deliberately not used as a gate: it can be evaded by a single space, and a gate that can be stepped around is worse than none, because the reader believes they are covered.
Using no AI at all
Connecting, proving the connection is read-only, scanning the schema, building the entity map and completing the interview all work with no model configured. If you never set a key, the product never makes a network request.
You can also point it at a model running on your own machine. Any endpoint speaking the OpenAI chat-completions shape works, including a local one, in which case nothing leaves the machine even when you do ask a question.