Request a demo

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 3 October 2026. Anything not built is labelled.

Storing secrets

Passwords, authenticator (TOTP) setup keys and secret sign-in fields are encrypted with AES-256-GCM envelope encryption:

  • Each shared account gets its own random 256-bit data key. Each secret is encrypted under it with its own random nonce.
  • The data key is itself encrypted (“wrapped”) by a key-encryption key held in a key service. The service unwraps on request and never hands the key-encryption key out, and logs every use. This is built and in use in LayerT’s test environment, where the shared accounts are practice-site accounts. Production, which will use Google Cloud’s key service, is not deployed.
  • 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.
Not zero-knowledge. LayerT’s servers can decrypt a shared account’s password. They have to, to sign someone in. The controls are about who can cause that and when, and every time is logged.

Who may use an account

ControlHow it works
AccessGranted to directory groups, roles or named people. Group membership comes from your directory over SCIM
SensitivityLow, medium or high. Medium and high need an approver before each use by default. Only IT can mark an account high
ApprovalRequests 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 timeOptional, per account. A second person sees who has it and until when
Session lengthPer account, 1 hour by default. Extending is possible up to 8 hours in total from approval

Signing someone in

  1. BrowserPickThe person picks the account from the LayerT icon in the field, or from the toolbar launcher.
  2. LayerT cloudCheckThe session must be active, belong to this person and this enrolled, approved browser, and the person must still be active and entitled.
  3. LayerT cloudDecryptOnly then is the password decrypted, in memory, and a grant returned over HTTPS.
  4. BrowserMatch the siteThe extension hands the grant over only if the page is one of the account’s exact sites. A form inside a frame must also pass the frame rule below.
  5. The pageFillThe extension fills the vendor’s own form from Chrome’s isolated world. LayerT never shows the password.
Every grant is logged with the person, the account and the device. The password and codes never appear in the log.

The exact-site rule

A shared account is tied to exact sites: scheme, host and port must match, with no wildcards. An account can list more than one site, each of them exact. 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.

Sign-in forms inside a frame

Some sites show their sign-in form in a frame that comes from another address of the same company, so the page itself has nothing to fill. LayerT finds the form there, offers the account in the page as usual, fills the frame, and says on the page which address the form belongs to. It fills a frame only when all of these hold:

  • the top page is an address the account names, matched exactly as above;
  • the frame belongs to the same site as that page, over https, and so does every frame between them;
  • the frame isn’t sandboxed; and
  • the frame is visible. A frame nobody can see is never filled.

A frame from an unrelated site is refused, and LayerT says why. An account can be set to exact addresses for frames too, for a login worth the extra set-up. LayerT never presses the sign-in button for a form in a frame.

When the account goes out through a gateway Early access

For an account with gateway routing switched on, the session comes first and the page second. LayerT starts the session, switches the account’s sites to its gateway, and only then loads the sign-in page. If the person picked the account on a sign-in page they opened themselves, LayerT doesn’t fill that page: it starts routing, clears the account’s cookies, loads the page again through the gateway and fills it there. The detail and the limits are on Sessions and recording.

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). Only the current six-digit code is sent to the browser, when it’s needed, and filled like a password. The audit log records that a code was used, never the code.

If a code doesn’t go in, the person holding the session can see the current code in the LayerT toolbar popup and copy it. Nobody else can, and views are logged.

The setup key (the TOTP seed) stays on LayerT’s servers. The only way to see it is a password request that two people approve, one of them an Owner or Compliance Officer. It’s shown once (see Password requests).

Codes sent by email

Some vendors email a code at sign-in, or when they don’t recognise the browser. If that email goes to a team address such as vendors@, an Owner or IT Admin can connect the mailbox to LayerT and link it to the shared accounts whose emails arrive there.

  • Read-only at the source. LayerT reads the mailbox over IMAP with a short list of read-only commands. It never marks mail as read, and never moves, deletes or sends anything.
  • Organisational addresses only. When connecting a mailbox, an Owner confirms it’s a shared or role address, not a person’s own mailbox, and the lawful basis for reading it.
  • Only the sign-in email, only during the session. A person with codes-only access sees just the sign-in emails for the account they’re signed in to, and only those that arrived during their session. A code usually reaches the popup two to three seconds after it arrives, and if the account’s sign-in steps wait for an email code, LayerT fills it in.
  • Resets go to the owner. Password-reset and account-change emails are never shown to codes-only access, even from the account’s own vendor. The account’s owner is told in the Inbox instead. An email that fails the sender checks is never shown.
  • Owners can teach it. Each account can have rules naming the senders of its codes. Until one exists, LayerT recognises sign-in emails by their wording, which is a best guess.

Reading the whole mailbox

Full access is a separate grant, and it works like a sensitive shared account: it needs approval by default, lasts 30 minutes by default, and shows in Sessions. The mailbox is shown read-only in the console, watermarked with the reader’s name. Every email opened is logged. Mail is shown with scripts, forms and remote content switched off, links go through a page that shows the real destination, and attachments are listed but can’t be downloaded unless your organisation allows it.

Built, and switched off in production. Shared mailboxes are built and tested against a stand-in mail server. They’re switched off in production until LayerT’s compliance review, because LayerT then keeps a copy of that mail. See Data handling.

Device trust

When a session ends, LayerT clears the site’s cookies, which signs the person out. That also clears the vendor’s “remember this device” cookie, so every sign-in can look like a new device. An account can name the cookies to keep. LayerT keeps the list only after a test sign-in proves it’s safe: after a simulated end of session, the sign-in page must appear again. If it doesn’t, the list is refused with “Keeping these cookies leaves the person signed in.”

Sign-in fields and notes

Some sites ask for more than a username and password, such as an account ID, an organisation ID or a PIN. An account can hold extra sign-in fields. A new field is secret by default: a secret field is sealed like the password and fills only into password-type boxes. A shown field, such as an AWS account ID, is visible to the people who can use the account. Extra fields are filled by the account’s sign-in recipe, never guessed.

Each account also has notes for what people need to know (“use the Singapore region”, “don’t tick remember me”), each with its author and edit history.

What the person can and can’t see

During a sign-in, 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. No rule reads a password or code that LayerT filled, whatever fields the rule names, so a rule’s record can’t hold it either. The one exception is a password request, below.

The honest limit. To sign in, the password has to go into the vendor’s own password field, as it would with any password manager. A determined person with DevTools could read it from that field. LayerT’s protection here is governance: approval, time limits, an audit trail, and access that ends on time and at offboarding.
Required setting. Switch off Chrome’s built-in password manager by policy, so Chrome can’t offer to save a shared password into someone’s profile. LayerT’s deployment templates include that setting.

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.
Signing out clears the whole site. Signing out clears every cookie for that site, including the person’s own separate session there, if they had one. The only exception is a device-trust cookie the account keeps (see Device trust). When the site shares cookies with other services on a parent domain, LayerT says once, before the first sign-in, that it will sign them out of those too.

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.
  • Other sites. An account can list the other sites it uses, such as a separate sign-in address, one exact address per line.
  • Signed recipes. Every recipe is signature-checked before it runs. If the check fails, LayerT falls back to automatic detection, never submits the form, and reports why.
  • LayerT’s own recipes. For some sites LayerT brings its own signed recipe, and the account’s Sign-in tab says which recipe is used. They were tested against fictional vendor sites and stand-ins.
  • Sign-in health. The console shows, per site and account, which sign-ins worked and where the others stopped, in words, over the last 7, 30 or 90 days.
  • Importing. An admin can import accounts from a JumpCloud Password Manager export. The file is read in the admin’s browser; the preview never shows a password, and the accounts it creates are then sealed on LayerT’s servers like any other. Every import is logged.

Password requests

Sometimes a person really needs to see a password, a setup key or a secret field: to hand it to a vendor’s support team, or to set up a new device.

  1. ConsoleAskThe person asks, with a reason. Owners and IT Admins can ask about any account; anyone else only about accounts they may use or own.
  2. ConsoleTwo approvalsTwo people other than the requester approve. One of them must be an Owner or Compliance Officer. These requests can’t be decided in Slack or by email.
  3. ConsoleView onceWithin an hour, the requester signs in again if their last sign-in was more than 10 minutes ago, and sees the value once. A second view is refused.
  4. LayerT cloudMarked as seenThe value is marked as seen. Owners, Compliance Officers and the account’s owner are alerted, and the owner is asked to change it at the vendor.
Every step is in the audit log. The value itself never is.

Break-glass export

An offline export for disaster recovery is encrypted, and needs two custodians to open, each with their own passphrase. Generating one is logged.

Limits

  • LayerT never presses the sign-in button for a form inside a frame: it fills, and the person submits. A frame from an unrelated site, a sandboxed frame and a frame nobody can see are refused.
  • Forms drawn on canvas, or inside a site’s closed shadow roots, aren’t supported.
  • LayerT doesn’t rotate passwords automatically yet.
  • Codes sent by text message or push approval aren’t handled. Codes sent by email are, when the address is a connected shared mailbox.
  • Password requests send an alert as soon as the value is seen. Exports don’t send alerts yet Proposed; they’re in the audit log.