LayerT whitepaper

The LayerT security model

Version
1.0
Published
18 September 2026
For
Security architects, CISOs
Reading time
14 minutes
Written by
The LayerT team
SummaryWho LayerT defends against, how, and what it deliberately leaves to other controls. A threat-by-threat walk-through with the residual risks stated.

Security products are usually sold on what they stop. This paper is about how LayerT reasons: what it protects, whom it assumes might attack those things, what it does about each of them, and what remains. Where LayerT relies on something else, such as your device management, your identity provider or the good faith of the people you make administrators, we say so.

It describes LayerT as built on 18 September 2026. LayerT is pre-launch. Anything not yet built carries a label.

What LayerT protects

LayerT sits in the browser your company already manages. It protects five things.

  1. Shared-account credentials. The passwords and authenticator seeds for the logins a team shares: social accounts, vendor and finance portals, admin consoles.
  2. Access decisions. Who may use which account, for how long, with whose approval, and who may get past a block.
  3. The integrity of your policy. The rules that say which sign-ins are allowed on work laptops.
  4. The record of what happened. The audit log, and recordings of shared-account sessions where you choose to keep them.
  5. Your people’s trust in LayerT’s own prompts. If employees learn to trust anything that looks like LayerT, a look-alike becomes a phishing tool.

Trust boundaries

PartyTrusted toNot trusted to
The web pageNothing. Every site, including a legitimate vendor’s, is treated as potentially hostileRead LayerT’s prompts, click them, or influence which account is offered
The LayerT extensionEnforce policy and broker sign-ins on a managed browser profileDecide anything on its own: policy and grants come signed or checked from the server
LayerT’s cloudStore sealed secrets, sign policy, check entitlements, keep the audit logAct outside your roles and approvals, or let LayerT staff browse your data
Your identity providerSay who people are and whether they’re active(It is the root of identity; LayerT follows it)
Your device managementInstall and configure LayerT on managed profiles(It is the root of deployment)

Threats and what LayerT does about them

1. A well-meaning employee signs in with a personal account

The risk. Someone signs in to personal email or messaging on a work laptop. Data leaves through a channel your network tools see only as an encrypted connection to a common website.

What LayerT does. A rule names the sign-in field. When the person submits, LayerT checks the typed value in the page, sees it isn’t a company account, and cancels the submission before the site’s code sends anything. The person sees a clear card with the admin’s message and, if the rule allows it, a way to ask for access. An approver decides how long any exception lasts. Every step is logged.

What remains. LayerT evaluates form submissions and pastes into named fields. It isn’t a data-loss prevention system, and doesn’t inspect files or the clipboard.

2. An employee tries to get around the policy

The risk. Someone who wants to avoid a rule might go offline, block LayerT’s servers, or try to feed the browser an old or altered policy.

What LayerT does.

  • Policy is signed with Ed25519 and verified in the browser. A modified policy doesn’t verify, so it isn’t used.
  • A policy’s version must always go up, and it must belong to your organisation, so an old or foreign policy can’t be replayed.
  • Policy expires after 7 days. A browser that can’t get a fresh one fails closed: on pages your block rules cover, it stops submissions until it reconnects. Going offline or blocking LayerT gains nothing lasting.

What remains. Until LayerT ships a signed extension package for force-install Coming soon, someone with local administrator rights could remove the extension. Your device management should keep people off local admin.

3. A hostile page imitates LayerT or interferes with it

The risk. A phishing page draws a fake LayerT prompt asking for a password. Or a page’s scripts try to read LayerT’s prompts, click them, or slide the account menu under the cursor.

What LayerT does.

  • LayerT prompts never ask for a password, and never contain a password field. Every prompt says so in its footer, and a test enforces it. A prompt that asks for a password isn’t LayerT.
  • While a genuine LayerT prompt is on a tab, the LayerT icon in the browser toolbar shows an amber dot. A page can copy a prompt’s look, but it can’t draw in the toolbar. The icon is pinned by policy, so it’s always visible.
  • Prompts live in closed shadow roots, out of the page’s reach, and act only on real clicks and key presses.
  • The shared-account menu is an extension page in its own frame. It accepts clicks only after being fully visible for a moment, and closes if the page moves or covers it.

What remains. The toolbar cue only helps if people learn to look for it. We teach it on this site, and recommend teaching it in onboarding. Clickjacking defences reduce the risk rather than removing it, so sensitive accounts can be set to launch from the toolbar only.

4. A look-alike site tries to receive a shared password

The risk. A domain that looks like your vendor’s tries to get LayerT to fill a shared account.

What LayerT does. Each shared account is tied to exact sites: scheme, host and port, with no wildcards, over HTTPS. The extension checks the page, and the service worker checks again using the address Chrome reports for the requesting frame. A look-alike gets nothing, and nothing is filled on page load.

5. Someone leaves the company

The risk. A leaver still knows the passwords to shared accounts, or still has a session open.

What LayerT does. They never knew the passwords. When your directory deactivates them, LayerT ends their console sessions, revokes their shared-account sessions and requests, and their browsers sign out of those accounts within about a minute. Their browsers can’t refresh credentials, so they un-enrol within the hour.

6. Someone with legitimate access misuses a shared account

The risk. A person approved to use the finance portal does something they shouldn’t while signed in.

What LayerT does. Access can require an approver each time, can be limited to one holder at a time, and ends on time. Sessions are listed live, and an admin can end one remotely. Where you choose, sessions are recorded and watermarked with the person’s name. Everything is attributed to the person, not to a shared login.

What remains. While signed in, a determined person could read the password from the vendor’s own password field using DevTools, as with any password manager. LayerT’s answer is governance: approval, time limits, recording and audit. For high-value accounts, rotate the password after sensitive use.

7. A laptop is lost or stolen

The risk. Someone gets a laptop with an enrolled browser.

What LayerT does. Device tokens last an hour. Shared-account sessions are time-limited, and LayerT doesn’t keep shared passwords in the browser after signing someone in. An admin can revoke the device, which removes its LayerT credentials and its access to shared accounts.

What remains. Disk encryption, screen lock and remote wipe are your device management’s job.

8. An administrator oversteps

The risk. One person with admin rights grants themselves standing exceptions, watches recordings without reason, or quietly changes policy.

What LayerT does.

  • Separation of duties. IT Admins publish rules but can’t grant permanent exceptions. Compliance Officers grant and revoke exceptions but can’t publish rules.
  • Nobody approves their own request. The server refuses it.
  • Optional two-author review stops people publishing rules they drafted.
  • Recording needs the Owner’s written attestation before any account can record, and every viewing needs a typed reason and is logged.
  • Revealing a stored password needs two people.

What remains. An organisation that gives one person every role removes these checks. LayerT shows whether both the IT and Compliance roles are filled, and records it if you choose single-person ownership.

9. LayerT’s own cloud is attacked

The risk. This is the most serious case for any SaaS product that holds secrets. LayerT’s servers can decrypt shared-account passwords and recordings. They have to, to sign people in and to play recordings back.

What LayerT does.

  • Secrets are stored with AES-256-GCM envelope encryption, one data key per account, with the data keys wrapped by a key-encryption key. The database holds only ciphertext. Recordings are encrypted on the device, and the storage bucket holds only ciphertext.
  • Moving key-encryption and policy-signing keys into a managed cloud key service is in progress Coming soon, so keys can be used but not taken.
  • LayerT staff can’t browse your data. Support access needs a named operator, a reason, a time limit and your Owner’s approval, and is logged in your audit log.
  • Policy is verified in the browser against keys built into the extension, so an attacker who could change what the API returns still couldn’t forge policy without the signing key.

What remains. A full compromise of LayerT’s servers and keys could expose secrets. LayerT isn’t in production yet. We’ll publish our hosting, key management and incident response before the first customer goes live. For your highest-value accounts, keep rotation and a break-glass route that doesn’t depend on LayerT.

Residual risk at a glance

RiskResidualYour control
Local admin removes the extensionUntil force-install from a signed package shipsKeep people off local admin
Authorised user reads a filled passwordBy designApproval, recording, rotate after sensitive use
Remote sign-out delayUp to about a minuteNone needed for most accounts
Recording shows page textBy defaultSwitch on text masking per account
Compromise of LayerT’s cloudSecrets decryptable with the keysRotation, separate break-glass for crown-jewel accounts
Look-alike promptsPeople must know the cuesTeach the toolbar dot and the password rule

What we ask of you

  1. Manage laptops with an MDM, and keep people off local administrator.
  2. Switch off Chrome’s built-in password manager by policy. LayerT’s templates include it.
  3. Keep your directory accurate: it decides who is active and what they may use.
  4. Put different people in the IT Admin and Compliance Officer roles.
  5. Decide, and write down, your lawful basis before switching recording on.
  6. Teach people the two cues: LayerT never asks for your password, and its toolbar icon lights up when it’s on the page.

Questions about this paper? Ask us in a demo. We’d rather answer a hard question now than in your security review.