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 3 October 2026. LayerT is pre-launch: it runs in a test environment with dummy data, and production is not deployed. 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, authenticator setup keys and other secret sign-in fields 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 in a browser an administrator has approved | 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 | Approve a browser. However LayerT was installed, every new browser waits for an administrator’s approval |
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. Rules act only on what your administrators name. That now covers form submissions, pastes, typed text and files given to a page, by name or by the text inside a plain-text file. The limits matter more than the list:
- LayerT reads plain text only. It doesn’t look inside PDFs, Office files or images. A rule about file text stops those rather than reading them.
- Data a page sends by itself, without a form, a paste, a typed field or a file given to it, is outside every rule.
- A typing rule can’t keep text out of the page. The text is there from the first keystroke, and a page that sends as you type already has it. The rule tells the person and stops the text being sent with a form, a submit button or Enter.
- LayerT doesn’t read or control the clipboard, and has no library of ready-made detectors.
- What a rule matches is recorded, readable by default, and a typing rule records the text of the whole field. That is a record about your own people, and it needs their knowledge and your assessment.
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.
- A rule that applies to a directory group fails closed the same way. A browser that doesn’t hold a current, signed answer about its own person’s groups stops the action on pages where a blocking rule names a group.
What remains. Force-install from a signed extension package is built and switches on with LayerT’s first production release. It hasn’t yet run on a managed machine. Chrome doesn’t let people remove a force-installed extension through its settings. But the browser runs on a laptop its user may control: someone with local administrator rights can change browser policy or tamper with the browser, and so defeat enforcement. The policy stored in the browser profile can also be read, and its signature is checked when it arrives, not each time it’s used, so someone who can write to that storage can change it on that laptop. Your device management should keep people off local admin, and you should treat the policy as internal to your organisation.
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.
Some sites show their sign-in form inside a frame from another address of the same company. LayerT fills such a form only when the top page is an address the account names, the frame belongs to the same site as that page, the frame isn’t sandboxed and the frame is visible. It says on the page which address the form belongs to. A frame from an unrelated site is refused, a frame nobody can see is never filled, and LayerT never presses the sign-in button in a frame.
What remains. For frames, “the same site” means the same registrable domain as the page the account names, so a frame on another host of that site can be filled when the account’s own page embeds it. An account can be set to exact addresses for frames too.
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 renew their token, so they un-enrol within minutes. For people who change roles rather than leave, quarterly access reviews ask each account’s owner to confirm who still needs it, and show whether each person actually used it.
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. Each browser’s credential is tied to a key made in that browser that can’t be exported. The token the browser uses lasts minutes, and renewing it needs a proof signed by that key, so a copy of the token alone stops working within minutes and there is no long-lived credential to lift. 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. The key is protected by the browser’s software, not by a TPM or a Secure Enclave, and this isn’t device attestation. Someone who can run software as the person on that laptop can use the key there. Disk encryption, screen lock and remote wipe are your device management’s job.
8. Someone sets up a browser that isn’t yours to trust
The risk. Anyone who can sign in as one of your people, on a personal laptop or with stolen credentials, sets LayerT up in a browser of their own to get your rules and your shared accounts.
What LayerT does. Every new browser waits for an administrator’s approval before it gets any rules or shared accounts. Until an Owner or IT Admin approves it on Devices, LayerT’s servers give it no policy and no shared account, and its popup says it’s waiting. Owners and IT Admins are told about a waiting browser, and the Inbox lists every one. What the browser reports about how it was installed is shown to the approver and decides nothing, because it is only the browser’s own word. For 7 days after a decline, the browser can be put back in the queue, which approves nothing.
What remains. Approval is a person’s judgement. It doesn’t prove that a device is company-owned or managed. An Owner or IT Admin can approve their own browser, and the audit log names the approver. The person whose account set the browser up isn’t told by email. A registration token delivered by device policy, which would tie set-up to your device management, isn’t built.
9. 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, by default, can’t grant permanent exceptions. Compliance Officers grant and revoke exceptions but can’t publish rules. An Owner can give one named person the right to grant permanent exceptions, and that change is logged.
- 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.
- Seeing a stored password needs two approvers other than the person asking, one of them an Owner or Compliance Officer. The requester sees it once, after a fresh sign-in, and Owners, Compliance Officers and the account’s owner are alerted. The password is then marked as seen, to be changed.
- Password requests, permanent exceptions and rule changes can be decided only in the console, never from a Slack message or an email link.
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.
10. 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.
- The key-encryption and policy-signing keys are held in a key service, where they can be used but not copied out, and every use is logged by the service. This is built and in use in LayerT’s test environment. Production, which will use Google Cloud’s key service in the EU, is not deployed.
- The policy-signing key is software-protected: the key service offers that type of key in software only, so it isn’t held in a hardware security module.
- 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, with the ability to use the keys, could expose secrets. The keys aren’t separate per organisation. The audit log, with the values your rules matched, is readable there too, unless a rule is set to hide its values. LayerT isn’t in production yet. It will run on Google Cloud in the EU (the Milan region), with keys and backups in Google’s EU multi-region; see Data handling. We’ll publish our 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 defeats enforcement | Always possible on a laptop the user controls | Keep people off local admin |
| Policy on the device can be read | By design: it’s signed, not secret | Treat the policy as internal |
| A typing rule records the whole field | Readable by default, up to 10,000 characters | Set the rule to mask or hide its values; tell your people |
| A site’s own background uploads | Outside every rule | Don’t rely on LayerT for them |
| A browser’s key is software-protected | Software running as the person can use it on that laptop | Endpoint protection; revoke the browser |
| Approving a browser you shouldn’t | A person decides; LayerT doesn’t attest devices | Approve only browsers you recognise; the audit log names the approver |
| Audit log isn’t tamper-evident | Until tamper-evident storage is built Proposed | Export the log regularly; exports carry checksums |
| 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, including what the page shows back after it was typed | By default. Typing is masked where it’s typed, in form fields and rich-text editors | Switch on text masking per account |
| A form or paste rule can read a password a person typed | When the rule names that box. Readable by default. No rule reads a password LayerT filled | Don’t name password boxes in a rule, or set the rule to hide its values |
| 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.
- Approve new browsers promptly, and only the ones you recognise.
- Tell your people what your rules record, above all a rule that watches typed text.
Questions about this paper? Ask us in a demo. We’d rather answer a hard question now than in your security review.