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 3 October 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 files for macOS and Windows (Linux files exist too). The same policy switches off Incognito, Guest mode and Chrome’s own password manager, and on Windows it adds LayerT to your other force-installed extensions instead of replacing them. A person can also set LayerT up in a browser themselves, with their work account.
Every new browser then waits for an Owner or IT Admin to approve it, however LayerT was installed. Until it’s approved it gets no rules and can’t use shared accounts.
| Part | What it is | Notes |
|---|---|---|
| Service worker | The extension’s background process | Holds the browser’s own signing key and its short-lived token, 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, check files given to the places a file rule names, 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 | A web application | The admin console, the extension’s API, the SCIM 2.0 server and the OpenID Connect client |
| Worker | A separate service with no public address | Runs the scheduled jobs and sends notifications |
| Operator console | A separate site for LayerT staff | Creates and manages organisations. Staff can see inside an organisation only with that organisation’s approval (see Identity, tenancy and roles) |
| 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 | Google Cloud Storage | Session recordings only, encrypted on the device before upload. The bucket never holds plaintext |
| Key service | A cloud key service | Signs each policy version with Ed25519 and wraps the key that seals each shared-account secret and recording. Keys can be used through the service but never copied out of it. The policy signing key is software-protected: the service offers that type of key in software only, not in a hardware security module. Built, and in use in LayerT’s test environment. Production, which will use Google Cloud KMS, is not deployed |
| Scheduled jobs | Recurring jobs on the worker | Close expired requests and sessions, apply retention, re-sign policy before it expires, rebuild policy after directory changes, send notifications and reminders, check gateway health |
Hosting. LayerT isn’t in production yet. Today it runs in a test environment that holds dummy data only. In production it will run on Google Cloud in the EU, in the Milan region (
europe-west8), with its keys and database backups kept in Google’s EU multi-region. Cloudflare will handle DNS and send notification email. The providers are listed in Data handling. Other data residency options aren’t available yet.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 |
| Your gateways Early access | You | Small servers you rent. A shared account with routing switched on sends its own sites through one, so the vendor sees one address. LayerT checks each gateway from outside and tells it which connections to admit. LayerT doesn’t run gateways |
| 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 sends the public half of a key it made, proves it holds the private half, and gets a short-lived device token. It then waits for an administrator’s approval | The identity provider’s sign-in, and a signature from the browser’s key |
| Token renewal | Extension → API | A fresh short-lived device token | A proof signed by the browser’s key, checked against the public key LayerT stored at enrolment |
| Policy sync | API → extension | The signed policy for your organisation | Device token; the policy itself is verified with Ed25519 in the browser |
| The person’s groups | API → extension | The directory groups of this browser’s own person, and nobody else’s, as a signed answer valid for 24 hours | Device token; the answer is verified with Ed25519 in the browser |
| Audit | Extension → API | Events about blocks, matches, approvals and sessions, with the value a rule matched | Device token, which must match the event’s device |
| Continuing with a reason | Extension → API | The person’s reason for continuing past a block, with the rule, the page and the value. The action goes ahead only once the server has stored it | Device token; the person is taken from the token, never from the page |
| 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 |
| Gateway session Early access | API → extension | For a routed account: which gateway to use, a credential for this session only, and the address the vendor will see. No password travels in it | Device token, bound to the person’s active session |
| Gateway admission Early access | Gateway → API | The gateway asks whether to admit each new connection | The gateway’s own key. LayerT answers it only about its own organisation’s sessions |
| Scheduled jobs | Cloud Scheduler → worker | Trigger only | A Google-signed identity token for the scheduler’s own service account |
| Sign-in outcomes | Extension → API | Whether a shared-account sign-in worked, at which step it stopped, and the page’s address without its query. Never values, labels or page text | Device token |
| Device facts | Extension → API | Extension version, how the browser says it was installed, browser, operating system and policy version | Device token |
| Version check | Extension → API | Which LayerT version is newest. The answer is the same for every organisation | None. The request carries no credentials and nothing about the person |
| Notifications | Worker → approvers | Requests waiting on someone, answers and alerts, by email, Slack and the extension. No secrets and no full values | Email over SMTPS; Slack’s API with your organisation’s Slack connection; the extension’s device token |
| Slack decisions | Slack → API | An approver’s Approve or Deny on a request | Slack’s request signature, then the approver’s rights are checked again at the moment of the click |
What the extension sends, and what it doesn’t
LayerT reads only the fields your rules name. 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.
- It sends audit events when a rule matches: the rule, the page’s address, the field and the value that matched. For a form rule the value is the text of the field, and for a paste rule the pasted text. That’s how an auditor can see that a personal address was stopped.
- For a typing rule, the value is the whole text of the field as it was when the rule matched, not only the part that matched, up to 10,000 characters.
- For a file rule, it sends the file’s name, type and size, how the file was given to the page, and whether LayerT could read it. A file’s text is read in the browser to decide and is never sent.
- The browser always sends the value whole. A rule’s setting to mask or hide its values is applied on LayerT’s servers, before anything is stored. Values aren’t redacted in the browser.
- A password or code LayerT filled is never read by any rule, so there is nothing to send. A typing rule never reads a password box or a one-time-code box at all. A form or paste rule reads the fields it names, and that can include a password box a person typed into themselves.
- It sends access requests with the person’s reason, and encrypted recording chunks when recording is on for a shared account.
- It sends the reason a person gives to continue past a block, where a rule allows that.
- It reports whether each shared-account sign-in worked, and basic facts about the browser, so IT can see which laptops are protected. These reports carry no typed values and no page text.
- Events waiting to be sent are held in the extension’s storage until they’re delivered, and can include matched values.
- It doesn’t send pages. Outside a recorded shared-account session, the only page content it sends is the text of a field a rule matched, and it sends nothing typed into fields your rules don’t name. It never sends browsing history, a list of visited pages or cookie values. In a recorded session, what people type is masked where they type it, in form fields and rich-text editors, and the recording still shows what the page shows back: Sessions and recording has the detail.