How we protect your data.

1. In brief

Atlas Labs follows three working principles: we hold the minimum data needed to provide the service; what we hold, we encrypt; what we cannot encrypt, we audit. Section 2 expands the principles; sections 3 through 10 describe the specific controls; sections 11 through 15 describe how we demonstrate the controls work.

• Encryption at rest on every sensitive field — taxpayer identifiers, exchange API credentials, bank tokens, and TOTP secrets — under AES-256-GCM with per-user keys derived through HKDF-SHA-256 from a separate master per data class. A breach of the database alone yields encrypted blobs only; a breach of the server still requires per-user iteration to decrypt.
• Hashed credentials. Passwords (bcrypt cost-12), refresh tokens (SHA-256), and platform PINs (bcrypt) — the plaintext never persists.
• Read-only wallet model. We never see your private keys. We never request them. We cannot recover funds, sign transactions, or move Crypto-Assets on your behalf.
• Coordinated disclosure. Every domain publishes /.well-known/security.txt per RFC 9116 pointing at security@hq-fs.com with a 90-day disclosure window.

2. Security principles

The principles below describe how we make decisions when a new feature touches sensitive data. Each one is reflected in specific controls in the sections that follow.

• Data minimisation. If we do not need a piece of data, we do not collect it. Where the audit discovered we held data we did not use (vestigial OAuth tokens on the Account table), the disposition has been written down for removal.
• Encryption with per-user keys. A single master key is a single point of compromise. Per-user keys derived via HKDF-SHA-256 turn a server breach into a serial decryption problem rather than a bulk one.
• Domain separation. Each sensitive data class has its own master key. A leak of one master does not unlock the others.
• Fail-closed audit. Where audit logging is appropriate, the disclosure is gated on the log write succeeding — the data is not returned if the audit cannot be recorded.
• Read-only by default. Connected services are added with the minimum scope. Wallets via SIWE signature, exchanges via read-only API keys, banks via read-only OAuth.
• Coordinated disclosure. Researchers report privately first; we patch; we credit; we publish. Adversarial behaviour is the only path that closes the channel.

3. Encryption at rest

Sensitive fields are encrypted at the application layer before they reach the database. The cipher is AES-256-GCM throughout; integrity is built into the cipher, so a modified ciphertext fails to decrypt rather than producing a wrong value. The blob format is versioned (v2:iv: ciphertext:tag) so future rotations or scheme changes are non-breaking.

The encryption key for each row is derived per-user from a data-class master: HKDF-SHA-256(masterKey, salt = userId, info = purpose). The purpose strings are domain-separated: cex-credentials, bank-credentials, tax-id, totp-secret, email-pii, name-pii, oauth-tokens. A derived key cannot be reused across data classes even if the same master is supplied, and a compromise of one master does not open the others.

For a database-only breach, the decrypted plaintext is not recoverable: the master keys live in the application server's environment, not the database. For a combined database + application-server breach, an attacker still has to iterate per user — the per-user salt prevents a single bulk decrypt operation from yielding every row at once.

4. Encryption in transit

Every Atlas Labs domain serves traffic over TLS 1.2 or higher. The Strict-Transport-Security header is set withmax-age=63072000; includeSubDomains; preload; the apex domain is on the HSTS preload list, so a first-time visitor is already directed to HTTPS by the browser before our redirect runs.

All inter-service calls between Atlas Labs applications (auth ↔ ledger, ledger ↔ docs, etc.) are HTTPS-only with an internal shared-secret header, gated by an explicit CORS allowlist, and authorised at the application layer.

5. Authentication and access control

Authentication is RS256 JWT issued by the auth service. Access tokens have a 15-minute lifetime; refresh tokens are 7 days. Both ride HttpOnly, Secure, SameSite=Lax cookies. The refresh-token record stored in the database is the SHA-256 hash of the raw token; the raw token only ever lives in your browser.

Passwords are hashed with bcrypt at cost factor 12 — high enough to make offline dictionary attacks slow on consumer hardware, calibrated to verify in roughly 200ms on production hardware.

On a failed login, the email-keyed counter records the attempt. From the third failure on, the attempt window backs off exponentially; from the fifth failure, the account is locked for 15 minutes. Successful login resets the counter. The error message is identical regardless of whether the email exists, blunting enumeration attacks; a separate code surfaces only when a lockout is in effect so the UI can show a meaningful retry timer.

Two-factor authentication is RFC 6238 TOTP. The seed is encrypted at rest under a per-user HKDF-derived key (see section 3). Recovery codes, where issued, are bcrypt-hashed before storage.

Role-based access control limits staff and tenant-admin actions in the application. Where high-sensitivity action is permitted (revealing a stored taxpayer identifier, for instance), an additional per-user PIN is required at the moment of action — verified server-side, audit-logged, CSRF- gated.

6. Application security controls

Beyond authentication, the application enforces a set of standard mitigations against the OWASP Top 10 and ASVS v4 control set.

• Cross-site request forgery. The Next.js proxy on every authenticated app sets a non-HttpOnly csrf_token cookie on navigation responses and verifies a matching header on every state-changing request (POST / PUT / PATCH / DELETE). Bearer-token routes (agent API, internal service-to-service) and webhook endpoints are exempt with their own auth.
• Security response headers. X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy denying geolocation, camera, microphone, payment and FLoC, and a Content Security Policy listing every script and connect target explicitly.
• Bot challenge. Cloudflare Turnstile gates registration and password reset. Soft-skipped when no secret is configured (dev convenience), enforced in production.
• Rate limiting. @fastify/rate-limit applies per-route buckets — the heaviest is on POST /auth/login (5 attempts / 15 min / IP) and POST /auth/register (10 / hour / IP).
• Input validation. Every API endpoint validates input through Zod schemas before reaching the database layer. SQL is exclusively parameterised through Prisma; no string interpolation reaches the query planner.
• Output encoding. React escapes by default; the few server-rendered HTML strings (blog posts, event rules, audit response) are produced from a trusted Markdown renderer that escapes HTML in user- authored sections before re-introducing the safe tag set.
• Dependency posture. Direct dependencies are pinned in lockfile; weekly automated review against the npm advisory database; security patches applied within seven days of publication for high or critical advisories.

7. The wallet model — read-only by design

Atlas Labs cannot lose your funds because we cannot move your funds.

When you connect a self-custodial wallet (e.g. MetaMask, Coinbase Wallet, hardware wallet via WalletConnect), you sign a Sign-in-With-Ethereum (SIWE) message proving ownership of the address. We store the address (a public identifier) and the timestamp of the signature. We never receive your seed phrase, your private key, or any signing capability. Importing transaction history is performed by reading the public chain through indexers (Etherscan, Routescan, Alchemy, Chainstack) — which never see your wallet either; they index the chain.

When you connect a centralised exchange via API (Coinbase, Kraken, Binance, etc.), the API keys you supply are encrypted with AES-256-GCM and stored under your per-user HKDF-derived key. The plaintext key and secret never persist. The keys you supply must be read-only on the exchange side — the import wizard tests for read-only scope before accepting them and refuses keys that grant trading or withdrawal capability.

When you optionally use the Atlas wallet vault feature, the private key is encrypted client-side with PBKDF2-SHA- 256 (310,000 iterations, OWASP-recommended) using a passphrase only you know. The server stores the ciphertext; we cannot decrypt it under any circumstances, including with a court order. If you lose the passphrase, we cannot recover the key — the trade-off is intentional and stated on the vault setup screen.

8. Audit logging

Sensitive disclosures and high-impact actions are individually audit-logged. The most stringent surface is the taxpayer-identifier reveal: every plaintext disclosure of a stored TIN passes through a fail-closed audit log that captures the user ID, person ID, portfolio ID, timestamp, request IP, user agent, and supplied reason. The disclosure is refused if the log write fails, with a 503 returned to the caller — the audit is not an afterthought, it is the gate.

Audit-log records are retained for seven years to satisfy tax-record retention obligations in the largest jurisdictions in our user base. The records are immutable at the application layer (no UPDATE or DELETE path exists) and stored in the same database with the same encryption-at-rest discipline as other rows.

9. Logs and retention

We retain operational logs only as long as they are useful for security monitoring and incident investigation.

• Server access logs (IP, request line, status, user agent) — 14 days.
• Authentication logs (success and failure, IP, user-agent, account ID where applicable) — 90 days.
• Application error logs — 30 days.
• Sensitive-field audit log — 7 years (see section 8).
• Billing records — 7 years to satisfy accounting and tax retention obligations.

No logs contain plaintext sensitive fields. Email addresses appear in authentication logs in hashed form (matching the searchable-encryption hash used for login lookup).

10. Sub-processors

We use a small number of third-party services. Each processes only the data necessary for its function. We sign data-processing agreements where required by GDPR Article 28, UK GDPR, and PDPA equivalents. The full list is published in our Privacy Notice section 7.

We will publish a sub-processor list and a notification channel for sub-processor changes once we onboard our first business tenants. Material additions or replacements will be announced 30 days in advance via email and in-product banner; account holders may terminate without penalty before the change takes effect.

11. Compliance posture

The table below lists every security and compliance control we publicly commit to, along with whether it is live today, in progress, or on the roadmap. The status column updates with the codebase; this page is regenerated as part of the release process.

Items in the "In progress" or "Roadmap" column are tracked in the workspace blocker registry and attributed to the workstream that owns them. Where a certification (SOC 2, ISO 27001) is on the roadmap, this page does not assert the certificate before we hold it — the "Roadmap" status is the honest signal.

12. Industry frameworks we benchmark against

The controls above are designed against published standards, even where the corresponding regulatory regime does not compel us. The standards we benchmark against and what they contribute:

• ISO/IEC 27001:2022. The information security management system shape — Annex A controls A.5 through A.8 — informs the policy structure, change management, and supplier review processes. Certification is on the roadmap (blocker LD-0008).
• SOC 2 Trust Services Criteria. Security, Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 Type II audit is scoped on the same engagement as ISO 27001.
• NIST SP 800-53 Rev. 5. Used as the reference for control depth on Identification and Authentication (IA), Access Control (AC), Audit and Accountability (AU), and System and Communications Protection (SC) families.
• CIS Critical Security Controls v8. The tactical companion to NIST 800-53; specifically informs the rate-limit, brute-force, and dependency-management controls.
• OWASP ASVS v4 Level 2. Application- security verification standard; the level-2 control set is the bar for every authentication and session management feature.
• OWASP Top 10 (2021). The negative-space companion to ASVS — every category has a written mitigation in section 6.
• GDPR Article 32 + UK GDPR + PDPA Section 24. Security of processing. Our encryption-at-rest, access- control, and incident-response posture is designed to satisfy each.
• MAS Technology Risk Management Guidelines. The Monetary Authority of Singapore's guidance for financial institutions. We are not MAS-regulated as a non-VASP, but we adopt the framework as a benchmark because Atlas Labs is incorporated in Singapore and the guidance reflects the regulator's expectations of financial-data handlers in our jurisdiction.
• FATF Recommendation 10 (CDD). Explicitly out of scope: we are software, not a virtual-asset service provider, and we do not perform value transfer or holding. We name the recommendation for clarity so that finance buyers reviewing this page know the question is not unanswered.
• PCI DSS v4.0.Out of scope: we never see cardholder data. Stripe's hosted surfaces handle the card details directly. Stripe is PCI DSS Level 1 certified; the scope of our integration falls under SAQ A.

13. Incident response

We maintain a documented incident-response runbook covering detection, triage, containment, eradication, recovery, and post-incident review. The runbook is available to qualified buyers under NDA on request.

Where a personal-data breach occurs, we notify affected users and the relevant supervisory authority without undue delay and within 72 hours where feasible, consistent with GDPR Article 33, UK GDPR, and PDPA Section 26D. Where the breach is likely to result in a high risk to the rights and freedoms of natural persons, we notify affected users directly under Article 34 GDPR and the equivalent rules.

Material customer-impacting events are also disclosed on this page's public-audits section (15) and recorded in our changelog.

14. Coordinated vulnerability disclosure

Atlas Labs operates a coordinated vulnerability disclosure programme. Every domain publishes /.well-known/security.txt per RFC 9116 pointing at security@hq-fs.com with the canonical policy at /security-policy.

Headline terms: 90-day coordinated disclosure window; acknowledgement within three business days; preliminary triage within ten business days; remediation target of 30 days for Critical and High issues. Researchers are credited (with consent) in our public Hall of Fame and earn thesecurity_researcher Legendary achievement on their Atlas Labs account.

A formal monetary bounty programme is on the medium-term roadmap. Until it is funded, recognition is non-cash; the policy is not a contract for payment.

15. Public audits

We commission independent and internal audits of the platform on a recurring schedule. The reports below are the public ones; private commercial audits and customer- specific reviews are available under NDA on request.

• Data Protection & Encryption Audit (2026-05-07). Scope: encryption at rest, cryptographic key management, sensitive-field disclosure controls, audit logging. Outcome: 6 of 17 prior findings remained open; remediated to 1 critical (since closed) during the same week. Re-audit on the same date.
• GTM Readiness Audit (2026-05-05 / 06). Scope: rate limiting, brute-force lockout, security headers, CSRF, Turnstile, design-token consolidation. All Critical and High findings closed.
• User Acquisition Strategy & Growth Readiness Audit (2026-05-06). Scope: competitive analysis, acquisition funnel, analytics, advertising, affiliate, ambassador, bug bounty, gamified events. 16 of 17 findings closed in code on 2026-05-07; the remaining item (demo content seed) is operational follow-up.

Future audits scheduled: third-party penetration test (pre-public-launch), SOC 2 Type II readiness assessment, ISO 27001 stage-1 review.

16. Questions

Buyers, auditors, and security professionals can reach us at security@hq-fs.com. For sales-cycle security review packs (questionnaires, SIG Lite responses, redacted audit reports) write to legal@hq-fs.com and reference your buying context.

For end users with a privacy or rights question, see the Privacy Notice. For the legal contract framing the service, see the Terms of Service.