Security
Your code and your data are the most sensitive things you have. Here is how we protect them, written so both management and developers can use it.
Adea gets a database user that can only read, and read access to the code. Every query is checked before it runs. Only plain read queries pass, with a time limit, a row limit and a read-only transaction. Adea can neither change nor delete anything.
Every company has its own connection and its own area in the database, and the database itself refuses to show one company's data to another. Adea's AI cannot run code or commands. It can only use the tools it is given for your company.
Adea and your data run on servers at Hetzner in the EU. The only parties that see data outside the EU are the few suppliers on the sub-processor list, and only what they need. The data processing agreement is included from the start.
All traffic is encrypted with TLS. Credentials for your database and tokens are stored encrypted with us, never in plain text.
Developers can close tables and columns to certain roles, for example salaries or national ID numbers. The rule applies before a query runs, so an answer cannot get around it. Rules in plain language are a help, not a guarantee. Use table access when you need to be sure.
Files with keys and passwords (such as .env, certificates and key files) are never read, and values that look like secrets are removed before the code is used.
Every answer shows its sources and assumptions. Your developers can open them and approve the rules the answers are built on.
Questions, connections, rules and permission changes are logged, so administrators can see who did what and when.
Your data is not used to train AI. That applies to us and to the AI provider, which processes data through an API where training is excluded.
Raw result rows from your database are deleted after 30 days. The answer keeps its SQL and the summarised figures, so it can still be shown and re-run. Questions and answers are kept as long as you have an agreement, and you can delete them in Adea. When the agreement ends, we delete your data and copies of the code no later than 30 days after. Backups are deleted with the normal rotation and no later than 35 days after that deletion.
Create a user that can only read. Preferably use a read replica of the database. You can send these examples straight to your developer.
PostgreSQL
CREATE ROLE adea_readonly LOGIN PASSWORD '…'; GRANT CONNECT ON DATABASE your_db TO adea_readonly; GRANT USAGE ON SCHEMA public TO adea_readonly; GRANT SELECT ON ALL TABLES IN SCHEMA public TO adea_readonly; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO adea_readonly;
MySQL
CREATE USER 'adea_readonly'@'%' IDENTIFIED BY '…'; GRANT SELECT ON your_db.* TO 'adea_readonly'@'%';
The user should only have SELECT. Don't grant it rights on sequences (USAGE or UPDATE) or on functions that write, and don't let it own anything. Adea's connection test checks tables, but not sequences and functions, so your developer makes sure of that.
Found a vulnerability, or have questions from your security team? Write to sikkerhed@adea.io.