Legal information

Security

The security of the data you give us access to is fundamental to the dashiox service. This page summarises the main measures and the rules for reporting vulnerabilities.

Encryption

  • All communication with the service takes place exclusively over HTTPS (TLS) with HSTS enabled; the same applies to the service's communication with platform APIs.
  • Platform access and refresh tokens (Google) are stored encrypted with AES-256-GCM; the key is kept separately from the database.
  • Passwords are stored only as a hash (Argon2id); session and invitation identifiers only as a hash (SHA-256).

Data isolation

  • The data of each workspace is logically separated; permissions are checked on every request both in the application and in the database (row-level security).
  • The portal, the administration and the interface for AI clients (MCP) run on separate hosts with separate sessions and cookies.
  • Analyses and findings are delivered only to you and to the AI client you connected and authorised yourself; you can remove its access at any time in the portal under Connected AI apps → Remove access (Připojené AI aplikace → Odebrat přístup in the Czech-language portal), by removing the connector in the AI client, or by asking us by e-mail.
  • An analysis result export file (XLSX, CSV) can be downloaded only by the person who started the export, within 24 hours; we re-check their access both when preparing and when downloading it. Values that a spreadsheet application could run as a formula are neutralised in the export and e-mail addresses are replaced with a placeholder; the export contains no access tokens. We accept a logo for report branding only as a validated PNG image.
  • In an organisation, each member sees only the data of its workspace; connections and tokens are personal and are not shared with other members. When a member is removed or leaves, their access ends immediately – in the portal and in AI apps, without waiting for tokens to expire. For members with access only to assigned clients, we check the assignment on every request.

Sign-in and permissions

  • Accounts are created by invitation only; sign-in requires a password and two-factor authentication (TOTP), or sign-in with a verified Google account with the same e-mail (sign-in security is then governed by the Google account; signing in with Google never creates an account without an invitation).
  • Organisation invitations are single-use, valid for 7 days and can be accepted only with an account using the e-mail address they were sent to; we store the link only as a hash, and resending invalidates the old link. Only the owner and admins of the organisation may invite, and only up to their own role.
  • Sign-in attempts are rate-limited, forms are protected against CSRF and pages by strict security headers (a Content Security Policy with no external sources, with a single exception: pages of the public website allow Google Tag Manager and Google Analytics, which are loaded only after you consent to analytics cookies; the portal after sign-in and the administration allow no external sources).
  • The service makes no changes in platform accounts during the beta; change proposals (coming soon) will be carried out only after your explicit approval.
  • The operator's administrative access is separate, protected by two-factor authentication and audited; we access user data only as described in the Privacy Policy.

Backups

We back up the database and configuration regularly. Backups are stored with restricted access and rotated regularly, and deleted data disappears from them no later than 30 days after deletion from the production system.

Operations

  • The servers run at the provider listed on the subprocessors page with restricted network access, automatic security updates and protection against repeated sign-in attempts.
  • Tokens, passwords and keys are automatically masked in logs; logs do not contain the content of platform data.

Reporting vulnerabilities

If you find a security issue, please write to (machine-readable details are in security.txt). We communicate in Czech and English.

  • Describe the issue and the steps to reproduce it; share sensitive data only to the extent necessary.
  • Test only with your own account, do not access, modify or delete other users' data, do not disrupt the service (no DoS attacks, spam or social engineering) and do not test the infrastructure of the platform providers.
  • Give us reasonable time to fix the issue before disclosing it; we will acknowledge your report and keep you informed about the fix.
  • We will not take legal action against researchers who act in good faith and follow these rules. We do not currently offer financial rewards (bug bounty).