SYSTEM Cited by 2 sources

Cloudflare Zero Trust Access

Zero Trust Access is Cloudflare's identity- aware application-proxy tier: it sits in front of an origin application (Worker, container, or on-prem service) and enforces declarative access policies + login methods on every request before traffic ever reaches the origin.

Mechanics

• The admin defines policies (who can access) and login methods (Okta / Google Workspace / OIDC / SAML etc.) for each application.
• On success, Access signs a JWT and includes it in the request to the origin.
• The origin application validates the JWT to guard against any client that tries to bypass Access and hit the origin directly.
• Access-fronted applications get observability (who accessed what, when) and audit trail for free.

Canonical role in Developer-Platform architectures

A consistent shape on Cloudflare's own reference architectures is Access as the universal front door: every entrypoint Worker sits behind Access, which means individual applications never have to build application-level auth — declarative policy + JWT validation covers it.

Seen in

• sources/2026-01-29-cloudflare-moltworker-self-hosted-ai-agent — both the Moltworker Admin UI and its API endpoints sit behind Access. The Moltworker Worker validates the Access-issued JWT on every request to prevent spoofed bypass traffic.
• sources/2026-04-20-cloudflare-internal-ai-engineering-stack — Access is the identity substrate for Cloudflare's internal AI engineering stack: the platform-layer proxy Worker validates the Access JWT, strips client auth, injects the real AI-provider key server-side, and tags requests with an anonymous per-user UUID.

Related

• systems/cloudflare-workers — the typical origin running behind Access.
• concepts/zero-trust-authorization — the broader authorization doctrine Access implements.
• companies/cloudflare — operator.