1. Read-only sources
SQL sources are opened read-only. A write is refused by the engine, not only by the interface; the safeguard is proven with a passing case, a violating case and a deliberate sabotage.
2. Federated identity, no local accounts
Sign-in goes through Idenva (SSO). A token from another issuer, or an expired one, is refused, and re-enabling a local password is detected. Dashvia keeps no user database of its own.
3. Row-level rights
Idenva groups decide which rows are visible. The filter is parameterised, never built by interpolating values, and it also applies to cross-filters, drill-down, exports and scheduled reports.
4. An AI that shows its query
Text-to-SQL answers with a readable SQL query. Any read outside the schema and any write is refused before execution. Without the Kopilvia hub, Dashvia switches to an explicit degraded mode: local corpus, and a refusal to answer outside it rather than a guess.
5. Audit log
Who viewed, exported or changed which report is recorded in an append-only log: the database refuses any update or deletion of a row already written.
6. Hardened, pinned base
Dashvia builds on Apache Superset (Apache-2.0), pinned at version 6.1.0. A default secret key or an admin/admin account is refused at start-up, and published security advisories are checked against the pinned version.
7. Self-hostable
The base installs on your own infrastructure. Your schemas and results do not have to leave it.