LayerT whitepaper
Fail-closed by design
A control that works in the browser has an obvious weakness: the browser is on the employee’s laptop. If the laptop can quietly stop receiving policy, or accept a policy it shouldn’t, the control becomes a suggestion. This paper describes how LayerT closes those gaps with signed policy and a fail-closed default, and what that looks like to the person at the keyboard.
Why enforce in the browser at all
Network security tools see encrypted traffic to a website. They can’t see what was typed into a sign-in form, or whose account it was. By the time a request reaches the network, a personal sign-in on a work laptop looks identical to a work one.
LayerT runs where the typing happens. Its content script sees the value in the field, compares it with your rules, and acts before the site’s own code sends the request. That position is the product’s advantage, and it’s also why the policy it enforces has to be trustworthy.
One policy, one signature
Admins write rules in the console as drafts. Publishing turns every pending draft into one new version of your organisation’s policy. Version numbers only go up, and each publish takes the next number under a lock, so two admins can’t produce the same version.
- ConsoleDraftsRules, list changes and exception revocations are staged. Optional two-author review.
- LayerT cloudCompileRules, approved exceptions and per-person settings are assembled into one document.
- LayerT cloudSignCanonical JSON (sorted keys, signature excluded) signed with Ed25519.
- BrowserVerifyChecked with Web Crypto against keys built into the extension.
The signed document carries the organisation it belongs to, its version, when it was issued and when it expires. Rolling back doesn’t rewind history. It publishes the old rules as a new, higher version, keeping any exceptions approved since.
What the browser checks
The extension fetches policy every 15 minutes, at start-up and after navigation, using conditional requests so an unchanged policy costs almost nothing. Before it uses a policy, it verifies:
| Check | Refuses |
|---|---|
| Signature | Anything that doesn’t verify against a public key built into the extension |
| Key | Anything signed by a key the extension doesn’t know |
| Organisation | A policy for any organisation but its own |
| Version | Anything not newer than what it already has, so an old policy can’t be replayed |
| Expiry | A policy past its expiry time |
Several public keys can be built in at once, so the signing key can be rotated without a gap. The signing key is held on LayerT’s servers today and is moving into a managed cloud key service Coming soon.
Failing closed
Every policy expires 7 days after it’s issued. LayerT re-signs it automatically 48 hours before that, so a connected browser never sees an expired policy. Only a browser that has been unable to reach LayerT for days will.
When it does, LayerT doesn’t fall back to “allow”. On any page covered by a block or force sign-out rule, it stops form submissions and pastes into the rule’s fields, and shows a card that explains why:
Connectivity required. LayerT couldn’t update this browser’s policy, so it can’t check this action. Connect to your network, then try again.
Monitor rules keep logging. When the browser reconnects and gets a fresh policy, the card clears by itself within about 30 seconds, without a reload.
We chose to fail closed only where a blocking rule applies, not across the whole web. A stale policy on a laptop stops the risky sign-in. It doesn’t stop the person reading the news.
The emergency stop
Sometimes you need enforcement off, everywhere, now: a rule is wrong and it’s blocking the sales team. The Owner can pull an emergency stop. The stop is itself a signed policy version, so nobody can forge one to switch LayerT off. It’s logged, and browsers pick it up on their next sync: within 15 minutes, sooner if the person navigates.
Exceptions without backdoors
A rule can let blocked people ask for access. An approver picks how long: a single attempt (a five-minute window), 15 minutes, or 1, 8 or 24 hours. Permanent exceptions can be granted only by the Compliance Officer or the Owner, never by IT, so the people who write the rules aren’t the people who grant standing exceptions to them.
An approval becomes part of a newly signed policy, in one atomic step, so an exception is exactly as trustworthy as the rule it relaxes. Nobody can approve their own request. The server refuses. Requests that nobody decides expire.
Enforcement a page can’t talk its way out of
LayerT acts on form submissions and pastes before the site’s own handlers run, and cancels them when a rule matches, so the site’s request never leaves. The prompts that explain a block are built to resist the page they’re drawn on:
- closed shadow roots the page’s scripts can’t reach,
- buttons that respond only to real clicks and key presses,
- no password fields, ever, and a footer that says LayerT never asks for one,
- an amber dot on LayerT’s own toolbar icon that the page can’t draw.
What gets recorded
Every block, monitor match and use of an exception is logged with the site, the field, the matched value and the person. Values are readable on purpose, so an auditor can confirm that what was blocked really was a personal account. Audit events are kept for 365 days by default.
Limits
- LayerT evaluates form submissions and pastes into the fields a rule names. It isn’t general data-loss prevention.
- A “warn” rule currently stops the action like a block. A warning that lets the person continue is being built Coming soon.
- The emergency stop and new rules reach a browser on its next sync, not instantly.
- Until LayerT ships a signed extension package for force-install Coming soon, someone with local administrator rights could remove the extension. Keep people off local admin.
The best way to judge a fail-closed design is to try to break it. Ask us for a sandbox in your demo.