Architecture

Identity, tenancy and roles

Every action in LayerT belongs to a real person from your directory, not to a device or a shared login. Roles keep the people who configure apart from the people who grant exceptions.

Describes LayerT as built on 18 September 2026. Anything not built is labelled.

Your directory is the source of truth

LayerT runs a SCIM 2.0 server. Your identity provider pushes people and groups to it, and keeps them up to date.

  • Users and groups: create, read, replace, update and delete, with the standard discovery endpoints.
  • Filtering supports eq and and, which is what identity providers use for provisioning.
  • LayerT issues the SCIM token. It’s shown once and stored only as a hash. When you rotate it, the old token keeps working for 24 hours so provisioning doesn’t break.
  • Roles come from directory groups you map in the console. Someone with no mapping gets Read-only. When several mappings apply, the most privileged one wins.

LayerT is built for JumpCloud. Other identity providers that speak SCIM 2.0 and OpenID Connect, such as Okta, Microsoft Entra ID and Google Workspace, may work but aren’t certified yet.

Signing in to the console

The console uses the OpenID Connect authorization code flow with your identity provider:

  • LayerT finds your organisation from the email domain, then sends the person to your identity provider with a one-time state and nonce.
  • The returned ID token is verified against your provider’s published keys: issuer, audience, expiry and nonce.
  • The person must already exist in LayerT through SCIM. Nobody is created on first sign-in, and deactivated people are refused.
  • The console session lives on the server and is checked on every request, including the person’s current role. Revoking it takes effect immediately.

Credentialing each browser

People sign in once from the extension through your identity provider. That gives the browser its own credentials:

CredentialLifetimeNotes
Device token1 hourSent with every API call from the extension. Carries the organisation, the person and the device
Refresh token30 days, rotated on every useStored only as a hash. If two refreshes race, only one wins. A refused refresh un-enrols the browser

Admins can revoke a device from the console. It loses its LayerT credentials and its access to shared accounts, and any live shared-account sessions on it end.

When someone leaves

When your directory deactivates a person or removes them from LayerT:

  1. Their console sessions end immediately.
  2. Their shared-account requests and live sessions are revoked, and their browsers sign out of those accounts within about a minute.
  3. Their open access requests close.
  4. Their browsers can’t refresh credentials, so they un-enrol within the hour.
  5. Nobody can approve anything for them any more.

LayerT won’t let the directory deactivate the last active Owner. It keeps them active and tells the Owner why, so an organisation can’t lock itself out.

Keeping organisations apart

  • Every organisation-owned record carries its organisation and is filtered by it in the application, on every query.
  • Each organisation’s policy is signed separately, and the extension refuses a policy for any organisation other than its own.
  • Recordings are stored under a per-organisation prefix.
  • Tests check that one organisation’s credentials can’t read another’s policy, audit events, sessions or recordings.
Database-level isolation. Isolation is enforced in the application today. Row-level security in the database, as a second layer, is on our list.

LayerT’s own staff

LayerT staff can’t browse an organisation’s data. To see an organisation’s diagnostics, a named LayerT operator has to ask, with a reason, for up to four hours. Only that organisation’s Owner can approve it. Every view is logged in the organisation’s own audit log.

Roles

LayerT has six built-in roles. They’re designed so that the people who configure aren’t the people who grant exceptions.

Can…OwnerIT AdminCompliance OfficerTeam ApproverAuditorRead-only
Publish rules
Approve requests and shared-account use
Grant a permanent exception
Revoke an exception
Manage shared-account secrets
End a live session
Watch recordings
Switch recording on (attestation)
Revoke devices, emergency stop✓ (stop: Owner only)✓ (devices)
See the whole organisation’s audit logown only
  • Nobody approves their own request. The server refuses it for access requests and shared-account use. Revealing a password needs a second person.
  • Optional two-author review stops people publishing rules they drafted themselves.
  • Role changes are checked on both ends, so an IT Admin can’t demote an Owner.
  • Team Approvers can currently decide requests across the organisation. Scoping them to their own team is planned Coming soon.

The audit log

Every block, request, decision, sign-in, session, recording view and settings change is written to one log, in plain words.

  • Events are tied to the person from their credentials, never from anything the request claims.
  • Values are readable on purpose. If a personal address was blocked, the log shows the address, so an auditor can check the decision.
  • Kept for 365 days by default. Each organisation can change that.
  • Approvers and Auditors see the whole organisation. Everyone else sees their own events.
Not yet. Filtering and exporting the audit log, per-rule redaction of values, and tamper-evident storage aren’t built yet.