SQL guardrails
Before a question reaches your database, the SQL that answers it goes through a strict check. It is there to keep STYD to safe, read-only queries.
What the check enforces
One SELECT statement. Writes, structure changes, locking, INTO and several statements in one call are refused.
Only built-in functions from an allow-list for your database type. A function that is not on the list, or that belongs to another schema, is refused.
No system catalogs (such as information_schema or pg_catalog): they cannot be filtered by what a member may see.
Only the tables and columns of your own database. A reference to anything else is refused or sent back to be corrected.
A table hidden from the member asking is refused on every way of asking: the chat, the API and AI apps.
Secret values (passwords, tokens, keys, card and bank numbers) are replaced by [hidden] in results.
Values STYD builds itself
When STYD's own code looks up your tables or counts rows, the values it uses are sent to the database as bound parameters, not pasted into the SQL text. The table and column names are checked against your database first.
When the check cannot decide
The check fails closed. If the SQL cannot be read, or STYD does not yet know the layout of your database, the query does not run and the answer says so. After a refusal STYD may retry a limited number of times with a corrected query, but a safety refusal is final.
Guardrails do not replace database permissions
Treat guardrails as a strong layer, not a guarantee. The strongest protection is the database account itself: connect with a read-only, least-privilege user so the database enforces what STYD can and cannot do, independently of any application behavior.
Your part
Always connect with read-only database credentials.
Scope that user to only the data STYD needs.
Combine this with table visibility and workspace roles.
No security control is absolute. Layered protection (database permissions, read-only access, visibility and roles) is what keeps things safe.