Your data stays where it is.
iDash connects read-only, encrypts credentials field by field, and resolves every access decision from the session that made the request.
This page describes the controls in place in the product today. iDash holds no third party security certification, and this page claims none.
Connecting a source
A connection is proven before it is stored. Four steps run in order, and a failure at any of them leaves nothing behind.
- A single probe query runs first, in a read-only session under a statement timeout.
- Introspection reads tables, columns, primary keys and foreign keys. It reads no rows of your data.
- Any failure rolls the whole attempt back, so a half-connected source is never persisted.
- iDash refuses to connect to the application database that runs iDash itself.
- Nothing requires production. A read replica gives the same schema, the same keys and the same answers.
Every query is a read
Read-only is enforced by the database, not requested politely by the client. A guard sits in front of that, and a timeout sits around it.
- A guard rejects anything that is not a single SELECT or WITH statement before it is sent.
- PostgreSQL and MySQL sessions are pinned read-only by the server itself.
- ClickHouse connects with read-only mode set. SQL Server and Trino run under a select-only login.
- Every statement runs under a timeout and is cancelled rather than left to run long.
- There is no write path to disable, because no write path is built.
Credentials and sessions
Connection details are encrypted before they are written down and decrypted only to open a connection. They exist in the API process and nowhere else.
- Host, port, database, user and password are encrypted field by field with AES-256-GCM at rest.
- Decryption happens inside the API, only at the moment a connection is opened.
- Credentials never appear in a prompt, a tool result, a chart spec or an export.
- The user session travels in an httpOnly cookie that browser scripts cannot read.
Tenancy and roles
Every workspace-scoped request resolves the caller's membership before it does anything else. Roles are ranked, and the ranking is checked at the boundary rather than in the interface.
- Membership is resolved first on every workspace and project route.
- A non-member receives a 404, so the existence of a workspace is never disclosed.
- Roles rank owner, admin, member, viewer, and a workspace can never be left without an owner.
- Data sources belong to the project they were connected in, and are reachable only from it.
- Access attributes are resolved from the authenticated session, never from model output.
The code sandbox
When a question needs Python, model-written code runs in a container that is treated as hostile. It receives a result file and no way back to your database.
- Each execution runs in a fresh container with a read-only root filesystem.
- The only host path mounted is that chat session's own workspace, which is destroyed with the session.
- Networking is off unless it is explicitly enabled.
- CPU, memory, wall clock and output size are all capped.
- Query results enter as a file. Connection details never enter at all.
What we claim, and what we do not
Security pages are easy to inflate. This one describes architecture and controls that exist, and says plainly where the line is.
- iDash holds no SOC 2, ISO 27001 or HIPAA attestation today, and displays no badge suggesting otherwise.
- Everything described above is in the product now, not planned.
- Work that is designed but not built is listed on the roadmap, not here.
- Bring your own security review. The connection is read-only, so the blast radius is a credential you can revoke.
Report a security issue
Send it to the team directly. Include what you found and how to reproduce it, and you will get a human reply.
idash@thegatewaycorp.comConnect a replica and inspect it.
A read-only credential is all iDash asks for, and all it can use.