Security considerations

We have put a lot of thought into making sure your data stays safe and that each of your embed users' data is siloed between each other. We'll first talk about how your dat is secured by us and then we'll go into the steps you can take to make sure you follow best practices.

Using as little data as possible

Unlike a lot of other analytics tools, we try to use as little data as possible (that's contradictory you say?). This is done by not building a data warehouse on our end and instead we pull data from your data sources when needed to refresh data on your dashboards.

Even when using our LLM, we do not send your data across and instead send metadata instead for maximum privacy while maintaining LLM output quality.

Security in transit

All data is secure in transit using TLS and HTTPS security. This is used whether you use the staging environment, the production environment or even when self hosted.

Security at rest

We use a database that encrypts data at rest meaning even data like your user name and profile picture are encrypted when stored. You can read more about security of our database here (opens in a new tab).

Column level encryption

We have gone one step further for special columns that store details like your database credentials or API details by using the pgsodium extension for postgresql (our database of choice). This ensures that even we cannot read these credentials if we wanted to. You can read about pgsodium here (opens in a new tab).

How can you protect your data better

We have made it easy to make sure your data stays safe and siloed between embed users by providing you strong controls with our datasource and sessions systems.

1. Use our native clients when possible

We have built our native clients when possible which makes sure that the APIs they use our stable and secure

2. Use our js, ruby and python SDKs on a secure environment

The reason we have set up a system to create embed users and to upsert a dashboard session is to make sure that they can only be run in a privileged environment like a server. This makes sure your env key is not leaked like when using it on a browser. This also ensures that an embed user cannot arbitrarily request access for dashboards that you have not explicitly granted permission to access.

This may seem like an extra step to manage instead of handling it all on the client but this will definitely help when going on to the next step.

3. Setup datasources to only fetch data for the correct embed user

Our data source system is quite flexible so it may seem like an easy way to just fetch all the data and then use the AI system to visualise data for a particular user. But this can be highjacked by an ill-intentioned user to fetch all the data from your database if needed. We go into more details about this in this page.

4. Only provide us as much data as is absolutely necessary

When setting up datasources, especially when it comes to a database data source like mysql, mongodb or postgresql, make sure you provision an additional user for the database with only read access to the particular tables and views you need for visualisation. This helps prevent against unauthorized access by any party and is generally a good database management practise in general.