Security at Atlas

Every company in Atlas is a separate workspace. Separation is enforced inside the database itself, not only by the application, and every change made in a workspace is recorded in its audit log.

Sign-in supports single sign-on, passkeys and two-factor authentication. Each company decides which sign-in methods its people may use.

Atlas runs on Vercel. Its data is stored in a Neon Postgres database, and uploaded files (contracts, receipts, compliance documents) are kept in Vercel Blob storage with private access only. Files are never served from a public link. Each download goes through Atlas, which checks that you're allowed to see the file first.

All traffic to Atlas is served over HTTPS, and browsers are told to use HTTPS only (HTTP Strict Transport Security, two years, including subdomains).

Passwords are stored only as bcrypt hashes. Two-factor secrets are stored encrypted, and API keys are stored only as keyed hashes, so the full key is shown once at creation and never again.

Every table holding company data is protected by Postgres row-level security, applied even to the database's own owner role. A request can only read or change rows belonging to the company it's working in. A bug in an individual screen can't expose another company's data.

People can belong to more than one company, and each membership is kept fully apart. Every page is also served with a strict, nonce-based Content Security Policy, plus headers that block framing and content-type sniffing.

Companies can sign in through their identity provider with SAML or OIDC single sign-on, and keep membership in step with their directory automatically through SCIM. People can also sign in with passkeys, Google, Microsoft Entra ID, email and password, or a text-message code, and each company chooses which of these methods it allows.

Anyone can turn on authenticator-app two-factor authentication, with one-time recovery codes. Sessions end after 12 hours without activity and after 7 days at most. Deleting data, changing how a company signs in (including single sign-on) and exporting all data ask you to sign in again if you haven't in the last 10 minutes. Repeated failed sign-ins lock further attempts for 15 minutes, both per account and per network address. Sign-up, password resets, invitations, sign-in codes, data exports and the API are all rate-limited, so they can't be used to flood an inbox or hammer the service.

Within a company, access follows each person's role: company manager, department manager, finance, support agent, project manager or member. Every server action and API endpoint checks both the company and the person's role before it reads or changes anything, and an automated test fails the build if a new action skips that check.

API keys act with the access the person who created them has today. Their role is re-checked on every request, so a change of role applies to their keys immediately, and a key stops working when that person is deactivated or leaves the company. Outgoing webhooks are signed so receivers can verify they came from Atlas, are sent over HTTPS only, and can't be pointed at private, internal or cloud-metadata network addresses.

Changes to a workspace's records, logged hours, people, access and settings are recorded in its audit log: what changed, who changed it, and when. That includes changes made through the API, imports and scheduled jobs. Company managers can browse and export the log. Nothing in Atlas edits or deletes audit entries, and data retention never applies to them. Atlas's own server logs leave out passwords, tokens, email addresses and phone numbers.

Actions by Atlas's own platform administrators are recorded too, in a separate platform audit log: granting or removing administrator access, sending someone a password reset link, and deactivating, reactivating or deleting an account.

Changes to how a person signs in are recorded in the same log: a changed email or password, two-factor turned on or off, passkeys added or removed, linked Google or Microsoft accounts removed, phone numbers added or removed, and sessions signed out remotely. These entries never contain passwords, codes or keys.

Each company can choose how long Atlas keeps notifications, closed tickets, expired compliance documents and CRM activity. Every policy is off until a company manager turns it on, each record type has a minimum period, and Atlas shows how many records a policy would remove before it's switched on. Records past the chosen period are then permanently deleted by a daily job, and each deletion is written to the audit log.

When someone leaves, offboarding ends their access to the company in one step while keeping the business records their work produced.

Content for this section is being prepared.

Content for this section is being prepared.

Content for this section is being prepared.