Why We Don't Use Cloudflare — And Why It Matters for Your Firm | Insights

Cloudflare is the most widely deployed content delivery and access control network in the world. Millions of organisations use Cloudflare Zero Trust Network Access (ZTNA) to secure remote access to internal applications. It is technically excellent. It solves real security problems. For many use cases, it is the right tool.

Private AI Ltd used it. We built our first deployment architecture around Cloudflare ZTNA. We then deliberately moved away from it — and replaced it with a client-controlled sovereign access layer. This article explains the architectural and compliance reasoning behind that decision. It matters for your firm’s data sovereignty posture.

Note: this article explains how Cloudflare ZTNA works as a general access technology. Private AI Ltd does not use Cloudflare or ZTNA in client deployments. Our architecture uses a direct gateway model with no third-party authentication, access gateway, or network transit provider in the access path — see The Standing DPA and Zero-Egress AI Explained for how our architecture differs.

The Problem With Cloudflare: A Third Party in the Access Path

Cloudflare ZTNA works by routing all traffic through Cloudflare’s edge network. When a user accesses your private AI environment, their request hits Cloudflare’s servers first. Cloudflare authenticates the user, evaluates the access policy, and routes the request through to your server. The response travels back through the same path.

This is elegant engineering. But it has a structural consequence: Cloudflare is in the access path.

Cloudflare processes access metadata for every session: source IP, authenticated identity, timestamp, application accessed, session duration. Under UK GDPR, this makes Cloudflare a Data Processor for access transit. The firm must execute a DPA with Cloudflare. Because Cloudflare is a US entity, that DPA requires a UK Addendum to EU Standard Contractual Clauses — an international transfer mechanism.

This is not a paperwork exercise. The US CLOUD Act gives US law enforcement the power to compel US entities to disclose data — including metadata — held on their systems, regardless of where that data is physically stored. Cloudflare’s infrastructure is operated by a US corporation. US legal process can reach Cloudflare’s access logs for your firm’s sessions. That access log contains your users’ identities, session timestamps, and access patterns — correlated to your sovereign AI environment.

For a Scottish law firm processing client-privileged information through AI, that is a jurisdictional exposure that did not need to exist.

The Compliance Consequence: An Extra Processor at the Access Layer

Every regulated firm that deployed our architecture under the Cloudflare model had the same processor map at the access layer:

A UK bare-metal infrastructure provider — Direct Data Processor (UK entity, domestic DPA, no international transfer)
Cloudflare — Direct Data Processor (US entity, DPA required, UK Addendum to EU SCCs)

The AI environment itself was pristine. No AI vendor processed your data. The inference was local. The documents stayed on-server. But Cloudflare sat at the front door, logging who entered and when.

The compliance question: is it acceptable to have a US company holding access metadata for sessions into your firm’s sovereign AI environment? For some firms, the answer is yes — Cloudflare’s DPA is well-drafted, their data practices are documented, and the access metadata itself is not client-privileged data.

But the more principled question is: does Cloudflare need to be there at all? Is there an architecture that delivers the same access security with no third party in the path — not even at the metadata level?

There is.

The Alternative: A Client-Owned Gateway

The sovereign access layer that replaced Cloudflare in our architecture is architecturally simpler, jurisdictionally cleaner, and actually more aligned with the firm’s control model.

Instead of routing traffic through Cloudflare’s edge, the firm provisions a secure access layer — a server on their own account. The AI environment establishes an encrypted, authenticated connection into the environment. User traffic arrives at the access layer, authenticates via single sign-on with two-factor authentication, hosted inside the environment, and is routed through.

The result:

No third-party access path. The gateway is the firm’s own server on the firm’s own account. No traffic transits Cloudflare’s infrastructure. No access metadata is generated on any US company’s systems.
No additional DPA. The gateway is infrastructure, not a processor. It handles routing, not identity processing. No Article 28 DPA is required for the access layer.
No UK Addendum to EU SCCs. No international transfer occurs at the access layer. The gateway can be provisioned within UK/EEA jurisdiction.
Client-controlled kill switch. The firm’s IT Lead can shut down the gateway instantly. Access to the AI environment stops. No third party is involved in that decision.

The access logs live on the AI server itself — in the firm’s own contracted infrastructure. The ICO, should it ever need them, receives them from the firm directly. No third party holds them.

What We Kept From the ZTNA Model

Moving away from Cloudflare did not mean abandoning the security properties that made ZTNA valuable. The sovereign access layer preserves all of them:

Zero exposed ports on the AI server. The AI server still has no public IP and no listening ports. The tunnel is outbound-only. From any external scanner, the AI server remains invisible.

MFA on every session. Self-hosted two-factor authentication is enforced before any session is established. The implementation is identical in effect to Cloudflare Access — the policy enforcement simply runs on infrastructure the firm controls.

Immutable access audit trail. Every session is logged: identity, timestamp, source, duration. The log is stored locally on the client’s own infrastructure. It is tamper-evident, queryable, and producible to the ICO without any vendor’s cooperation.

Network-level egress control. Unchanged. The environment remains sealed with no outbound path for data to take. The only permitted connection is the authenticated link into the firm’s own secure access layer. Data cannot leave through any other path.

The security posture is equivalent. The compliance posture is materially stronger.

The Managing Partner’s Summary

The practical translation of this architectural change:

With Cloudflare ZTNA: Your firm’s AI environment was secured by an excellent, market-leading product operated by a US corporation. Cloudflare held your access metadata. Cloudflare was a Data Processor. A US judge could, in principle, compel Cloudflare to disclose who accessed your AI system and when.

With a self-hosted access layer: Your firm’s AI environment is secured by infrastructure your firm controls directly. No third party holds your access metadata. No US entity is in the access path. The only Data Processor at the infrastructure layer is a UK bare-metal infrastructure provider — contracted by you, on UK soil, under a direct domestic data-processing agreement.

The difference is: no third party in the access path. It is the architectural property that makes the sovereignty guarantee complete rather than merely partial.

Talk to our team to review the full sovereign access architecture and evaluate whether this model is the right posture for your compliance obligations.

Private AI Ltd (SC881079) acts as a Standing Data Processor under Article 4(8) UK GDPR, operating a Zero Standing Privileges architecture. We deploy sovereign, zero-egress AI environments for regulated professional services. In the Default Operating State, we hold no active connection and no credentials to client systems.