Read-only by default.
Written for the person who has to approve the connection. Queries run through read-only connections with table-level access controls, and every answer shows the SQL behind it.
Query path
Read-only
Access
Selected per table
Answers
SQL always visible
Execution
Isolated sessions
Queries run read-only
A controlled query path accepts reading and inspection statements.
Aten attaches your database as a read-only connection. The query layer accepts only read statements — SELECT, WITH, DESCRIBE, SHOW, and EXPLAIN. Statements that modify data are rejected before they reach your database.
Aten's product query path is designed to read your data and answer questions about it. It does not issue create, update, delete, or schema-changing operations.
You choose what Aten can see
Access is selected and managed one table at a time.
Access is granted per table, not per database. When you connect a source you select exactly which tables Aten may query, and only those become visible to it. Anything you don't select stays out of reach.
You can toggle any table off at any time — it disappears from Aten immediately — or disconnect a source entirely whenever you want.
Every answer shows its query
The SQL behind each number stays available for inspection.
Aten does not ask you to trust a number. Every figure it returns is accompanied by the SQL that produced it, so any answer can be inspected, re-run, and checked against your source of truth.
For a reviewer, that means the tool is auditable by design: there is no hidden query path, and nothing is computed somewhere you cannot see.
Queries run in an isolated session
Each question runs inside a short-lived in-memory session.
Each question is answered in its own short-lived, in-memory session that is created for that query and discarded immediately afterwards. Nothing persists between questions, and one customer's session cannot reach another's data.
Within that session, access to the host filesystem is disabled and the configuration is locked, so it cannot be re-enabled from inside a query.
How credentials are stored
Secrets are encrypted and Google access remains revocable.
Database credentials are stored in an encrypted secrets vault, never in plain text, and are decrypted per connection. Google connections use OAuth — Aten holds a token you can revoke from your Google account at any time, and we never see your password. Connections and stored data are encrypted in transit and at rest.
A note on the BigQuery permission scope. When you connect BigQuery, Google's consent screen asks for the full BigQuery scope rather than the read-only one. This is a constraint of Google's API, not a design choice: running any query — including a dry run — requires the bigquery.jobs.create permission, which the read-only scope does not grant. Under the read-only scope, Aten could read your schema but every query would fail.
Aten's own connection to BigQuery is configured read-only regardless, and you can revoke access from your Google account at any time. We'd rather explain this than have you discover it on the consent screen.
Your data never trains a model
Customer data is used to answer customer questions.
Your data is used to answer your questions and nothing else. It is not used to train models — ours or anyone else's — and it is not shared with other customers.
Questions before you approve a connection?
Ask about a specific control, compliance requirement, or connector. A human will answer.
Email [email protected]Last reviewed: July 29, 2026