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 people’s lists are assembled into one document for the whole organisation.
- 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, in order | Refuses |
|---|---|
| Version | Anything not newer than what it already has, so an old policy can’t be replayed |
| Organisation | A policy for any organisation but its own |
| Key | Anything signed by a key the extension doesn’t know |
| Signature | Anything that doesn’t verify against the public key built into the extension |
| Expiry | A policy past its expiry time, by the laptop’s clock |
A refused policy is thrown away, and the browser keeps the one it had. Several public keys can be built in at once, so the signing key can be rotated without a gap. The signing key is held in a key service and can’t be exported: LayerT’s servers ask the service for each signature. The key is software-protected. The service offers this type of key (Ed25519) in software only, so it isn’t held in a hardware security module. This is built and in use in LayerT’s test environment. Production, which will hold the key in Google Cloud KMS, is not deployed. Development builds sign with a local key that production builds of the extension don’t trust.
What a rule can act on
Rules began with sign-ins: a rule names a field, and LayerT checks what is typed there when a form is submitted, or what is pasted into a single-line text box.
Rules can also act on text typed into a field, and on a file given to a page through a file box, a drop or a paste, judged by its name or by the text inside a plain-text file of up to 1 MB. A file that a blocking rule matches never reaches the page.
One part of that follows the same principle as the rest of this paper. A rule about a file’s text also stops a file LayerT can’t read, such as an image, a PDF or an Office document, and says it couldn’t check it. An input LayerT can’t judge is stopped, not waved through.
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.
Warn and monitor rules keep working. When the browser reconnects and gets a fresh policy, the card clears by itself within about 30 seconds, without a reload.
The same card stops a file given to a file rule’s fields, and Enter in a field a typing rule watches, without reading anything.
Two newer features fail closed in the same way.
Rules for a directory group. A rule can apply to the people in a directory group, or to everyone outside one. Each browser gets a signed answer about its own person’s groups, valid for 24 hours. A browser that doesn’t hold a current answer stops the action on pages where a blocking rule names a group, as it does when its policy is out of date.
Continuing with a reason. A form or paste rule can let people continue past a block by giving a reason. LayerT lets the action through only after the server has recorded the reason. Offline, or when LayerT can’t be reached, it stays blocked and the card keeps what was typed.
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 send a browser a forged 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. The stop is marked urgent inside the policy, but today the extension doesn’t fetch it any faster than other changes.
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. A file that a blocking rule matches is stopped the same way, before the page’s own handlers see it. Typed text is different: it’s in the page from the first keystroke, so a typing rule stops it being sent with a form, a submit button or Enter, and can’t take it back from a page that sends as you type. 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, warning, monitor match and use of an exception is logged with the rule, the page’s address, the field, the matched value and the person. When a rule matches, LayerT records what matched, and for a typing rule the text of the field, so an auditor can check the decision. A rule can mask or hide its values.
- Values are readable by default, so an auditor can confirm that what was blocked really was a personal account. The browser always sends the value, and a rule’s setting to mask or hide it is applied on the server before anything is stored.
- A typing rule keeps the whole field as it was when the rule matched, up to 10,000 characters, not only the part that matched.
- A file rule keeps the file’s name, type and size, and whether LayerT could read it. A file’s text is read in the browser and never leaves it.
- A reason given to continue past a block is kept with the match, in the person’s own words.
- No rule reads a password or code LayerT filled, so a shared account’s password can’t reach a rule’s record. A typing rule never reads a password box or a one-time-code box at all.
- A form or paste rule reads the fields it names, and that can include a password box a person typed into themselves. Such a value is recorded readable unless the rule is set to mask or hide its values.
Audit events are kept for 365 days by default.
What’s in a bundle, and what a compromised laptop can do
The signed policy a browser receives is called a policy bundle. It’s one JSON document for the whole organisation: every rule, the lists rules refer to, the emergency-stop setting, the revoked-browser list and every live approved exception. It never contains shared-account passwords, authenticator codes, device credentials or signing keys. Those travel separately, one sign-in at a time, and stay in memory.
Two honest consequences follow from that design.
Every laptop holds the whole organisation’s bundle. Today each browser receives the same bundle, so each laptop with an approved browser holds other people’s allowlists, and every live exception with the value that was approved, who approved it and the reason given. Group memberships no longer travel in the bundle: each browser gets a signed answer about its own person’s groups, and learns nobody else’s. Bundles scoped to one person are part of LayerT’s design but aren’t built. Treat the bundle as internal company data.
The signature protects the bundle in transit, not at rest. The browser checks a bundle once, when it arrives, then saves it as plain JSON in the browser profile and enforces what it saved. At rest, only the laptop’s disk encryption protects it. So:
| Who | What they can do |
|---|---|
| A web page | Nothing to the bundle. It can’t read the extension’s storage or send the extension messages |
| Someone on the network | Delay updates for up to 7 days, after which blocking rules fail closed. They can’t forge, alter or replay a bundle |
| The person, or software running as them | Read the whole bundle. Software that can write to the profile’s extension storage can change it and switch enforcement off |
| An administrator, or malware with admin rights | Defeat LayerT on that laptop: edit storage, remove policies, replace the extension or change the clock |
| Someone holding a locked laptop with disk encryption | Nothing in the profile. Revoke the browser anyway |
No control that runs inside a browser can stand up to an administrator on the same laptop, and LayerT doesn’t claim to. It relies on the controls every managed fleet should have: full-disk encryption, no local administrator rights, LayerT force-installed through your MDM, extension developer tools and developer mode blocked, and a routine that revokes the browser, suspends the person and locks the laptop together. Revoking a browser cuts it off from LayerT and stops it enforcing. It doesn’t lock it.
A breach of LayerT’s own servers is different. An attacker who controls LayerT’s application could ask the key service to sign for as long as they held that access, and browsers would accept what they signed. They couldn’t copy the key out, every signing request is logged, and removing their access ends it. The full case-by-case analysis is on Policy bundles and device compromise.
Limits
- Rules act on form submissions, pastes, typed text and files given to a page. LayerT reads plain text only, and it isn’t a content scanner: it doesn’t look inside PDFs, Office files or images.
- 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. It tells the person and stops the text being sent with a form, a submit button or Enter.
- Continuing with a reason, and rules for a directory group, depend on LayerT’s servers. Offline, a reason can’t be recorded, and a browser keeps its last answer about its person’s groups for up to 24 hours.
- An open page keeps the rules it loaded with until it’s reloaded or its address changes.
- The emergency stop and new rules reach a browser on its next sync, not instantly.
- A bundle is verified when it arrives, not each time it’s read. Someone who can write to the browser profile’s extension storage, or who has local administrator rights, can defeat enforcement on that laptop. Keep people off local admin.
- Every browser holds the whole organisation’s bundle, including other people’s approved exceptions.
- Expiry is judged by the laptop’s clock.
- The signed extension package that MDM force-installs is built and ships with LayerT’s first production release. It hasn’t yet been run on a managed machine. Force-install stops people switching LayerT off in Chrome’s settings. It doesn’t stop an administrator.
The best way to judge a fail-closed design is to try to break it. Bring your hardest questions to a demo, and we’ll show you what happens.