Skip to content

SYSTEM Cited by 6 sources

Cloudflare Access

Overview

Cloudflare Access is Cloudflare's identity-aware application-proxy product — sits in front of applications (self-hosted or SaaS) and enforces identity + device + network policy via OIDC / SAML / one-time PIN flows before forwarding authenticated requests to origin. Part of the broader Cloudflare One / Zero Trust suite.

Closely related to / a rebrand of the earlier Zero Trust Access capability surfaced elsewhere in the wiki.

Managed OAuth support for agents (Agents Week 2026)

Cloudflare announced during Agents Week 2026 (see managed OAuth for Access) that Access fully supports RFC 9728 OAuth Protected Resource Metadata. Concretely:

  • Access-protected applications now advertise their authorization-server discovery metadata at the RFC 9728-mandated well-known path.
  • When an agent receives a protected URL and gets 401, it can fetch the metadata, find the authorization-server URL, drive the human user through a scoped OAuth consent flow, and come out the other side with a per-agent token the Access origin accepts.
  • The named demo scenario in the 2026-04-17 post has OpenCode receiving an Access-protected URL from a user, sending the user through Access's OAuth consent, and succeeding on subsequent authenticated calls — no session reuse, no token pasting, no ambient browser authority.

Why this matters for agent workloads

Pre-RFC-9728, the prevailing workaround for agents needing authenticated access was to let the agent pilot the user's browser session. This is the "use the logged-in browser" posture: agents effectively impersonate the human everywhere with no per-agent consent, no scope limitation, and no audit trail specific to the agent. Unsafe at scale.

Access + RFC 9728 enables per-agent OAuth scoping — per-resource tokens, per-scope grants, revocable at any time, auditable per-agent in Access logs. The agent-ergonomic authentication primitive the industry was missing.

Relationship to Agent Readiness Score

Agent Readiness Score checks for RFC 9728 OAuth metadata presence (described under the non-scoring OAuth check in the 2026-04-17 post). Access supplies the metadata automatically for Access-protected sites — so a Cloudflare-protected origin is agent-ready on the auth axis without origin-side work.

Require Access Protection (frontier-model defence context)

Cloudflare Access is the zero-trust layer in the frontier-model defence architecture. The implicit trust of "being inside the network" is replaced with explicit per-request identity and policy for every employee accessing every tool.

Require Access Protection ensures newly deployed or misconfigured applications can't be reachable before an access policy is in place. Built after an engineer shipped a misconfigured tool — in Cloudflare's deployment the exposure stopped at the tool itself (no lateral movement across a flat network). Implements require-access-before-reachability.

IdP Federation makes the secure-by-default posture consistent: IdP is configured once and shared across the organisation. New accounts get SSO automatically; recipient-side IdP connections are read-only.

(Source: sources/2026-06-09-cloudflare-defend-against-frontier-cyber-models)

Worker- and account-level policies (2026-08-14)

Access can now be attached directly to a Worker, or to every Worker in an account, instead of only per-hostname. This moves the policy from the hostname to the application object: any domain/route/ workers.dev subdomain/preview URL that resolves to the Worker is protected automatically, closing the gap where a newly added custom domain was reachable without auth until its policy was written (worker-attached-policy-over-hostname-policy).

  • Account-level policy makes every current and future Worker private by default (private-by-default-deployment, account-wide-default-policy); scope is selectable (preview-URL traffic only, all production, or both), with a per-Worker bypass for intentionally public Workers.
  • Precedence when policies overlap: hostname → Worker → account (most specific wins). A new Access tab in the Worker view shows which policies apply.
  • Identity in context, no JWT parsing: with Access on a Worker, the authenticated identity is attached as ctx.access; ctx.access.getIdentity() returns email/name/groups with no in-Worker JWT validation (request-context-identity-injection). wrangler dev can simulate an authenticated user locally (local-dev-identity-simulation).
  • Platform default: setting an Access policy on a Workers-for-Platforms dispatch Worker makes every tenant Worker private by default (patterns/central-proxy-choke-point).
  • Agents authenticate via service tokens.

Enabled by FL2's phase-ordered module pipeline: to target individual Workers, Workers routing was split from execution and moved before Access in the request pipeline — safe on FL2 because phases statically declare inputs/outputs. (Source: sources/2026-08-14-cloudflare-secure-all-your-internal-vibe-coded-applications-in-one-click)

Seen in

  • companies/cloudflare — parent company.
  • systems/cloudflare-zero-trust-access — earlier wiki page on the same product family.
  • oauth-protected-resource-metadata — the standard Access now implements.
  • concepts/sso-authentication — parent SSO concept.
  • agent-readiness-score — graded check surface.
  • concepts/zero-trust-authorization — overarching concept.
  • require-access-before-reachability — Require Access Protection pattern derived from this system.
  • systems/cloudflare-workers — Access now attaches per-Worker; identity via ctx.access.
  • systems/workers-for-platforms — dispatch-Worker policy for private-by-default platforms.
  • systems/fl2-proxy — the routing/execution split that enabled per-Worker Access.
  • private-by-default-deployment — posture enabled by account-level policy.
  • request-context-identity-injection — ctx.access identity delivery.
  • worker-attached-policy-over-hostname-policy — policy binds to Worker, not hostname.
  • account-wide-default-policy — private-by-default across all Workers.
  • local-dev-identity-simulation — simulate Access identity in wrangler dev.

AI Gateway identity propagation (2026-08-05)

Cloudflare can protect a custom AI Gateway domain with Access. After SAML-backed authentication and Access policy evaluation, the gateway receives the verified Access user ID as cf.user_id request metadata. That removes the shared-provider-key attribution gap: logs, per-user spend limits, and User Insights behavioral analytics can identify the person or agent that generated the traffic. This is an identity propagation use of Access, distinct from the earlier OAuth-discovery flow for agents accessing protected origins. (Source: sources/2026-08-05-cloudflare-catching-rogue-ai-behavior-with-identity-aware-analytics)

Cloudflare OS identity boundary (2026-08-05)

Cloudflare OS uses Cloudflare Access to control who may enter the platform. Inside that entry boundary, agents and apps still start with no resource access; resource grants and later sharing checks are handled by Cloudflare OS Gatekeepers. This separates user/workspace entry authentication from resource- and observation-aware authorization. (Source: sources/2026-08-05-cloudflare-os-an-open-platform-for-agents-apps-and-work)

Last updated · 766 distilled / 2,225 read