Architecture
Signed policy and enforcement
Rules are written in the console, published as one signed version, verified by every browser, and enforced in the page before a form is sent. If a browser can’t prove its policy is current, it fails closed.
Describes LayerT as built on 18 September 2026. Anything not built is labelled.
The life of a policy
- ConsoleDraftIT writes or changes rules as drafts. Nothing reaches a browser yet.
- ConsolePublishPublishing applies every pending draft as one new version. Optional two-author review stops people publishing their own drafts.
- LayerT cloudSignThe version is serialised as canonical JSON and signed with Ed25519.
- BrowserFetchEvery 15 minutes, at start-up and after navigation, with conditional requests.
- BrowserVerifySignature, key, organisation, version and expiry are all checked before a single rule is used.
- The pageEnforceRules act on form submissions and pastes before the site’s own code runs.
What a rule is
A rule says where it applies, which fields it watches, what value triggers it and what happens.
| Part | Options |
|---|---|
| Where | A site pattern: exact URL, a glob such as https://*.postbox.example/*, or a regular expression |
| Which fields | CSS selectors for the fields on that page. Admins can build them by pointing at the page with the extension’s picker |
| What value | Conditions on the typed value: equals, matches a pattern, email domain, in a list, and combinations with and/or/not. Conditions can also compare against the person’s own directory identity, such as “only their own work address” |
| What happens | Monitor (log only), block, block with a request (the person can ask for access), or force sign-out (clears the site’s cookies and storage, then shows a signed-out page) |
Today LayerT evaluates form submissions (the submit event, submit buttons and Enter in a field) and pastes into watched fields. Built-in rules cover personal Google sign-ins, Telegram Web and WhatsApp Web.
Signing
Each published version is serialised deterministically (keys sorted, signature fields excluded) and signed with Ed25519. The policy carries a version number, the organisation it belongs to, when it was issued and when it expires.
- Versions only go up. Each publish takes the next number for your organisation under a lock, so two admins can’t publish the same version.
- Rolling back publishes the old rules as a new, higher version. Approved exceptions made since then are kept.
- The signing key is held by LayerT’s servers today. Moving it into a managed cloud key service is in progress Coming soon.
Verification in the browser
The extension checks every policy with the browser’s own Web Crypto implementation before using it. It refuses a policy if:
- the signature doesn’t verify against a public key built into the extension,
- it was signed with a key the extension doesn’t know,
- its version isn’t newer than the one it already has,
- it belongs to a different organisation, or
- it has expired.
Several public keys can be built in at once, so a signing key can be rotated without a gap.
Failing closed
A browser that can’t get a current, genuine policy doesn’t quietly stop enforcing it.
- Policy expires 7 days after it’s issued, and LayerT re-signs it automatically 48 hours before that. A browser only sees an expired policy if it has been unable to reach LayerT for days.
- On a page covered by a block or force sign-out rule, an expired policy stops every form submission and every paste into the rule’s fields, with a “Connectivity required” card. It explains what happened and offers only Back.
- Monitor rules keep logging.
- When the browser reconnects, the card clears by itself within about 30 seconds, without a reload.
The emergency stop
The Owner can switch all enforcement off for the whole organisation. The stop is itself a signed policy version, so a browser can’t be tricked into it. It’s logged. Browsers pick it up on their next sync: within 15 minutes, sooner if the person navigates.
Enforcing in the page
LayerT’s content script listens for submissions and pastes before the site’s own code sees them. When a rule matches, LayerT cancels the event, so the site’s request is never sent. The end-to-end tests check that it isn’t.
LayerT’s prompts are built so that a page can’t interfere with them:
- They’re drawn in closed shadow roots, which the page’s scripts can’t reach.
- Their buttons respond only to real clicks and key presses, not to events a script creates.
- They never show the rule’s internal name. They show the message the admin wrote.
- They never ask for a password, and never contain a password field. A test checks every prompt.
- While a prompt is on the page, the LayerT toolbar icon shows an amber dot that the page can’t forge.
Asking for access
A blocked person can ask for access, if the rule allows it.
- BrowserAskThe person explains why. The request has a deadline, 30 minutes by default.
- Console or popupDecideAn approver chooses: a single attempt (five minutes), 15 minutes, 1, 8 or 24 hours, or permanent.
- LayerT cloudApplyThe approval becomes an exception in a newly signed policy, in one atomic step.
- BrowserRetryThe prompt updates by itself. If the person left, a desktop notification tells them.
- Nobody can approve their own request. The server refuses it.
- Permanent exceptions can be granted only by the Compliance Officer or the Owner, never by IT.
- A request that nobody decides expires automatically.
- Email alerts to approvers aren’t built yet Coming soon. Requests arrive in the console Inbox and in the extension.
What gets logged
Each block, monitor match and use of an exception creates an audit event with the site, the field, the matched value and the person. Values are kept readable on purpose, so an auditor can see that the blocked sign-in was a personal address. Audit events are kept for 365 days by default, and each organisation can change that.