Architecture

Data handling

What LayerT keeps, where it keeps it, how long for, and what it never collects. Written so your privacy team can fill in their records without a call.

Describes LayerT as built on 3 October 2026. Anything not built is labelled.

What LayerT stores

Data	Where	Protected by	Kept for
People from your directory: name, email, job title, manager, active status	Postgres	Access controls; your directory is the source	While they’re in your directory; deactivated people are kept for the audit trail
Groups and memberships	Postgres	Access controls	As your directory says
Devices: each browser set up with LayerT, who it belongs to, the public half of its key, whether it’s waiting, approved or declined, when that was decided, and last seen	Postgres	Access controls. The private half of the key never leaves the browser	Revoked devices are removed after 90 days idle
Audit events: the rule, the page’s address, the field and the matched value. For a form rule the value is the text of the field, and for a paste rule the pasted text	Postgres	Access controls; readable by default. Each rule chooses what is kept of its values: as typed, partly masked, or nothing. The setting is applied on the server when the event arrives	365 days by default, configurable
Typed text a typing rule matched: the whole field as it was when the rule matched, up to 10,000 characters	Postgres, as the value of the audit event	The same as any matched value	With the audit log
Files a file rule matched: the file’s name, type and size, how it was given to the page, and whether LayerT could read it. Never the file’s text	Postgres, with the audit event	The same as any matched value	With the audit log
Reasons people give to continue past a block, in their own words	Postgres, with the audit event	Access controls. If the person typed the blocked value into their reason and the rule hides or masks values, it’s hidden or masked there too	With the audit log
Access requests: the value, the site, the person’s reason	Postgres	Access controls	180 days after they close, unless an active exception depends on them
Shared-account passwords, authenticator setup keys and secret sign-in fields	Postgres	AES-256-GCM envelope encryption, one data key per account	Until the account is deleted or the secret replaced
Shown sign-in fields (such as an account ID) and account notes, with each note’s edit history	Postgres	Access controls	Until the account is deleted
Shared-account sessions	Postgres	Access controls	180 days after they end
Gateways you add: name, region, host name, the addresses LayerT measured for it, and its health	Postgres	Access controls	Kept after a gateway is removed, for the audit trail
Routed sessions: which gateway a session went out through, and the address the vendor saw	Postgres	Access controls. The session’s gateway credential is stored only as a hash	With the session
Session recordings	Object storage	AES-256-GCM, a fresh key per recording, encrypted on the device	90 days by default, 7 to 365 configurable
Recording index: which session, which pages, timings	Postgres	Access controls	Deleted with the recording
Signed policy versions	Postgres	Ed25519 signature	The latest 20, plus anything from the last 30 days
Sign-in outcomes: whether a shared-account sign-in worked, and at which step it stopped. No values or page text	Postgres	Access controls	90 days
Device facts: extension version, how the browser says it was installed, browser, operating system	Postgres	Access controls	With the device
Notifications and their delivery records	Postgres	Access controls; they never carry a secret or a full value	30 days
Access reviews: who confirmed which person still needs which account, and the report	Postgres	Access controls; each report and CSV carries a SHA-256 checksum	7 years
Shared mailboxes you connect: the connection details and sign-in, and the Owner’s confirmation that it’s an organisational address	Postgres	Sign-in details use the same envelope encryption as shared-account passwords	Until the mailbox is removed
Copies of the mail in a connected shared mailbox	Object storage; sender, subject and date in Postgres	AES-256-GCM, one data key per mailbox. Codes and links LayerT extracts are encrypted too	30 days by default, at most 365. Deleted 7 days after the mailbox is disconnected
Who read which email in a shared mailbox, and who was shown which code	Postgres	Access controls	With the audit log

What your rules record

LayerT reads only the fields your rules name. 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.

Readable by default. The value a form or paste rule matched is sent to LayerT’s servers and kept readable, so an auditor can see what was stopped.
A typing rule keeps the whole field, not only the part that matched, up to 10,000 characters.
A file rule keeps the file’s name, type and size, how it was given to the page and whether LayerT read it. It never keeps the file’s text.
No rule reads a password or code LayerT filled. Whatever the trigger, a rule skips a password, a one-time code or a secret sign-in field that LayerT filled, so a shared account’s password can’t reach a rule’s record.
The user name LayerT fills is still judged. During a shared-account sign-in, a sign-in rule that covers the page still sees the user name LayerT filled. It lets the sign-in through and records that as an exception, with the user name.
A typing rule never reads a password box or a one-time-code box at all, nor a field LayerT filled.
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.
The setting is applied on the server. The browser always sends the value. Each rule’s choice (as typed, partly masked, or nothing) is applied on LayerT’s servers before anything is stored. Values aren’t redacted in the browser.
Page addresses are recorded only with an event: when a rule matches, when someone asks for an exception, and, without its query, when a shared-account sign-in is reported as working or not. No list of visited pages is kept or sent.
Events waiting to be sent are held in the browser. The extension’s storage can hold unsent events, including matched values, until they’re delivered.

A typing rule is monitoring. A typing rule on a chat box records what the person wrote around the match. Treat that as monitoring of your staff: tell your people what your rules record and assess it, as you would before switching on recording. LayerT asks for an Owner’s attestation before recording, and has no such step for rules, so that assessment is yours to make.

What never leaves the laptop

Anything typed into a field that no rule names, outside a recorded session. What a recording holds is on Sessions and recording.
The text inside a file. A rule about file text reads it in the browser to decide. It’s never sent and never stored.
The private half of the key each browser makes for itself.
Your people’s browsing history, the pages no rule covers and cookie values. LayerT doesn’t collect them.
The raw recording key, after it’s handed over once to be wrapped.
What people type into form fields and rich-text editors during a recorded session: it’s masked where they type it, before anything is encrypted. A recording still shows what the page shows back after it was typed, and the addresses of pages and requests.

What the extension receives

Every approved browser in your organisation receives your organisation’s signed policy. That policy includes the rules, and the approved exceptions and per-person settings that rules need, such as corporate phone numbers or approved personal accounts. Treat the policy as internal to your organisation.

Group memberships aren’t in the policy. Each browser also receives, separately, a signed answer naming its own person’s directory groups, valid for 24 hours. It never receives anyone else’s.

For a shared account that goes out through a gateway, the browser of the person in that session also receives which gateway to use, a credential for that session only, and the address the vendor will see.

Shared-account passwords, secret sign-in fields and authenticator codes are sent only to the enrolled browser of a person with an active session, only when needed to sign in, and never stored in the browser by LayerT.

There is one other way a secret leaves LayerT’s servers: a password request. Someone asks, with a reason, to see a password, an authenticator setup key or a secret field. Two other people must approve, and one of them must be an Owner or Compliance Officer. The person who asked then sees it once, in the console, after signing in again within the last 10 minutes. The value is marked as seen, and the account’s owner is asked to change it.

Deletion

People: deactivating someone in your directory ends their access at once. Their records stay for the audit trail until the retention period ends.
Your organisation: when an organisation closes, LayerT keeps its data for a 30-day grace period, then deletes everything in one step, including stored recordings, and records a receipt of the deletion.
Recordings and old records: deleted automatically by daily retention jobs, and each recording deletion is logged.
Shared-mailbox copies: deleted when they pass the mailbox’s retention window, and 7 days after a mailbox is disconnected.

Taking your data with you

An Owner can export the whole organisation as one zip file, including every kept recording, decrypted so it can be watched outside LayerT. A manifest lists a SHA-256 checksum for every file. The export never includes passwords, authenticator setup keys or secret fields, and making one is written to the audit log.

The audit log itself can be exported as CSV or JSON Lines by Owners, IT Admins, Compliance Officers and Auditors. Typed values are left out unless the person ticks a box to include them.

Sub-processors and location

LayerT will run on two infrastructure providers. Each one processes your data only on LayerT’s instructions, under a data processing agreement.

Provider	Contracting entity	Planned use
Google Cloud	Google Cloud EMEA Limited (Ireland)	The console, API and worker, the database, recording storage, logs and the key service. Region: Milan (`europe-west8`). Keys and database backups: Google’s EU multi-region
Cloudflare	Cloudflare, Inc. (United States)	DNS for layert.net, and sending notification email

If your organisation connects Slack, approvers’ notifications go through your own Slack workspace, under your agreement with Slack. Your identity provider and MDM are yours too, so they aren’t LayerT’s sub-processors.

Before launch. LayerT isn’t in production yet, so this is the planned set-up, not a running one. Today LayerT runs in a test environment that holds dummy data only. The final sub-processor list (including any fallback email provider), the safeguards for any transfer outside the EU, and data residency options will be published here before the first customer goes live.

If you’re filling in a record of processing

Purpose: controlling which accounts people sign in to on work devices, applying your rules to forms, pastes, typed text and files given to a page, brokering access to shared accounts, and keeping an audit trail of all three.
Data subjects: your employees and contractors whose browsers are set up with LayerT.
Special categories: LayerT doesn’t set out to process them. A rule’s record holds what the rule matched, so what it contains depends on the rules you write, and a typing rule keeps the whole field. A recording can capture whatever a vendor’s page shows, which is why recording needs the Owner’s attestation first.
Legal basis: yours to determine. LayerT asks the Owner to record it before any recording can happen.