You are handing us production credentials. Here is exactly what happens to them.

No. Every connection Datafliq opens is read-only: your data can be read, never changed or deleted. An assistant cannot alter a row, drop a table, or touch your schema, and two separate controls enforce that.

Your database enforces it. On Postgres, MySQL and SQLite, Datafliq opens the connection in read-only mode, so your own database refuses any write outright. The guarantee comes from the engine that holds your data rather than from software sitting in front of it, and on Postgres it protects your schema as well as your rows.

Datafliq enforces it too. Before anything runs, every source gets a second check: only a single, straightforward read statement is allowed through. That check works from a list of what is permitted rather than a list of what is banned, so reads reach your data and nothing else does. It covers every source you can connect, including spreadsheets and SQL Server. MongoDB connections only ever issue a find.

Encrypted at rest with AES-256-GCM before they reach the database. Every credential gets its own random initialisation vector and an authentication tag, so a stored value cannot be silently altered without decryption failing.

Each encrypted value records which key encrypted it, so keys can be rotated without re-encrypting everything at once. Encryption keys live in the environment, never in the database beside the data they protect. Credentials are never returned to the browser after saving, never written to logs, and never exposed to the model.

On Datafliq’s servers, connecting outward to your database. Nothing is installed in your environment and your data is not copied into ours. We open a read-only connection, run the statement, and pass the rows back to your assistant. You will need to permit network access from our servers to your database. Spreadsheet and file sources are the exception: those are read into a temporary in-memory workspace that is destroyed when the query finishes.

No. Results are streamed back to your assistant and are never written to disk, cached, or stored in our database. This means we cannot show you a history of past query results, which is a deliberate trade.

The rows your query returns. That is how the assistant answers your question, so it is worth being precise about where the boundary sits.

It sees results from the sources you connected and the tables it queried. It does not see your database credentials, tables it did not query, sources you have not connected, or sources assigned to a teammate but not to you. Your credentials are used by our server to open the connection and are never placed in the model’s context.

You assign access per source. Members can query only the sources you explicitly grant them; admins can query every source in the organisation. That scoping is applied when the assistant connects and asks for the source list, not merely hidden in the interface. A member’s assistant is never handed a connection to a source they were not assigned. Revoking access takes effect on the next query.

Traffic to Datafliq is TLS-encrypted and the domain is served with HSTS, so browsers refuse to connect over plain HTTP. Your assistant reaches your data through a unique MCP link tied to your organisation, and that link can be rotated if you believe it has been exposed.