Atlas

Appearance

OSINT operational security ​

OSINT investigations change your threat model. The subjects you investigate sometimes have the means and motive to look back. This guide covers the practices that defend the workflow itself — separate from the investigation methods in the OSINT analyst guide.

Account isolation ​

Use a separate Atlas account per investigation domain. A single account that holds your trader watchlist, your client portfolios, and your OSINT subsets is a single point of correlation. If one account is compromised — credential stuffing, phished session, a careless screen share — the leak crosses domains.

Practical setup:

  • One account for personal trading.
  • One account for OSINT work.
  • Distinct emails (preferably distinct providers — different password recovery surfaces).
  • Distinct passwords stored in a password manager.
  • 2FA enabled on every account; recovery codes printed and stored offline.

Two-factor authentication ​

Mandatory for OSINT work. Setup in Settings → Security:

  1. Use a TOTP app (Google Authenticator, Authy, 1Password). Avoid SMS-based 2FA — SIM swap attacks are real.
  2. Print the recovery codes. Store them in a physical location separate from your authenticator device.
  3. If you lose the authenticator, the recovery codes are the only way back in. There is no soft-reset path that bypasses them.

Do not screenshot the QR code or recovery codes during setup — screenshots end up in cloud sync, on backup volumes, in places you don't fully control.

Session hygiene ​

  • Log out at end of session. Sessions are JWT-based with refresh tokens; logging out invalidates the refresh token.
  • Clear local storage when changing computers or finishing an investigation. Browser DevTools → Application → Local Storage → clear for the Atlas origin.
  • Don't use Atlas in incognito for OSINT. The session loss on tab close defeats the purpose, and incognito doesn't isolate against the network-level adversary you actually care about.
  • Use a dedicated browser profile for OSINT work. Separate cookies, separate extensions, separate fingerprint surface.

Network-level OPSEC ​

Atlas does not provide network anonymization — that's outside its scope. If your threat model includes the upstream data providers learning what you query:

  • Use a trusted VPN or Tor at the network layer. Atlas's backend is the only thing that talks to upstream providers, but your traffic to the Atlas frontend is still observable to your local network.
  • For Atlas instances you self-host, control the egress IP — see Self-hosting.

What AIS / ADS-B reveal about you ​

Nothing — directly. Querying for a vessel or aircraft does not broadcast your interest back to the subject. The data flow is one-way: the transponder transmits; you receive (via the upstream provider, via Atlas).

Indirectly — possibly. The upstream providers (MarineTraffic, OpenSky) can see what your account queries. If your account is identifiable to them, your interest pattern is too. Atlas reduces this exposure (the backend account at the provider is shared by the Atlas server, not per-user) but doesn't eliminate it.

If your threat model includes the upstream provider being adversarial or compromised, prefer self-hosting with credentials you control, and rotate them periodically.

What Atlas logs ​

The backend logs at INFO level by default:

  • HTTP method, path, status code, latency.
  • User ID for authenticated requests.
  • The _key() helper deliberately strips api_token query params before logging.

The backend does NOT log:

  • Request bodies (in the default configuration).
  • Response bodies.
  • Specific symbols, vessel MMSIs, or aircraft callsigns at the request level — but these may appear in upstream provider logs, which Atlas does not control.

For self-hosted instances, the operator controls the log retention and storage location. For hosted Atlas, see the privacy policy.

What Atlas does NOT do ​

  • Cross-reference your queries to your identity in any output you publish.
  • Send query history to third parties.
  • Bundle AI chat conversation history into upstream provider requests.

Defending the AI chat boundary ​

The AI chat sees your active panels' data and your conversation history within the active thread. It does NOT see other tabs, files, or your filesystem. The boundary is enforced server-side — the prompt template only injects context fields from your authenticated session.

Do not paste credentials, recovery codes, or notes about identifiable subjects into the chat. The chat sees only what's needed to answer questions about your panels.

If you suspect compromise ​

  1. Sign out of all sessions from Settings → Security (revoke active sessions, if available; otherwise, change password to invalidate all sessions).
  2. Rotate the password.
  3. Re-enroll 2FA — generate fresh recovery codes.
  4. Review the alerts panel for any rules you didn't create.
  5. Review subscription / billing for any unexpected changes via the Stripe portal.

Released under the project license. Public sources only — no proprietary or restricted data.

Atlas