Security overview and data protection | ATX AnalyticsTable Docs

Security overview and data protectionWhat is protected and what is not; the credential vault; data at rest and in transit. This section describes exactly how ATX AnalyticsTable protects the CREDENTIALS it stores so it can reach your databases, the DATA it fetches with them, and the AUTOMATION a project can carry — and how an organisation proves afterwards who did what. These are protected by different mechanisms, and it is worth knowing which is which. The application runs in one of two shapes. As a desktop application the backend runs on your own machine and listens on the loopback interface only, so nothing on your network can reach it, and every request it answers has to carry a secret generated on first run and kept in your user profile.

What is protected, and what is not

This section describes exactly how ATX AnalyticsTable protects the CREDENTIALS it stores so it can reach your databases, the DATA it fetches with them, and the AUTOMATION a project can carry — and how an organisation proves afterwards who did what. These are protected by different mechanisms, and it is worth knowing which is which. The application runs in one of two shapes. As a desktop application the backend runs on your own machine and listens on the loopback interface only, so nothing on your network can reach it, and every request it answers has to carry a secret generated on first run and kept in your user profile.
As a server — Docker, Kubernetes, or one backend per user on a terminal server — every person signs in, gets a role (Viewer, Analyst or Admin), and every request is checked against that role by the server itself. In both shapes: credentials are always encrypted at rest, in a vault whose key is held apart from the data it unlocks; data fetched into the project database is encrypted at rest when you switch that on; traffic to your databases is encrypted whenever the server offers it, and an administrator can make verified encryption compulsory; a project that arrives from another computer or person runs nothing automatically until you trust it; and an append-only, hash-chained audit trail records security-relevant actions in a form an auditor can verify independently.
An administrator can switch whole features off — AI, e-mail, cloud storage, Git, individual connectors, the update check — through Group Policy, Intune or a policy file, and the backend enforces those switches rather than merely hiding buttons. What is deliberately NOT claimed: this does not defend against someone using your machine while you are logged in, and it is not a substitute for full-disk encryption, which is the operating system's job (BitLocker on Windows, FileVault on macOS, LUKS on Linux) and remains worth turning on.
None of your data is sent anywhere unless you ask for it: there is no telemetry and no cloud account. Only two automatic outbound calls exist, and neither carries anything from your projects. When a licence server is configured, the app periodically asks it for the status of your licence id, and activating a licence sends that id with a machine identifier, the computer name, the operating system and the app version. The update check downloads the public list of releases and compares version numbers on your machine; an administrator can turn it off.
AI features send the model you chose only what the administrator's data policy for that model allows. Crash dumps stay on your machine and are never uploaded.

Credentials at rest — the vault

Every database password, API key, service-account JSON, Oracle wallet password, Git token, proxy password and cloud-storage key you save is written to an encrypted vault, never to the connection file. Connection files hold only what is safe to share: name, kind, host, database, and a REFERENCE to the secret. That now includes object storage: an Azure Blob account key, SAS token or connection string, a Google Cloud Storage service-account JSON and an S3 access key are kept only in the vault — never in the browser, in a project file, in your settings or in a settings export — and no endpoint returns a stored storage key to anyone, administrators included.
The vault encrypts each record separately with AES-256-GCM — a 256-bit key, a fresh random 96-bit nonce per record, and an authentication tag that makes silent tampering detectable rather than merely unlikely. The vault's own 256-bit master key is held by the operating system keychain: Windows Credential Manager, the macOS Keychain, or libsecret on Linux. That is the important part. Encryption is only as good as where the key lives, and a key sitting in a file beside the data it unlocks protects against a stolen disk and nothing else.
Keeping it in the keychain means the vault file alone is useless — copied to another machine, restored from a backup, or read by another program running as you, it will not open. A server or container has no keychain, so in server mode the backend REFUSES TO START with its vault key stored beside the ciphertext. The key must be mounted from outside — a read-only key file (ANALYTICS_VAULT_KEY_FILE, which the Helm chart creates as a Kubernetes Secret by default) or an external secret manager — and an existing vault is re-encrypted under the mounted key, every secret read back and compared, all or nothing.
Accepting the old behaviour takes an explicit opt-out that is logged on every start. Older desktop installations used a local RSA-3072 key pair with OAEP-SHA-256 to wrap a per-record key; those vaults are migrated automatically on first start, every record is read back and compared before anything is replaced, and the previous files are moved into a dated superseded folder rather than deleted. The migration is all-or-nothing and first proves the keychain works with a real write and read: where it cannot be used — a Linux machine with no secret service running, say — an older vault stays on its previous format until the keychain becomes available.
A passphrase mode is also available, deriving the master key with scrypt at N=65536, r=8, p=1 over a random 16-byte salt, so the key itself is never written to disk. For deployments that already run a secret manager, the vault can point at AWS Secrets Manager, Azure Key Vault, Google Secret Manager or HashiCorp Vault instead. Because a keychain entry does not travel with a roaming or rebuilt profile, Settings → Backup & restore exports settings, connections and saved credentials as one file encrypted under a passphrase you type (scrypt, then AES-256-GCM); the credentials are re-encrypted under that passphrase, never under the machine key, and the passphrase is stored nowhere.
Treat that file like a password list — it is one, behind the passphrase. In server mode only an administrator can export or restore one.

Data at rest — the project database

Everything you import — rows pulled from PostgreSQL, Oracle, SQL Server, BigQuery, cloud object storage or a file — is materialised into the project's DuckDB database beside the project file. That database can be encrypted, and when it is, DuckDB encrypts it with AES-256-GCM: authenticated encryption, so a corrupted or tampered block is detected rather than silently returned. The key you supply is not used as the key directly — DuckDB passes it through a key derivation function and wipes the input from memory afterwards.
The write-ahead log is encrypted with it too, and so are the temporary spill files DuckDB writes when a query is larger than memory, which is where an otherwise careful setup usually leaks. Only the file header stays readable, and it holds nothing sensitive: the format magic bytes, flags, a database identifier, and an encrypted canary used to check that the key you offered is the right one. The encryption key is a separate 256-bit key of its own, kept in the same vault as your credentials and therefore behind the same keychain — deliberately not the same key that protects the credentials, so that rotating one never forces re-encrypting the other.
This is OFF by default and switched on with the environment variable ANALYTICS_DUCKDB_ENCRYPTION=1 — or, for a whole estate, the administrator policy Require encryption of project databases (RequireDatabaseEncryption) — because it changes how every database is opened and that is a decision to take deliberately rather than to inherit from an upgrade. New databases created while it is on are encrypted from the start; an existing database is converted on request, which rewrites it in full, verifies that every table and every row count survived, and keeps the original alongside as a dated plaintext backup you delete when you are satisfied.
Understand the trade before switching it on: if the keychain entry holding the database key is lost — a wiped Credential Manager, a profile restored onto a different machine — the database cannot be decrypted by anyone, including you.

Data on the fly — connections to your databases

A connection that is not encrypted sends your password and every row you read across the network in the clear, and on a shared or corporate network that is a realistic exposure rather than a theoretical one. PostgreSQL connections default to PREFER: TLS is used whenever the server offers it, and plain text only where the server genuinely cannot negotiate it. The full set of modes, in ascending order of what they actually prove — DISABLE, no encryption at all; ALLOW, plain text unless the server insists; PREFER, encrypted where available (the default); REQUIRE, always encrypted, but the server's certificate is not checked, so this stops passive capture and not impersonation; VERIFY-CA, the certificate must chain to a certificate authority you trust; VERIFY-FULL, the chain AND the host name are checked, which is the only mode that actually authenticates the server you are talking to.
Root CA, client certificate and client key paths can be supplied for the verifying modes and for mutual TLS. SQL Server connections are encrypted by default and validate the server certificate by default; trusting an unverified certificate is an explicit opt-in for development. Oracle supports password, wallet, external and token authentication, with a wallet directory giving mutual TLS against Autonomous Database. BigQuery, Google Cloud Storage, Azure Blob Storage and S3-compatible object storage are reached over HTTPS, with S3 requests signed using AWS Signature Version 4; a custom endpoint for a self-hosted store is the one place a plain-HTTP address can be entered, and only because MinIO on a loopback address is a normal thing to develop against.
An administrator can set a TLS FLOOR for the whole installation — [database] min_tls in config.ini, or ANALYTICS_DB_MIN_TLS — at prefer, require, verify-ca or verify-full. A connection that chose nothing is raised to the floor; one that explicitly asked for less is REFUSED with an error naming the policy, rather than quietly connecting; and a value the app does not recognise is treated as verify-full, so a typo fails closed. For PostgreSQL, SQL Server and Oracle that turns "encrypted where possible" into "verified, or not at all".
Behind a TLS-inspecting corporate proxy, the backend trusts the operating system's certificate store as well as its own built-in list, so an inspection root your IT department already deploys to browsers is accepted for AI, licence and update checks, cloud storage and database TLS without anyone turning verification off. An extra PEM bundle can be added, never substituted. The desktop app follows the Windows proxy settings, including PAC files and WPAD; a proxy password is kept in the vault.
Integrated Windows proxy authentication (NTLM or Kerberos) is not supported directly — the usual answer is a local authenticating proxy.

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.