Why Layerline · Trust

Trust, in plain terms.

What Layerline actually does for access control, audit, sessions, and encryption — sourced from the code, no vague claims.

01 · Role-based access control

Three-tier permissions, cascading from org to task.

Org-level roles (owner, admin, producer, member, external) cascade into project-level roles (admin, editor, member, viewer) which cascade into asset and task permissions. Org owners and admins automatically have access to all projects in their org; regular members must be added explicitly to a project. Project admins and editors can edit any task in their project; project members can only edit tasks assigned to them.

  • 01 Org roles: owner · admin · producer · member · external
  • 02 Project roles: admin · editor · member · viewer
  • 03 Asset & task permissions cascade from project role
  • 04 Every read/write enforces requireRole / requireProjectAccess
02 · Activity log

Every meaningful action is logged.

Layerline writes to an activity log for tasks (create, update, assign, status change), assets (status change, comment, output completion), file uploads, time entries, asset status changes, and asset comments. The log is a real database table — queryable, exportable, never silently truncated.

  • 01 Task lifecycle events
  • 02 Asset status changes + comments
  • 03 File uploads to Layerline Storage
  • 04 Time entries (start, stop, manual)
03 · Session versioning

Revoke a desktop session without breaking the browser.

Each user carries three independent token versions — browser, desktop, admin. Bumping a version invalidates only that client type instantly. A leaked desktop token can be revoked without logging the user out of the web app. Browser tokens last 7 days; desktop tokens last 90.

  • 01 Separate browser_token_version, desktop_token_version, admin_token_version
  • 02 Bump the version, the corresponding JWT family is invalid
  • 03 AuthGuard compares JWT version against DB on every request
  • 04 Login increments the version for that client type
04 · Encrypted credentials

Sensitive secrets are encrypted at rest.

Webhook secrets and API key hashes are encrypted using AES-256-GCM via encryptToken / decryptToken before they hit the database. Bulk content (project files, asset records) is not field-level encrypted today — we want to be honest about scope rather than overclaim.

  • 01 AES-256-GCM for webhook secrets
  • 02 AES-256-GCM for API key hashes (ll_mk_* prefix)
  • 03 TLS in transit
What we don't claim yet

Coming next, on the public roadmap.

Compliance attestations, enterprise single sign-on, multi-factor authentication, and field-level encryption at rest are on the roadmap — not in the product today. If your team needs any of these as a hard requirement before adopting, reach out and we'll share our timeline.

  • On the roadmap · Compliance attestations
  • On the roadmap · Enterprise SSO
  • On the roadmap · Multi-factor authentication
  • On the roadmap · Field-level encryption at rest

One OS. Every app. Yours.

Start free. No credit card, no procurement loop. Scale to a studio when you're ready.