Security & governance
Not as a worry, as a design input. Every protection below works whether or not the model behaves, because none of them depends on the model behaving.
Only SELECT is permitted. Anything that writes, deletes or alters is
rejected before it reaches your database — by a parser that understands SQL,
not by an instruction asking the model to be careful.
Business and branch filters are attached after the model has finished composing. It never writes them, so whether they are present does not depend on anything it produced.
We store a reference to your database credential, never the credential. It lives in a managed secrets vault. A breach of our systems is not a route into yours.
Who asked, what was asked, what ran, how many rows came back. Available to your administrators, retained for as long as your plan specifies.
The one that matters most
Multi-tenancy in a lending business is not a nice-to-have. One shop reading another's book is a serious incident, and it is the failure most likely to be caused by a model that means well.
SELECT customer_name, due_date FROM payment_schedule WHERE due_date < CURDATE()
A perfectly reasonable query. It would also return every branch in the business, and every business on the platform.
SELECT customer_name, due_date
FROM payment_schedule
WHERE due_date < CURDATE()
AND business_id = 7
AND branch_id IN (1, 2)
AND branch_id IN (
SELECT branch_id FROM staff_branches
WHERE staff_id = 42 AND status = 'ACTIVE')
LIMIT 501
Three separate boundaries: the business, the branches the session covers, and the branches that member of staff is actually assigned to.
There is no override switch, no administrator bypass, and no fallback that executes the query unscoped. A question that cannot be safely bounded returns an error, not a result. This is deliberate: a setting that turns scoping off is a setting somebody eventually turns off.
Answers you can trust
PawnTeller answers from a configuration that names your tables, your columns and what your business terms mean. Ask for something nobody has defined — a risk rating, a ratio you have never specified — and it says there is no configured rule for it.
It will then offer the related facts it can show, clearly labelled as related rather than as the thing you asked for.
Every answer comes with the rows it was drawn from. The sentence is a summary of a table you can read yourself, not a claim you have to take on faith.
Results are capped and marked when capped, so a partial page is never presented as a total.
The connection
| Question | Answer |
|---|---|
| Do you copy our data? | No. PawnTeller reads your live database at the moment a question is asked. There is no export, no nightly sync and no warehouse. |
| Is the connection encrypted? | Yes — TLS 1.2 or above, with the certificate chain verified. An unverified connection is refused rather than downgraded. |
| What access does it need? | A read-only account restricted to the tables in your configuration. It cannot be granted write access it does not ask for. |
| Where do credentials live? | In a managed secrets vault. Our own database holds a reference only, so a copy of it is not a way into yours. |
| What does the AI see? | Table and column names, and the rows returned by the query it proposed. Never a credential, a hostname, or anything belonging to another business. |
| Can we see what it did? | Yes. Every question, the query that ran, who asked and how many rows came back, kept for the retention period on your plan. |
If you have a review process, we would rather go through it early than late. Send us the questionnaire.