How GL protects the data that passes through it, and what's still on the roadmap. ← Back to G-Layer
G-Layer (GL) is a governance layer that sits between the people at an organisation and an underlying AI model. Every request goes through GL first, not directly to the model. That is what lets the controls below be enforced consistently, rather than relying on each person to follow a policy by hand. This page describes what's actually built and turned on today, not a marketing summary of intent.
Client sites are gated by Cloudflare Access at the network edge: a real login (organisational email address) is required before a request ever reaches GL's own code, for any site configured to require it. There is no anonymous or shared-password access to a live client deployment; each user is named individually on an allow-list, and access can be revoked per person without touching anyone else's.
API keys and shared secrets (the model provider key, database credentials, inter-service tokens) are stored as encrypted secrets on the server side (Cloudflare Worker secrets), set directly by an administrator and never embedded in, or served to, the browser. A person using GL never has visibility into any credential GL itself uses.
GL can scan content, including uploaded files, before it reaches the model, and redact categories such as card numbers, IBANs, National Insurance numbers, NHS numbers, email addresses, and API keys. This has been tested against real fixtures, including a password-encrypted PDF and a corrupted file, and it fails closed: if a file can't be reliably scanned, it's blocked rather than silently passed through unmasked.
Where a client connects GL to their own database, that connection is read-only at the database user level, reaches GL only through an authenticated tunnel, and is restricted to an explicit allow-list of tables. Individual columns can additionally be blocked outright: names, addresses, phone numbers, card details, authentication tokens, and similar fields can be excluded so that no query, however phrased, can surface them.
Each client's GL instance is configured independently: which users can sign in, which tools and file types are allowed, which web domains (if any) can be reached, and a hard monthly spend cap enforced server-side. Nothing is shared across clients by default, and one client's configuration change does not affect another's.
Conversation activity logging is off by default and only enabled where a client explicitly asks for it and understands the implications for staff privacy under GDPR. It is not a standing default across every deployment.
A standing design rule for GL: a failure must never be silently reported as a success. If GL can't verify that a file, an answer, or an action actually happened the way it claims to, that gets surfaced honestly rather than passed through. The same principle applies to a security control: fail closed, not open.
GL runs entirely on Cloudflare's network (Workers, Pages, D1, KV, Hyperdrive), with HTTPS/TLS enforced throughout. Cloudflare's own infrastructure holds SOC 2 Type II and ISO 27001 certification. GL inherits that infrastructure-level assurance the same way most software built on a major cloud provider does; see Cloudflare's own compliance documentation linked above for the current scope of that certification.
If you believe you've found a vulnerability in GL, please report it via the contact in /.well-known/security.txt rather than a public channel, so it can be addressed before disclosure.