LayerT whitepaper
The LayerT security model

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.
- Shared-account credentials. The passwords and authenticator seeds for the logins a team shares: social accounts, vendor and finance portals, admin consoles.
- Access decisions. Who may use which account, for how long, with whose approval, and who may get past a block.
- The integrity of your policy. The rules that say which sign-ins are allowed on work laptops.
- The record of what happened. The audit log, and recordings of shared-account sessions where you choose to keep them.
- 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
| Party | Trusted to | Not trusted to |
|---|---|---|
| The web page | Nothing. Every site, including a legitimate vendor’s, is treated as potentially hostile | Read LayerT’s prompts, click them, or influence which account is offered |
| The LayerT extension | Enforce policy and broker sign-ins on a managed browser profile | Decide anything on its own: policy and grants come signed or checked from the server |
| LayerT’s cloud | Store sealed secrets, sign policy, check entitlements, keep the audit log | Act outside your roles and approvals, or let LayerT staff browse your data |
| Your identity provider | Say who people are and whether they’re active | (It is the root of identity; LayerT follows it) |
| Your device management | Install 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
| Risk | Residual | Your control |
|---|---|---|
| Local admin removes the extension | Until force-install from a signed package ships | Keep people off local admin |
| Authorised user reads a filled password | By design | Approval, recording, rotate after sensitive use |
| Remote sign-out delay | Up to about a minute | None needed for most accounts |
| Recording shows page text | By default | Switch on text masking per account |
| Compromise of LayerT’s cloud | Secrets decryptable with the keys | Rotation, separate break-glass for crown-jewel accounts |
| Look-alike prompts | People must know the cues | Teach the toolbar dot and the password rule |
What we ask of you
- Manage laptops with an MDM, and keep people off local administrator.
- Switch off Chrome’s built-in password manager by policy. LayerT’s templates include it.
- Keep your directory accurate: it decides who is active and what they may use.
- Put different people in the IT Admin and Compliance Officer roles.
- Decide, and write down, your lawful basis before switching recording on.
- 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.