Architecture

Sessions and recording

Every use of a shared account is a session you can see and end. Recording, watermarking and gateway routing are there for the accounts that need them, and all three are off until you switch them on.

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

Sessions

A session starts when someone’s use of a shared account is approved (or starts straight away, for one-click accounts) and ends when they sign out, when time runs out, or when an admin ends it.

  • The console’s Sessions page lists every session, live ones first: who, which account, when, how long, and how it ended.
  • A session counts as live only while it’s active and its end time hasn’t passed. That’s worked out when the list is read, so a late background job can’t make an ended session look live.
  • Owners, IT Admins, Compliance Officers, Team Approvers and Auditors can see every session. Everyone else sees their own, and sessions on accounts they own.

Ending a session remotely

  1. ConsoleEndAn Owner or IT Admin ends a live session and gives a reason.
  2. LayerT cloudRefuseAt once: no new grants or extensions for that session, and its gateway, if it has one, refuses new connections. Logged with the admin and the reason.
  3. BrowserNoticeWhile a session is live, the extension checks in every minute.
  4. BrowserSign outLayerT clears the site’s cookies and the tab’s storage, and tells the person an administrator ended their session.
The person is told an administrator ended it, not who or why.
The minute in between. Until the browser checks in (up to about a minute), the vendor’s own session cookie still works in that browser. A browser that’s offline signs out as soon as it runs again.

Recording Off by default

Recording is for accounts where a replay is worth having: a finance portal, a social account, a contractor’s access. It’s off for every account until two things are true:

  1. The Owner has attested in writing that the company has a lawful basis, has done an impact assessment and has consulted worker representatives, or doesn’t need to. The attestation is logged. Withdrawing it switches recording off on every account.
  2. Recording is switched on for that account by an Owner or IT Admin.

What’s recorded, and what isn’t

LayerT uses rrweb, an open-source recorder, to capture a replay of the page: its structure and text, clicks, scrolling and the timing of network requests. It’s a replay, not a video.

CapturedNever captured
The page as displayed: its structure, text and styles, unless text masking is on. That includes what the page shows back after it was typedWhat people type, where they type it: form fields (inputs, text areas and selects) and rich-text editors are always masked, whatever the account’s text-masking setting
Clicks, scrolling, mouse movementPassword, one-time-code and sign-in fields, and hidden form fields, which are left out completely
Which boxes were ticked, which radio option was chosen, and the name of a chosen fileA chosen file’s contents, and which option was picked in a drop-down list
The addresses of pages and requests, with each request’s status and timingRequest and response bodies or headers
The account’s own siteOther tabs, other sites, anything outside the browser, canvas drawings, images and fonts
LayerT’s own prompts

Recording also pauses while LayerT fills a sign-in form, so the fill itself never appears.

What people type is masked where they type it, in form fields and rich-text editors, on every account. Masked means each character becomes an asterisk, so a replay shows that something was written and where, not what. LayerT treats as an editor any part of a page the site marks as editable, including one that becomes editable later, and the code editors it knows. The same holds in a frame of the page’s own origin, which is the only kind of frame a recording covers, and inside a site’s open shadow roots (web components).

Page text is visible by default. Typing is masked where it’s typed. A recording still shows what the page shows back: a sent message in a thread, a “results for …” heading, a preview. It also holds the addresses of pages and requests (including a search term a site puts in an address), which boxes were ticked, and the name of a chosen file. The text on the page is recorded unless you switch on text masking for that account, which hides displayed text too. If the vendor’s pages show personal data, the recording will too. That’s why the Owner’s attestation comes first.

Two things aren’t recognised as editors: a terminal emulator, and a region made editable by styling alone. What’s typed there is recorded as page text. Limits and open work has the full list.

Telling the person

While a session is recorded, the session chip reads “recording”. The first recorded session shows a notice that doesn’t go away by itself. If recording can’t start, the chip says so and the person’s work carries on.

Encryption

  1. BrowserNew keyThe extension makes a fresh AES-256 key for this recording, kept in session memory only.
  2. BrowserEncryptEvents are compressed and encrypted in chunks before they leave the browser.
  3. LayerT cloudWrapThe key is sent once and wrapped immediately. Only the wrapped key is stored.
  4. Object storageStoreThe bucket holds ciphertext only.
  • Each recording has its own key. Each chunk has its own random nonce.
  • Chunks waiting to upload are kept encrypted on the device, with a size cap.
  • The wrapping key is held in a key service, which unwraps each recording key on request and never hands the wrapping key out. The key service is built and in use in LayerT’s test environment, but no recording has been stored there: recording itself has been tested in development only. Production, which will use Google Cloud’s key service, is not deployed.
Decrypted on the server for playback and export. To play a recording, LayerT’s servers decrypt it and send it to the viewer’s browser. When the Owner exports the organisation, the servers also decrypt every kept recording into that export. So LayerT can read recordings, and access to them is controlled by role, reason and audit.

Who can watch

  • Only the Owner, IT Admins and Compliance Officers.
  • Every viewing needs a typed reason and is written to the audit log against the viewer’s name.

Retention

Recordings are kept for 90 days by default. The Owner can choose anything from 7 to 365 days. A daily job deletes expired recordings (the stored chunks first, then their records) and logs each deletion.

Recordings are evidence, not proof

The recorder runs inside the vendor’s page, so a page could in principle interfere with it. Treat a recording as strong evidence of what happened, alongside the audit log, not as tamper-proof proof.

Watermark Off by default

When switched on for an account, LayerT draws a faint, tiled watermark over the vendor’s site with the person’s name, email, a short session ID and the time. It doesn’t block clicks, comes back if the page removes it, and prints.

Deterrence and attribution, not prevention. Anyone with DevTools can remove it, switching off the extension removes it, and nothing stops a phone camera. It’s also faint on dark vendor pages. It makes a screenshot traceable. It can’t stop one being taken.

Gateway routing Early access

Some vendors expect a shared account to come from one known IP address, so that they can allow-list it. Gateway routing sends one shared account’s sites through a gateway, so the vendor sees one steady address.

The gateway runs on a server you rent, such as a small virtual server with a static IP, so the address is yours. An Owner or IT Admin adds a gateway in the console and pastes one command on the server. LayerT then checks the gateway from outside and shows it online, with the addresses to give the vendor. It gives the gateway a name and a certificate, keeps its software up to date, and tells you if it goes offline, if its IP changes or if its certificate has a problem. A gateway whose IP changes is paused until an Owner or IT Admin confirms the new address. LayerT doesn’t run gateways itself.

Early access. Gateway routing is built and tested. It has run in our test environment only, on test servers with practice-site accounts. Nothing is in production yet.

What is routed

  • Routing is opt-in per account. It’s off for every account until an Owner or IT Admin chooses the account’s home gateway and switches routing on.
  • It applies only to that account’s own sites, and only while someone has an active session on it. Everything else in the browser goes direct.
  • TLS stays end to end. The gateway sees which host is being reached, and when, but not the content.
  • The gateway asks LayerT’s servers to admit each new connection. Each gateway has its own key, and LayerT answers it only about its own organisation’s sessions. A gateway opens a site only for a person who has that site’s account open in that browser.
  • A person can have two routed accounts open through one gateway in one browser at the same time. Another person’s session, one in another browser, or one that has ended is still refused.
  • A backup gateway takes over at the next sign-in, not in the middle of a session.

The route first, then the page

  1. BrowserOpenThe person opens a routed account from LayerT.
  2. LayerT cloudSessionLayerT checks the session and answers with the gateway to use, a credential for this session only and the address the vendor will see. No password travels at this step.
  3. BrowserRouteLayerT switches the account’s sites to the gateway and checks that the browser took the setting.
  4. GatewayLoadOnly then does the sign-in page load, through the gateway.
  5. The pageFillLayerT fills the vendor’s form, as for any shared account.
For a routed account, the vendor’s first sight of the session is the gateway.

When someone picks the account on a sign-in page they opened themselves, LayerT doesn’t fill that page. It starts routing, clears the account’s cookies as it does when a session ends, loads the page again through the gateway, and fills it there.

When the session ends, its cookies are cleared and its tabs are told before the route is taken down.

What the person sees

While a session goes out through a gateway, the session chip names the gateway and the address the vendor sees, for example “via London 1 · 203.0.113.7”, and the address can be copied. The first page loaded through the gateway also says, once, that the session goes out through your organisation’s gateway.

In LayerT’s menu on a sign-in page, a routed account’s row says which gateway it goes out through, by name only, before the person picks it.

When the gateway can’t be reached

By default, a routed sign-in isn’t opened when no gateway can take it. LayerT tells the person why, and doesn’t load the vendor’s page from the person’s own address.

An Owner or IT Admin can set an account to Go direct instead, under If the gateway can’t be reached. The sign-in then opens from the person’s own address, with a notice saying so. The choice is the account’s own, and the change is logged.

If a gateway stops in the middle of a session on an account that refuses, the account’s sites stop loading for the rest of that session and the page says why. The person ends the session and signs in again, which is when a backup gateway takes over.

Limits of gateway routing

  • An open connection isn’t cut. When a session ends or is revoked, the gateway refuses new connections at once, but a connection that is already open carries on until it closes.
  • A typed address loads its first page direct. A person who types the vendor’s address themselves loads that first page from their own address, because LayerT can’t route before there is a session. A vendor that allow-lists will refuse that page; the person starts from the LayerT icon instead.
  • Go direct shows the person’s own address. An account set to go direct lets the vendor see where the person is when the gateway fails. That is the account’s own choice.
  • A browser whose proxy is managed elsewhere can’t use a refusing account. If a policy, a VPN client or another extension controls the browser’s proxy settings, LayerT can’t route there, so an account set to refuse isn’t opened in that browser at all.
  • WebRTC isn’t handled, so a page that uses it can still learn the person’s own address.
  • Other browsers and other Chrome profiles aren’t routed.
  • It’s one address per account, per site, not one address for everything the company does.

The console’s routing map shows which accounts go through which gateway and who can reach them. It only reads your settings and changes nothing. Its gateway views fill in once you’ve added a gateway.