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 18 September 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.

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 and re-signing. 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 sweeps, retention, policy re-signingYour 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 never sends page contents; it sends audit events about the fields your rules name. Optional gateway routing (early access) isn’t shown.

The five rules we build by

LayerT's engineering follows a written constitution. Every spec and every change is checked against it.

  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, device credentials, policy sync and signature checks, audit batching, shared-account grants
Content scriptsEach page, in Chrome’s isolated worldWatch only the fields your rules name; 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 cloudExpire requests and sessions, apply retention, re-sign policy before it expires

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. Both actions are checked against roles, bound to a person and written to the audit log.

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. Everything on these pages is built and tested in development 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, but not yet approved for production (gateway routing)
  • Coming soon in progress (Edge, Firefox and Opera; cloud key management; force-install from a signed package)
  • Proposed designed, not built

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.Identity, tenancy and rolesSCIM, sign-in, device credentials, 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.