Security, deployment & licensing | ATX AnalyticsTable Handbook

Security, deployment & licensingEnterprise-ready by construction: keychain-backed secrets, role-based access, a tamper-evident audit trail, and nothing automatic until a project is trusted. ATX AnalyticsTable protects four things by four different mechanisms: the credentials it stores to reach your databases, the data it fetches with them, the automation a project can carry, and the record of who did what. On the desktop the backend runs on the operator's own machine and listens on the loopback interface only; in server mode every person signs in through Microsoft Entra ID, any OpenID Connect provider or any SAML 2.0 identity provider, receives a Viewer, Analyst or Admin role, and every request is checked against that role by the server itself. A project that arrives from another computer or person runs nothing automatically until someone trusts it, every security-relevant action lands in an append-only, hash-chained audit trail that an auditor can verify independently, and administrators switch whole features off through Group Policy or Intune with the backend — not just the interface — enforcing it. What is deliberately not claimed: this is not a defence against someone using the machine while its owner is signed in, and it is not a substitute for full-disk encryption.

What it does

Credential vault: AES-256-GCM per record, master key in the OS keychain, a scrypt-derived passphrase or an enterprise secret manager — database, Git, proxy and cloud-storage keys alike, and no endpoint ever returns a stored storage key
Project trust: a project from another computer or person opens paused — no startup schedules, refreshes, imports, exports or e-mails — until the user chooses “Trust this project”; administrators pre-trust approved folders
Role-based access in server mode: Viewer, Analyst and Admin from Entra ID app roles or from Entra, OIDC, SAML or SCIM groups, immediate revocation, scoped service tokens stored as hashes, per-user project folders, read-only SQL for viewers — enforced on every request
Append-only, hash-chained audit trail of credential use, sign-ins, queries, exports, e-mails, backups, licence, policy and AI actions — verifiable in the app, by API or with a stand-alone script, kept 400 days by default and forwardable to a SIEM over RFC 5424 syslog with TLS
Group Policy and Intune (ADMX/ADML): turn off AI, e-mail, cloud storage, Git, the update check or individual connectors, and restrict exports to approved folders — refused by the backend, recorded in the audit trail
Transport security from PREFER through VERIFY-FULL, plus an estate-wide TLS floor that refuses weaker connections; the OS certificate store is trusted, so TLS-inspecting proxies work without switching verification off
Optional AES-256-GCM encryption of the project database, covering the write-ahead log and temporary spill files, with its own separate key
Hardened boundary: loopback bind, a 32-byte API token checked before any request body is read, Host and origin checks, a per-response CSP nonce with eval forbidden, and per-user launch links with HttpOnly sessions on terminal servers
Hardened desktop shell: Electron fuses set before signing, asar integrity validation on Windows, permissions and device access denied by default, navigation locked to the app's own origin

How it works

Trust is remembered per user, per machine and per project path. Until it is given, anything the user does by hand still works and nothing is lost — the pause covers automatic work only, so a project received by e-mail cannot run its schedules, exports or mailings just by being opened.
Each audit record carries the SHA-256 hash of the one before it, across daily files, with a head file that catches records cut from the end. A changed byte, a removed or reordered record or a truncated file is reported with the first bad sequence number, and the audit trail cannot be switched off from inside the application.
Audit records name the actor — a signed-in person, the desktop user, a service token or the system — and hold metadata only: a hash of the SQL, row counts, recipients and outcomes, never query results, credential values, e-mail bodies or AI prompts.
A role map that does not parse fails closed to Viewer; an unrecognised TLS floor is read as VERIFY-FULL; a policy file that does not parse can never switch the trust prompt off. Misconfiguration lands on the safe side.
In server mode the backend refuses to start with its vault key beside the ciphertext; the key is mounted from a Kubernetes Secret or an external secret manager. User-typed URLs the server fetches pass an SSRF guard that refuses private, loopback and cloud-metadata addresses and re-checks every redirect.
AI features send a model only what the administrator's data policy for that model allows — on-prem full data, private-cloud schema and samples, public-cloud schema and aggregates only — and Ask Greg's queries are parsed by the database itself and confined to the project's own tables, so no spelling of a file path can make it read the disk.
A licence is a signed file verified against a public key compiled into the build, so an air-gapped installation validates its own licence with no network at all. A key added locally must carry a delegation signed by a built-in key, and setting the clock back does not extend a trial.
An administrator's diagnostics bundle is redacted on the way in and scanned again before export — a credential-shaped hit fails the export rather than shipping it. Crash dumps stay on the machine.

Practices that keep it reliable

List the folders your approved reports live on as trusted project roots, and leave the trust prompt on everywhere else
Forward the audit trail to your SIEM over TLS and alert on dropped records; keep an earlier verification hash to prove continuity across retention
Set the database TLS floor to VERIFY-FULL and put the database CA in the OS store — the setting most security reviews ask for first
In server mode, require sign-in through Entra ID, OIDC or SAML, provision users with SCIM, map groups to the three roles, set per-user project roots, and give viewers a database login that is read-only in the database itself
For regulated environments, point the AI base URL at an internal gateway that holds the key and authenticates the user by SSO, Kerberos or mTLS — or turn AI off by policy
Turn on database encryption deliberately, and understand the trade: a lost keychain entry means nobody can decrypt it, including you

In a regulated environment

Releases pass type checks, test suites and legal and version gates before they publish; Windows installers are signed and timestamped, container images ship with a CycloneDX SBOM, provenance and a cosign signature, and CI actions are pinned by commit hash.
Vulnerabilities are reported privately to security@atxinstitute.com under coordinated disclosure: acknowledgement within 3 business days, fixes for critical and high-severity issues within 30 days.
No telemetry and no cloud account. The only automatic outbound calls are the optional licence status check and an update check that downloads the public release list — neither carries anything from a project, and both can be turned off by policy.
One gateway in front of the model gives one place to rotate the credential, one set of rate limits, one audit trail that names the person rather than the workstation, and the ability to cut off access without touching a single machine.

Screens

Sharing — a packaged project with per-recipient rights and a tamper-evident integrity hash.
AI data policy — the egress class of a model decides how much of the data it may ever see.

Previous — chapter 11: PII masking & privacy
Next — chapter 13: Ask Greg — the AI designer and analyst
All 27 handbook chapters
ATX AnalyticsTable overview — the illustrated tour
Download ATX AnalyticsTable

Related guides

Air-gapped BI

ATX Institute on LinkedIn

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