架构
LayerT 是如何构建的
本文面向需要判断 LayerT 是否可靠的工程师和安全评审人员。它说明产品做什么、如何做，以及边界在哪里。
本文描述截至 2026年9月19日 已实现的 LayerT。尚未实现的内容均已标注。
LayerT 由两部分组成。浏览器扩展程序运行在贵公司已在管理的 Chrome 配置文件中。控制台和 API 是管理员、审批人和合规人员做出决定的地方。两者之间只通过 HTTPS 通信。您的网络路径中没有代理，操作系统上没有代理程序，也不需要新的浏览器。
我们遵循的五条构建原则
LayerT 的工程工作遵循一份成文的“宪章”。每一份规格说明和每一次变更都要对照它进行检查。
- 故障时默认阻止（fail-closed）。 如果 LayerT 无法证明其策略是最新且真实的，它就会阻止该策略所涵盖的操作。它绝不会悄悄放行。
- 将配置规则的人与授予例外的人分开。 IT 编写规则，合规部门授予长期例外。任何人都不能审批自己的请求。
- 对浏览器信任的内容进行签名；保持审计记录可读。 策略使用 Ed25519 签名，并在浏览器中校验。审计日志以通俗的文字保存，审计人员可以直接阅读。
- 使用真实的协议。 目录使用 SCIM 2.0，登录使用 OpenID Connect，验证器代码使用 RFC 6238，签名使用 Web Crypto。测试替换的是数据源，而不是协议。
- 只有真实浏览器验证通过，功能才算完成。 每个流程都有测试场景，在加载了真实扩展程序的真实 Chromium 中运行。
各部分运行在哪里
| 部分 | 运行位置 | 作用 |
|---|---|---|
| Service Worker | 扩展程序内，在 Chrome 中 | 注册、设备凭据、策略同步与签名校验、审计批量上报、共享账号授权 |
| 内容脚本 | 每个页面，在 Chrome 的隔离环境（isolated world）中 | 只监视您的规则指定的字段；填写共享账号登录信息；绘制 LayerT 的提示 |
| 页内提示 | 页面上的封闭 Shadow Root | 阻止卡片、账号菜单、通知和会话标签。页面无法读取或点击它们 |
| 控制台和 API | LayerT 云端 | 规则、共享账号、收件箱、会话、审计日志、SCIM 和登录 |
| Postgres | LayerT 云端 | 策略版本、审计事件、目录数据、以密文形式保存的共享账号密钥 |
| 对象存储 | LayerT 云端 | 会话录制，在设备上加密后再上传 |
| 定时任务 | LayerT 云端，一个独立的 worker 服务 | 使过期的请求和会话失效、执行保留期限、在策略过期前重新签名、发送通知、发送访问审查提醒 |
详细内容见组件与数据流。
LayerT 的服务器能看到什么
安全评审应当事先了解这一点：LayerT 不是零知识（zero-knowledge）系统。 为了让某人登录共享账号，LayerT 的服务器会为一次已批准、有时限的会话解密该账号的密码，并将其发送到此人已注册的浏览器。为了回放录制，服务器会为有权观看的人解密录制内容。当所有者导出整个组织的数据时，服务器会将保留的录制解密到该导出中。密码或验证器设置密钥也可以向某人显示一次，但必须先由另外两个人批准该请求。上述每一项操作都会依据角色进行检查、绑定到具体的人，并写入审计日志。
为什么这样设计. LayerT 代理的是访问：它决定谁可以使用某个账号、何时使用、使用多久，并按时结束。一个只有最终用户才能打开的保险库无法执行其中任何一项。我们选择了治理，而不是对最终用户保密，并且我们明确说明这一点。阅读关于访问代理的白皮书。
目前的进展
LayerT 尚未正式发布。除非带有标签，这些页面上的所有内容均已在开发环境中构建并测试：
- 默认关闭 已构建，但需要公司自行开启（录制、水印、自动提交、双人审阅）
- 抢先体验 已构建，但尚未获准用于生产环境（网关路由，以及部署在您自己服务器上的网关）
- 即将推出 尚未构建或尚未完成（Edge、Firefox 和 Opera；共享邮箱和电子邮件登录验证码）
- 提议中 已设计，尚未构建
有两个已构建的部分等待的是首次生产部署，而不是更多开发工作：由 Google Cloud 密钥服务保管的密钥，以及通过签名扩展程序包进行强制安装。开发环境中以本地密钥代替，因此我们将它们描述为“已构建，上线时开启”。
目前还没有客户或生产部署，LayerT 也未持有任何认证。