Architecture
Components and data flows
Every moving part, where it runs, and every connection between them, with the protocol and the credential each side uses.
Describes LayerT as built on 18 September 2026. Anything not built is labelled.
In the browser
LayerT’s browser side is a Manifest V3 extension. Your MDM installs it and pins its icon to the toolbar using Chrome enterprise policy templates for Windows, macOS and Linux.
| Part | What it is | Notes |
|---|---|---|
| Service worker | The extension’s background process | Holds the device’s credentials, fetches and verifies signed policy, batches audit events, brokers shared-account grants, runs timers for session expiry |
| Content scripts | Scripts Chrome runs in each page’s isolated world | Separate from the page’s own JavaScript. They read values only from the fields your rules name, and fill shared-account sign-ins |
| In-page prompts | The block card, notices, account menu and session chip | Drawn in closed shadow roots, so page scripts can’t read or restyle them. Buttons act only on real clicks and key presses. They use system fonts, so LayerT never loads web fonts into other companies’ pages |
| Account menu frame | An extension page shown in a frame inside the prompt | The shared-account list lives in the extension’s own origin, not in the page |
| Toolbar popup | The launcher, approvals and quick add | An extension page; never part of a website |
The trust cue a page can’t fake. While any LayerT prompt is on a tab, LayerT lights an amber dot on its own toolbar icon. A website can copy the look of a prompt, but it can’t draw in the browser’s toolbar. LayerT prompts also never ask for a password, and a test enforces that no prompt contains a password field.
In LayerT’s cloud
| Part | What it is | Notes |
|---|---|---|
| Console and API | One web application | The admin console, the extension’s API, the SCIM 2.0 server and the OpenID Connect client |
| Postgres | The system of record | Signed policy versions, audit events, directory data, requests and sessions. Shared-account secrets are stored as ciphertext in their own table |
| Object storage | S3-compatible | Session recordings only, encrypted on the device before upload. The bucket never holds plaintext |
| Policy signer | Ed25519 signing of each policy version | Keys held server-side today; moving to a managed cloud KMS Coming soon |
| Scheduled jobs | Five recurring jobs | Close expired requests and sessions, apply retention, re-sign policy before it expires, rebuild policy after directory changes, check gateway health |
Hosting. LayerT isn’t in production yet. The planned setup is a managed platform with managed Postgres in a US region. Data residency options aren’t available yet. We’ll publish the hosting providers and regions here before launch.
Outside LayerT
| Part | Owned by | How LayerT uses it |
|---|---|---|
| Your identity provider | You | Sends people and groups to LayerT over SCIM 2.0, and signs admins and people in over OpenID Connect. Built for JumpCloud |
| Your MDM | You | Pushes the Chrome policy that installs LayerT, pins its icon and tells it which organisation it belongs to |
| The sites your people use | Vendors | LayerT reads and fills forms on them. It never changes a vendor’s servers or traffic |
Data flows
Every flow below runs over HTTPS.
| Flow | Direction | What moves | Authenticated by |
|---|---|---|---|
| Directory sync | Identity provider → API | People, groups, active status (SCIM 2.0) | A LayerT-issued SCIM token, stored only as a hash |
| Console sign-in | Browser ↔ API ↔ identity provider | OpenID Connect authorization code flow | Signed ID token, checked against the provider’s published keys |
| Console use | Browser → API | Decisions, rules, settings | A server-side session, re-checked on every request |
| Enrolment | Extension → API → identity provider | The person signs in once; the browser gets device credentials | The identity provider’s sign-in |
| Policy sync | API → extension | The signed policy for your organisation | Device token; the policy itself is verified with Ed25519 in the browser |
| Audit | Extension → API | Events about blocks, matches, approvals and sessions | Device token, which must match the event’s device |
| Requests and grants | Extension ↔ API | Access requests, decisions, shared-account grants | Device token, bound to the person and the enrolled browser |
| Recording | Extension → API → object storage | Encrypted recording chunks | Device token; chunks are already encrypted |
| Scheduled jobs | Platform scheduler → API | Trigger only | A shared secret, compared in constant time |
What the extension sends, and what it doesn’t
- It sends audit events when a rule matches, including the site, the field and the value that matched. That’s how an auditor can see that a personal address was stopped.
- It sends access requests with the person’s reason, and encrypted recording chunks when recording is on for a shared account.
- Outside a recorded shared-account session, it doesn’t send page contents. It never sends browsing history, or anything typed into fields your rules don’t name.