Architecture
Shared accounts
LayerT keeps a team’s shared logins sealed, lets the right people use them for a set time, and fills the vendor’s sign-in form for them. Nobody needs to know the password.
Describes LayerT as built on 18 September 2026. Anything not built is labelled.
Storing secrets
Passwords and authenticator (TOTP) seeds are encrypted with AES-256-GCM envelope encryption:
- Each shared account gets its own random 256-bit data key. The password and the TOTP seed are each encrypted under it with their own random nonce.
- The data key is itself encrypted (“wrapped”) by a key-encryption key held on LayerT’s servers. Moving that key into a managed cloud key service is in progress Coming soon.
- Only ciphertext is stored, in its own table, apart from the account’s settings. Deleting an account deletes its secrets.
- Changing a password re-encrypts both secrets under a new data key and is logged.
Who may use an account
| Control | How it works |
|---|---|
| Access | Granted to directory groups, roles or named people. Group membership comes from your directory over SCIM |
| Sensitivity | Low, medium or high. Medium and high need an approver before each use by default. Only IT can mark an account high |
| Approval | Requests expire after 30 minutes. Nobody can approve their own. Approving re-checks that the requester is still active and still entitled. If two approvers decide at once, only one decision counts |
| One holder at a time | Optional, per account. A second person sees who has it and until when |
| Session length | Per account, 1 hour by default. Extending is possible up to 8 hours in total from approval |
Signing someone in
- BrowserPickThe person picks the account from the LayerT icon in the field, or from the toolbar launcher.
- LayerT cloudCheckThe session must be active, belong to this person and this enrolled browser, and the person must still be active and entitled.
- LayerT cloudDecryptOnly then is the password decrypted, in memory, and a grant returned over HTTPS.
- BrowserMatch the siteThe extension hands the grant to the page only if the page is the account’s exact site.
- The pageFillThe extension fills the vendor’s own form from Chrome’s isolated world. LayerT never shows the password.
The exact-site rule
A shared account is tied to exact sites: scheme, host and port must match, with no wildcards. https is required. The browser checks the page, and LayerT’s service worker checks again using the address Chrome reports for the requesting frame, not anything the page claims. A look-alike domain gets nothing.
Protecting the account menu
The list of accounts is an extension page shown inside a closed shadow root, so the site can’t read or restyle it. It only accepts real clicks, and only after it has been fully visible for a moment, which guards against tricks that slide the menu under the cursor. That reduces clickjacking risk rather than removing it. It closes if the page moves, covers or restyles it. Accounts can also be set to launch only from the toolbar, which turns the in-page menu off completely.
Submitting the form
Auto-submit is off by default. An owner can switch it on only after the account passes a test sign-in, and publishing a new sign-in recipe switches it off again. Even then, LayerT submits only when the person explicitly picked the account, on the exact site, in the top frame, with every filled field still visible, and never on page load. A CAPTCHA pauses LayerT and hands over to the person.
Authenticator codes
LayerT generates authenticator codes on its servers (RFC 6238). The seed never reaches a laptop. Only the current six-digit code is sent, when it’s needed, and filled like a password. The audit log records that a code was used, never the code.
What the person can and can’t see
LayerT never displays the password. It isn’t in the launcher, the menu, notifications or the audit log, and LayerT never saves it in the browser.
Ending a session
- On time. A minute before the end, LayerT offers Extend or Sign out now. At the end, it clears the site’s cookies and the tab’s site storage, which signs the person out.
- By an admin. An Owner or IT Admin can end a live session from the console, with a reason. LayerT refuses further grants for that session at once, and the person’s browser signs out within about a minute. They’re told an administrator ended it, not who or why.
- At offboarding. When your directory deactivates someone, or removes them from a group, LayerT closes their requests and sessions everywhere.
Setting up an account
- Detection. LayerT finds sign-in fields automatically. Where it isn’t certain, it asks the person to point at the field, and saves that as a suggested fix for the account owner to review. It’s never applied to anyone else automatically.
- Recording a recipe. For multi-step sign-ins, an owner records the steps once. The recipe stores where fields are, never what was typed.
- Test sign-in. An owner-only, logged run that proves the recipe works before auto-submit can be switched on.
Break-glass
- Revealing a password needs two people: an IT Admin or Owner asks, and a different IT Admin or Owner approves. It’s logged, and the password is then marked for rotation. Authenticator seeds are never revealed.
- An offline export for disaster recovery is encrypted, and needs two custodians to open, each with their own passphrase. Generating one is logged.
Limits
- Sign-in forms inside a cross-origin frame don’t get the in-page menu. Use the toolbar launcher.
- Forms drawn on canvas, or inside a site’s closed shadow roots, aren’t supported.
- LayerT doesn’t rotate passwords automatically yet.
- Real-time alerts for reveals and exports aren’t built yet Coming soon. Both are in the audit log.