Request a demo

Architecture

How LayerT is built

Written for the engineers and security reviewers who have to decide whether LayerT is sound. It says what the product does, how, and where the limits are.

Cream paper blocks laid out in a grid on a paper sheet, joined by thin teal paper lines like a system diagram.

Describes LayerT as built on 3 October 2026. Anything not built is labelled.

LayerT has two parts. A browser extension runs inside the Chrome profile your company already manages. A console and API is where admins, approvers and compliance people decide things. They talk only over HTTPS. There’s no proxy in your network path, no agent on the operating system and no new browser. The one exception is optional and per account: gateway routing sends one shared account’s own sites through a server you rent.

LayerT system overviewOn each managed laptop, the LayerT extension in Chrome has a service worker, content scripts and in-page prompts. It talks to the LayerT console and API over HTTPS: it receives signed policy and shared-account grants, and sends audit events, requests and encrypted recording chunks. The console and API store data in Postgres and encrypted recordings in object storage, and scheduled jobs handle expiry, retention, re-signing and notifications. Your MDM installs the extension. Your identity provider syncs people and groups over SCIM and signs admins in over OpenID Connect.Managed laptop · ChromeLayerT cloudLayerT extension: service workerVerifies policy, holds device credentials, talks to the APIContent scriptsIsolated world; watchonly what rules nameIn-page promptsClosed shadow roots;real clicks onlyThe pageSign-in forms, vendor sites. Not LayerT’s code.Console and APIRules, shared accounts, Inbox, Sessions, auditPostgresPolicy, audit, sealedsecrets (ciphertext)Object storageRecordings, storedas ciphertext onlyScheduled jobsExpiry, retention, re-signing, notificationsYour MDMInstalls and pins the extensionAdmins and approversUse the console in a browserYour identity provider (JumpCloud)People and groups over SCIM 2.0; sign-in over OpenID Connectsigned policy, grantsaudit, requests,encrypted recordingsreads the fields rules nameChrome policyHTTPSSCIM · OIDC
Every arrow is HTTPS. The extension sends audit events about the fields your rules name, with the text of a field a rule matched, and reports whether shared-account sign-ins worked. In a recorded session it also sends encrypted recording chunks. Notifications to approvers and optional gateway routing (early access, run in our test environment only) aren’t shown.

The five rules we build by

LayerT’s engineering follows a set of written rules. Every spec and every change is checked against them.

  1. Fail closed. If LayerT can't prove its policy is current and genuine, it blocks the actions that policy covers. It never quietly lets them through.
  2. Separate the people who configure from the people who grant exceptions. IT writes rules. Compliance grants lasting exceptions. Nobody approves their own request.
  3. Sign what the browser trusts; keep the audit trail readable. Policy is signed with Ed25519 and checked in the browser. The audit log is kept in plain words, so an auditor can read it.
  4. Use the real protocols. SCIM 2.0 for your directory, OpenID Connect for sign-in, RFC 6238 for authenticator codes, Web Crypto for signatures. Tests replace the data sources, never the protocols.
  5. A feature is done when a real browser proves it. Each flow has scenarios that drive real Chromium with the real extension loaded.

What runs where

PartRuns inWhat it does
Service workerThe extension, in ChromeEnrolment, the browser’s own key and its short-lived token, policy sync and signature checks, audit batching, shared-account grants
Content scriptsEach page, in Chrome’s isolated worldWatch only the fields your rules name, and files given to the places a file rule names; fill shared-account sign-ins; draw LayerT’s prompts
In-page promptsClosed shadow roots on the pageThe block card, the account menu, notices and the session chip. The page can’t read or click them
Console and APILayerT cloudRules, shared accounts, Inbox, Sessions, the audit log, SCIM and sign-in
PostgresLayerT cloudPolicy versions, audit events, directory data, shared-account secrets as ciphertext
Object storageLayerT cloudSession recordings, encrypted on the device before upload
Scheduled jobsLayerT cloud, a separate worker serviceExpire requests and sessions, apply retention, re-sign policy before it expires, send notifications, run access-review reminders

The details are in Components and data flows.

What LayerT’s servers can see

A security review should know this up front: LayerT is not zero-knowledge. To sign someone in to a shared account, LayerT’s servers decrypt that account’s password for an approved, time-boxed session and send it to the person’s enrolled browser. To play back a recording, the servers decrypt it for someone allowed to watch. When an Owner exports the whole organisation, the servers decrypt the kept recordings into that export. A password or authenticator setup key can also be shown once to a person, but only after two other people approve the request. Every one of these actions is checked against roles, bound to a person and written to the audit log.

The servers also receive what your rules match. When a rule matches, LayerT records what matched, and for a typing rule the text of the field, so an auditor can check the decision. A rule can mask or hide its values, and that setting is applied on the server, not in the browser. Data handling has the detail.

Why this design. LayerT brokers access: it decides who may use an account, when and for how long, and ends it on time. A vault that only the end user could open couldn’t enforce any of that. We chose governance over secrecy from the end user, and we say so plainly. Read the brokering whitepaper.

How far along it is

LayerT is pre-launch, launching in Q4 2026. It runs in a test environment with dummy data. Production is not deployed. Everything on these pages is built and tested unless it carries a label:

  • Off by default built, but a company has to switch it on (recording, watermark, auto-submit, two-author review)
  • Early access built and tested; it has run in our test environment only (gateway routing, through gateways on servers you rent, switched on per account)
  • Coming soon not built yet, or not finished (Edge, Firefox and Opera)
  • Proposed designed, not built

Two built parts depend on production rather than on more work. Keys held in a key service are built and in use in the test environment; production, which will use Google Cloud’s key service, is not deployed. Force-install from a signed extension package is built and switches on with the first production release; it has never run on a managed machine.

There are no customers or production deployments yet, and LayerT holds no certifications.

Go deeper

Signed policy and enforcementPublishing, signing, delivery, verification and failing closed.Shared accountsSealed storage, grants, filling, TOTP, ending sessions, break-glass.Sessions and recordingEnding a session remotely, recording with privacy defaults, watermark, gateway routing.Identity, tenancy and rolesSCIM, sign-in, each browser’s key and approval, isolation, permissions, audit.Data handlingWhat LayerT stores, where, for how long, and what never leaves the device.Limits and open workWhat LayerT doesn’t do, and what we’re still building.