How does iDBQuery handle row-level security and permissions?

iDBQuery controls access at several layers rather than exposing everything to everyone: - Authentication decides who can log in. - Role-based permissions decide which projects and data sources each user or team can see, so people only reach the data they are granted. - Connection credentials govern what iDBQuery itself can read; it queries under the database accounts you configure, so it inherits and respects the read permissions those accounts already enforce.

That means if a connection account cannot see a schema or table, neither can the questions asked through it. For stronger isolation, you can give different teams their own projects and connections scoped to the data they are allowed to touch.

The bigger control, though, is deployment. Because iDBQuery can run in your own VPC or fully air-gapped, and queries your data in place rather than copying it out, sensitive data never has to leave your environment in the first place; the strongest form of access control is data that never moves. Data is encrypted in transit and at rest, and your data is never used to train an AI model. For teams that need per-row restrictions enforced upstream, iDBQuery honours the database's own row-level policies because it runs real SQL through your controlled credentials. The guiding principle is architecture first: the safest boundary is the one your own infrastructure already enforces.