A1 Lane
Start free trial
Menu

Security basics

Status: product page (leg 3). Every statement below was written from the implementation; nothing here is aspirational. Anything not listed is not implemented.

Credentials and secrets

  • Platform credentials (OAuth tokens) are encrypted at rest with AES-256-GCM. The encryption key comes from server configuration or a key file that must live outside the data directory; the vault refuses a key file inside it.
  • Passwords are stored only as argon2id hashes; login compares against a dummy hash when the account does not exist, so timing does not reveal whether an email is registered.
  • Session tokens, API tokens, invitation and reset tokens are 256-bit random values stored only as SHA-256 hashes; the clear value is shown once. OAuth refresh tokens issued to assistants are stored the same way.
  • Workspace-level secrets you configure (link-shortener key, notification webhook secret) are encrypted in the workspace store with the vault key and never appear in settings views or exports.
  • Platform app secrets live in server configuration only; nothing in the repository or any export contains them.

Tenancy and access

  • Accounts support two-factor authentication (TOTP) with recovery codes, managed by the account owner under Account security.
  • Each workspace has its own SQLite database, media directory and event log; one workspace's queue, credential or outage cannot touch another's.
  • Every API, web and assistant request resolves the workspace through the caller: a user session (membership and role) or a workspace-scoped token (scopes read ⊂ write ⊂ publish). A workspace the caller cannot see answers 404. The deployment admin token runs the service (health, stats, billing attention) and opens no tenant data — there is no operator backdoor.
  • Roles: owner, admin, member, approver. Approvers approve or reject but cannot publish or connect accounts. Tokens can never hold the manage or approve permissions.
  • Client review links are HMAC-signed, expiring, revocable URLs scoped to one post.
  • Assistants connect through OAuth 2.0 (authorization code with PKCE, per-workspace grants, expiring access tokens, revocable refresh tokens) and get the same scoped token model as everyone else.

Transport and browser protections

  • Platform and billing calls go over HTTPS only; the outbound resolver refuses private addresses.
  • Cookies are HttpOnly, SameSite=Lax, Secure when the public URL is https. Cookie-authenticated writes are refused when the browser marks them cross-site or sends a foreign Origin.
  • Response headers: Content-Security-Policy (self only), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: same-origin, Cache-Control: no-store.
  • Stripe webhooks are accepted only with a valid Stripe-Signature (HMAC-SHA256 over the raw body, 5-minute tolerance); an unverified or replayed event changes nothing. Live-mode events are refused on a test-mode deployment.
  • Outgoing notification webhooks are signed t=<unix>,v1=HMAC-SHA256(secret, "t.body") so receivers can verify them.

Abuse controls

  • Throttles on sign-up (per address), login (per email + address, with lockout), password reset, public review links, and per-token calls on the assistant endpoint. Throttles are in-memory for the single-process deployment and reset on restart.
  • Upload size caps, media quotas, JSON body limits, plan limits (channels, seats, queue depth, storage) that fail loudly.

Delivery integrity

  • Receipts are append-only checkpoints; a restart resumes the stage, never re-sends a confirmed publish. An unconfirmed publish parks as uncertain and is never retried automatically.
  • Platform error text never reaches logs, the UI, the API or exports; only numeric codes do.

Export and deletion

  • Users export their account (every workspace they belong to) and delete it themselves from Account settings; deletion removes every owned workspace's database, media and vault entries.
  • Workspace owners export a workspace as JSON and delete it from Settings.
  • Cancelled or expired workspaces are retained for 30 days with export available; deletion afterwards is operator-confirmed by default.

What is not implemented (so nobody assumes it)

  • Single sign-on.
  • Email verification at sign-up is implemented but not enabled on this deployment yet; it turns on once the production mailer is proven (the G-01 sequence).
  • Field-level encryption of captions or media; media files are stored owner-only (mode 0600) on the server's disk.
  • Multi-process or multi-host throttles; the deployment shape is one process.
  • A bug bounty. Please report issues to [email protected].