What Askbase runs against your database, and how to make sure it cannot run anything else

This page is written for whoever decides whether this software is allowed near a production database. It is not a sales page. The short version: create a role that can only read, give that role to Askbase, and treat everything the application does as a second line rather than the first.

What the application executes

Every generated statement is parsed before execution and runs only if it passes a whitelist. Anything not on the list is refused, shown to the user with the reason, and never sent to the database.

• Exactly one statement. A semicolon followed by a second statement is refused.
• SELECT only, a leading WITH is allowed.
• No INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, TRUNCATE, GRANT.
• No transaction control, no PRAGMA, no administrative commands.
• No recursive WITH.
• Tables and qualified columns are checked against the schema snapshot taken at connection time.
• If the statement has no LIMIT, the application adds one.

On top of that, each query carries a timeout and a cap on the number of rows returned.

Why the application's own rules are not enough

Because one layer is one layer. Pedro and co-authors showed at ICSE 2025 that on an unmodified agent framework an instruction injected through text obtains full read and write access, and that attempts to defend by rewording the prompt proved exceedingly fragile.

Separately, a read-only role does not prevent denial of service. In a vulnerability report against Langchain-Chatchat, a heavy recursive WITH exhausted resources while read-only mode was enabled. That is why recursive expressions are refused by the parser here, not by permissions.

PostgreSQL

Substitute your own names for analytics, askbase_ro and the password.

CREATE ROLE askbase_ro LOGIN PASSWORD 'set_your_own_password';

GRANT CONNECT ON DATABASE analytics TO askbase_ro;
REVOKE CREATE ON SCHEMA public FROM askbase_ro;
GRANT USAGE ON SCHEMA public TO askbase_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO askbase_ro;

ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO askbase_ro;

Bound the resources on the role, so that a heavy query cannot affect anyone else.

ALTER ROLE askbase_ro SET statement_timeout = '30s';
ALTER ROLE askbase_ro SET idle_in_transaction_session_timeout = '60s';
ALTER ROLE askbase_ro SET default_transaction_read_only = on;

If some columns must not be read at all, do not grant the table. Create a view with the permitted columns and grant that instead.

CREATE VIEW clients_safe AS
  SELECT id, region_id, dt_reg FROM clients;   -- no names, no phone numbers
GRANT SELECT ON clients_safe TO askbase_ro;
REVOKE SELECT ON clients FROM askbase_ro;

This also improves the answers. The schema snapshot will contain only what is permitted, so the model will not write queries against columns it cannot read.

MySQL

CREATE USER 'askbase_ro'@'localhost' IDENTIFIED BY 'set_your_own_password';
GRANT SELECT ON analytics.* TO 'askbase_ro'@'localhost';
FLUSH PRIVILEGES;

ALTER USER 'askbase_ro'@'localhost'
  WITH MAX_QUERIES_PER_HOUR 2000 MAX_USER_CONNECTIONS 4;

MySQL has no per-role statement timeout, so the timeout is enforced by the application. As with PostgreSQL, hide individual columns behind views rather than granting the underlying tables.

SQLite

SQLite has no users; permissions are the file's. Work from a copy rather than the live file, and take the copy in a way that cannot catch the database mid-write.

sqlite3 /path/to/analytics.sqlite ".backup '/path/to/analytics-ro.sqlite'"
chmod 444 /path/to/analytics-ro.sqlite

Four checks before you allow it

1. Connect with the new role. The connection screen reports the privileges it found. A warning about write access means the role is not what you intended.
2. Switch off the Wi-Fi and ask a question. The answer should still arrive.
3. Open the query log and confirm it holds statements and row counts, not data.
4. From that role, try to create a table. It must fail on permissions.

What we cannot do for you

A read-only role does not limit which data a person may see. If someone must not see salaries, that restriction belongs in the permissions or in a view, not in the application. Askbase will honestly show everything the role can reach.