Security
Security you can verify, control by control.
DataSquares is a hosted analytics service. This page sets out the security and governance controls in the product today, grouped the way a security review reads them, and links each control to the documentation that explains how it works.
Identity and access
Sign-in can run through your identity provider, and each person reaches only what their role and grants allow.
- Single sign-on
- Connect one identity provider per company over OpenID Connect or SAML 2.0. Each SAML assertion must be signed with your certificate and issued for that sign-in, and it is accepted only once.How it works: Single sign-on
- SCIM provisioning
- Your identity provider creates, updates, suspends and removes members and pushes groups over SCIM 2.0. Suspending someone ends their sessions at once and stops their API keys.How it works: SCIM provisioning
- Two-factor authentication
- Authenticator codes come with ten single-use recovery codes, stored only as SHA-256 hashes. One switch requires two-factor for every member, and only an admin who uses it can turn it on.How it works: Two-factor authentication
- Passkeys and sign-in methods
- Passkeys count as two factors. Admins choose which faster sign-in methods the organization may use, and members managed by your identity provider always sign in through it.How it works: Passkeys and sign-in methods
- Sessions
- Everyone can see where their account is signed in and end any session. Changing a password ends every other session.How it works: Sessions
- Roles and custom roles
- Admin, Editor and Viewer are built in and locked. Custom roles set view, create, update and delete rights for each area, from dashboards and models to sources and pipelines.How it works: Roles and custom roles
- Delegated administration
- Each Administration page is its own permission, so you can grant the audit log, usage or billing pages without the rest of Administration.How it works: Delegated administration
- API keys bound to their owner
- A key carries read, write or admin scope, or named scopes, and can never do more than its owner’s role allows at that moment. Keys always expire and are shown only once.How it works: API keys bound to their owner
Data access
Rules on the data model decide which rows and fields each person sees, and they go wherever the data goes.
- Row-level security
- Policies on a model’s tables limit the rows each person sees. They run beneath every chart, export, drill-down and preview, fail closed, and dashboard filters and measures cannot bypass them.How it works: Row-level security
- Field masking
- Give a field a sensitivity label such as PII through the model API, and its values show as *** to everyone but workspace admins. Totals, filters and sorts on it are refused, so a hidden value can’t be read by inference.How it works: Field masking
- Raw SQL checks
- On a source with labeled fields, SQL that touches a labeled column, uses SELECT * or can’t be proven safe is refused for everyone but admins. On public shares, not even an admin can bypass it.How it works: Raw SQL checks
- Per-dashboard access
- Open one dashboard to a named member as a viewer or an editor. A grant adds to their role and never takes anything away.How it works: Per-dashboard access
- Share links
- Public links are read-only, can ask for a password and stop working on the date you set. Link visitors can’t drill through to other dashboards.How it works: Share links
- Embeds
- Your server mints each embed token and can bind the viewer’s row scope into it, out of the viewer’s reach. Allowed domains decide where an embed can render; the token stays the credential.How it works: Embeds
The same rules on every surface
Access is applied where the query runs, not in each chart, so it holds wherever the data appears.
- Dashboards and drill-downs
- Row-level security and masking are applied in the query engine, beneath every chart, drill-down and data preview.
- How it works: Dashboards and drill-downs
- Exports and scheduled email
- Exports are filtered the same way, and metric tiles are evaluated through the governed pipeline. A personal subscription is rendered with the subscriber’s own permissions and stops if they lose access.
- How it works: Exports and scheduled email
- Share links and embeds
- Masked fields stay masked in shares and embeds. When an embed token carries a row context, every query the embed runs is scoped by it.
- How it works: Share links and embeds
- Stories
- Live charts and numbers run with each reader’s access. A value the reader may not see shows as a dash, and a section can hide from readers who can’t see all of its data.
- How it works: Stories
- AI answers and the MCP server
- AI chat, card insights and MCP tools run as the person asking, under the same row-level security and masking.
- How it works: AI answers and the MCP server
- Alerts
- Alerts are evaluated on the server under your data permissions, so nobody is told about rows they cannot see.
- How it works: Alerts
- Android appEarly access
- Dashboards open with the same data rules as on the web: each person sees only the rows and columns their account allows.
- How it works: Android app
AI inside the same controls
The AI reads only what the person asking may read, shows the evidence behind each answer, and changes nothing until someone approves the exact change.
- The asker’s access, not more
- AI chat, card insights and the MCP server run as the person asking, so row-level security and masking apply to every answer. Answers use your governed metrics and glossary instead of improvising definitions.How it works: The asker’s access, not more
- Approval before any change
- Before the AI creates or changes a dashboard, report, alert, schedule, calculated field or pipeline, it shows exactly what will change and waits. Only that change runs, and DataSquares then re-opens the item to check it.How it works: Approval before any change
- Evidence with every answer
- An answer can show the SQL it ran, the sources and metrics it used, its filters and time range, whether the data was live or cached, and what it assumed. Exported conversations keep the evidence.How it works: Evidence with every answer
- Statistics without AI
- Explain this change, anomalies, key influencers and forecasts on a card are statistics computed on the server, whether or not AI is set up. AI is used only for the optional written summaries and for questions you send to AI chat.How it works: Statistics without AI
- Workspace AI settings
- Admins set the monthly AI token limit and how long conversations are kept, and can switch off any tool the assistant would otherwise use.How it works: Workspace AI settings
- One credit balance
- Every AI feature spends the same credits, with usage by feature and a ledger of every debit. At a zero balance the next AI request is refused and nothing else is affected.How it works: One credit balance
- Ask AI on shared links
- Off by default. When a publisher turns it on, it answers only from that share’s own cards and is rate-limited per share.How it works: Ask AI on shared links
- MCP server
- Lets the AI assistants your team already uses query DataSquares through read-only tools that run as the calling identity, within the API key’s scope.How it works: MCP server
Audit and monitoring
A record of who did what, built so that a reviewer can tell whether anything in it has been changed.
- Tamper-evident audit log
- Each entry is chained to the one before it with a SHA-256 hash that the database computes. Updates and truncation are refused, and only the retention sweep may delete.How it works: Tamper-evident audit log
- Verification you can run
- One API call walks the chain and reports whether it is intact and, if not, the exact entry where it stopped being intact. Each verification is itself recorded.How it works: Verification you can run
- Exports for reviewers and SIEMs
- Export a CSV with spreadsheet formulas neutralized, or pull a cursored NDJSON feed into your SIEM. Every export is audited too.How it works: Exports for reviewers and SIEMs
- Every query recorded
- Every query is recorded, never sampled, from charts, SQL, share links, exports, alerts and the AI: who ran it, the SQL, the rows returned and any error.How it works: Every query recorded
- Retention
- Audit entries are kept for two years and query records for one year by default. Removing old entries leaves an anchor, so a truncation is still detectable.How it works: Retention
- Sign-in and policy events
- Every sign-in records its method and how the second factor was met. New passkeys, SCIM changes and security policy changes have their own events.How it works: Sign-in and policy events
- Reading the log is governed
- Viewing the audit log needs its own permission: admins hold it, and anyone else must be granted it.How it works: Reading the log is governed
- Signed webhooks
- Send alerts, failed syncs, publishing and access changes to your own endpoint, signed with HMAC-SHA256 when you set a secret. Each webhook keeps a log of its deliveries.How it works: Signed webhooks
Tamper-evident, not tamper-proof: someone with full rights to the database could rewrite the chain consistently, which is why the documentation recommends keeping the exported feed somewhere DataSquares can’t reach.
Data protection
How DataSquares stores the credentials and secrets you give it, and what it does with your sources.
- Encrypted credentials
- Passwords, tokens and keys for your sources are encrypted with AES-256 before they are stored and never leave the server. Editing a source never shows them again.How it works: Encrypted credentials
- Read-only, encrypted connections
- DataSquares runs only read queries against your sources, over TLS by default. An SFTP source can pin the server’s host key.How it works: Read-only, encrypted connections
- Secrets shown once
- API keys and SCIM tokens are shown only once, and an API key keeps only its prefix on screen. The single sign-on client secret is write-only.How it works: Secrets shown once
- Notice of new sign-in methods
- Each new passkey, linked Google account and phone-approved sign-in is emailed to the account owner, so one they didn’t expect stands out.How it works: Notice of new sign-in methods
- Isolated warehouse storageEarly access
- Each workspace gets its own warehouse credential with access to only its own database, so a query for another workspace’s data is refused by the database engine.How it works: Isolated warehouse storage
- Definitions without data
- Exported dashboards, models and metrics contain no data, no credentials and no workspace IDs. Importing one never gives access to the original database.How it works: Definitions without data
- Outbound calls checked
- Webhook targets are checked when saved and again at delivery. Private, loopback and cloud-metadata addresses are refused, and redirects are never followed.How it works: Outbound calls checked
- Exports that don’t call home
- A report’s HTML export is self-contained and makes no outbound request, so opening it can’t reveal the reader’s address.How it works: Exports that don’t call home
- App lock on AndroidEarly access
- Your organization can require the app lock, and home-screen widgets show nothing about your data while it is on.How it works: App lock on Android
Quality and publication
Controls that decide which numbers people should rely on, and what is allowed to reach them.
- Critical checks hold publication
- If a critical data-quality check on the underlying data fails or errors, publishing the dashboard, report or model is held, and the previous version keeps serving.How it works: Critical checks hold publication
- Overrides need a reason
- An authorized admin can override a hold only with a written reason, which the audit log keeps with the author and the failing tests.How it works: Overrides need a reason
- Certification
- Admins certify dashboards, models, data sources and metrics. Certified assets carry a badge wherever they appear and rank first in search.How it works: Certification
- Governed metrics
- Define a KPI once, with its grain and an accountable owner. KPI cards, digests, alerts and AI answers that use it all evaluate the same definition.How it works: Governed metrics
- Versions and restore
- Publishing keeps a version of a model or dashboard that you can restore. Promoting a dashboard to a stage that holds another version shows a field-level diff first.How it works: Versions and restore
- Lineage and impact
- Trace any asset from its source to the dashboards and shares built on it, derived live from real references, before you change or remove it.How it works: Lineage and impact
- Reviews before a story is published
- Publishing a story waits until every reviewer approves. Only the owner can publish anyway, and that is recorded.How it works: Reviews before a story is published
- Careful recovery
- Deleted dashboards and reports wait in Recovery for a window admins set. A restore comes back unpublished, with public links, schedules and alerts off until an owner reviews it.How it works: Careful recovery
- Deletes that name what breaks
- Deleting a data source first lists the models and saved queries built on it, and waits for you to confirm.How it works: Deletes that name what breaks
Bring your security questions.
Our team can walk through these controls against your requirements, or start a free trial and see the product on your own data.
See alsoPrivacy policyTerms of service