Read-only by construction.
Playfair answers questions about your data without ever being able to change it. Here is exactly how, and what we do with everything else you trust us with.
Four locks on every query.
Any one of them is enough to keep your data unchanged. Playfair uses all four, on every question, every dashboard refresh and every API call.
- 01
A role that cannot write
When you connect a database, Playfair tries a harmless write inside a transaction that is always rolled back. If the write is accepted, the source is refused until you give it a read-only role.
- 02
One SELECT, nothing else
Every statement is parsed before it leaves our servers. Inserts, updates, deletes, DDL, COPY, SELECT INTO, multiple statements and functions with side effects are rejected, even when an analyst typed them.
- 03
A read-only transaction
Queries run inside BEGIN READ ONLY and end with ROLLBACK, so even a role with more rights than it should have changes nothing.
- 04
Bounded, and written down
A 30-second statement timeout, 10,000-row pages, a cost check with EXPLAIN (heavy scans ask first) and per-source rate limits. Every statement lands in the query log with who ran it.
- validate UPDATE orders SET status = 'refunded' WHERE id = 5203
- rejected before it reached the database: only a single SELECT is allowed
- connect playfair_reader@sample_store — read-only role, verified
- BEGIN READ ONLY
- SET LOCAL statement_timeout = '30s'
- EXPLAIN (FORMAT JSON) SELECT … — cost 1,842 · light
- SELECT date_trunc('month', orders.order_date)::date AS month, … LIMIT 10001
- ROLLBACK
- 9 rows in 31 ms · nothing written · saved to the query log
The query log of one answer on the sample store. The same sequence runs for Postgres; MySQL uses START TRANSACTION READ ONLY and MAX_EXECUTION_TIME.
Everything else you trust us with.
Credentials
Database passwords, tokens and SSH keys are encrypted at rest with AES-256-GCM, never logged and never returned by the API. Connections come from fixed egress IPs you can allow-list.
Results and caches
Cached results are encrypted at rest and expire on their own (five minutes by default). Sample values from columns that hold personal data are redacted.
Who sees what
Five roles from Owner to Viewer, enforced on the server. Pro adds per-source access, table allow-lists and masking of personal data for Explorers, Viewers and public links.
Sharing
Public dashboards are read-only and never indexed. Pro links can require a password or expire; embeds are restricted to the domains you list.
AI and your data
We send a model the minimum for each step: your question, the relevant schema and metric definitions, and aggregated results. Queries always run from our servers. Nothing is used to train models.
Privacy and GDPR
Hosted in the European Union (Frankfurt, Germany). A DPA, a public list of subprocessors, data export and account deletion, and an audit log of source changes, permissions, exports and share links.
What we do not do yet.
Security pages that only list strengths are hard to trust. These are the limits of version one.
- No row-level security. Access is controlled per source, table and column. To limit rows, connect Playfair to a database view that already filters them.
- No third-party certification yet. We follow the practices above and will share our security review on request; we do not claim a SOC 2 or ISO 27001 report we do not have.
Found something? Tell us.
Write to security@asrar.example with the steps to reproduce. We answer every report, fix confirmed issues first and credit you if you would like.