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 has a written incident response plan (severity levels, response targets, and how affected clients are communicated with) and a written vulnerability management process (how dependency and application vulnerabilities are found, prioritised, and fixed, including a real, dated dependency scan result). Both are early but genuine, not placeholders: they describe what GL actually does today, and each is reviewed at least annually.
OWASP does not certify or badge products, including against this list ("OWASP...does not currently certify any vendors, verifiers or software," per ASVS documentation), so this is not a claim of OWASP endorsement, just an honest, specific mapping of GL's real controls against the risk categories OWASP publishes for LLM applications specifically, since GL is one. General web-application risks (broken access control, credential handling, and similar) are covered by the Access control, Secrets, and Database access sections above instead; this table is about the AI-specific risks. See OWASP's own LLM Top 10 project for the current, versioned list.
| Risk | How GL addresses it today |
|---|---|
| Sensitive information disclosure | PII masking scans content, including uploaded files, before it reaches the model and redacts card numbers, IBANs, National Insurance numbers, NHS numbers, emails, and API keys, failing closed on anything it can't reliably scan. |
| Excessive agency | Every tool, file type, database table/column, and web domain a site's AI can use is an explicit allow-list, never a default. Database access is enforced read-only twice (application and database engine), and a hard monthly spend cap limits the damage even if something else goes wrong. |
| Insecure plugin/tool design | Each connector (Drive, MySQL, Magento) is individually enabled per site and authenticated with its own shared secret. A connector not explicitly turned on for a site simply doesn't exist for that site's model to call. |
| Model denial of service | A hard monthly spend cap per client, enforced server-side, limits the cost impact of runaway or abusive usage. |
| Overreliance | GL's own "never silently report a failure as a success" rule (see Reliability above) means a person is never left trusting an answer or a generated file that didn't actually happen the way it claims to. |
| Prompt injection | Not something GL claims to prevent at the model level. Instead it limits the blast radius: even a successfully manipulated response can only reach whatever tools, data, and domains are already allow-listed for that site. |
| Training data poisoning | Not applicable: GL uses hosted, pre-trained models (Anthropic, OpenAI) and never trains or fine-tunes on client data. |
| Model theft | Not applicable: GL doesn't host model weights; it calls providers' hosted APIs. |
| Insecure output handling | Not yet a formal, named control on its own. |
| Supply chain vulnerabilities | Not yet formally assessed. |
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.