Security & read-only DB users
A short list of the security decisions that matter when you run Edmund across a plant.
Administrator / complianceRead-only database users
When you connect a data source, Edmund writes the SQL it needs and runs it against your database without checking first that the statement is safe. So every data source must connect with a database user that can only read. That one choice means even a bad query can read your data, but never change or delete it.
Do not connect with an admin or read-write account. The per-engine commands for creating a SELECT-only user — PostgreSQL, Microsoft SQL Server, Oracle Database, InfluxDB and Snowflake — are on Data sources & SQL safety.
Two-Factor Authentication
Two-Factor Authentication (2FA) adds a second check at sign-in, so a leaked password alone is not enough to reach an account. When you turn it on, Edmund generates backup codes. Save them somewhere safe — they are how you get back in if you lose your authenticator.
For turning on 2FA and using backup codes to recover an account, see Password & 2FA recovery.
Shared devices
On a shared shop-floor tablet or terminal, sign out when you finish. If you leave an account signed in, the next person sees and works under your name, and their chats land in your history.
If you find a shared device already signed in as someone else, sign out before you start so your work is recorded under your own account.
Destructive actions
Deleting a project or a document is permanent. There is no undo and no recycle bin, so the content and anything indexed from it are gone for good. Check what you are about to remove before you confirm.
Deleting a project removes its documents, data-source connections and chat history along with it. If you only need to stop people using a workspace, move the people out instead of deleting the project.
