---

name: cloudflare-one description: Design, configure, troubleshoot, or review Cloudflare One Zero Trust and SASE deployments. Use cloudflare-one-migrations for migration planning from other vendors.

Cloudflare One

Before citing limits, settings, API fields, category IDs, or exact UI paths, retrieve current information from the Cloudflare One docs, the Cloudflare docs MCP server, or the Cloudflare API schema.

Workflow

1. Classify the ask: architecture, configuration, troubleshooting, migration, or review.
2. Gather context: account ID, users/sites/apps, identity provider, SCIM/group sync, device management, traffic path, compliance constraints, and rollout blast radius.
3. Retrieve only the current docs needed for the products involved: Access, Gateway, WARP/device client, Tunnel/Mesh, Cloudflare WAN, DLP, CASB, device posture, or identity.
4. If account access is available, inspect existing resources before proposing or making changes: Access apps/policies/groups/IdPs, Gateway rules/lists/categories, device profiles/posture checks, tunnels/routes, DNS/resolver settings, and locations/sites.
5. Propose the change set with prerequisites, validation, and rollback. For risky changes, stage disabled or scoped to a pilot group/site unless the user explicitly asks otherwise.

Assessment Prompts

Use these to avoid jumping straight to configuration. Ask only the prompts relevant to the user's task.

Architecture and Current State

• Sites and users: offices, branches, data centers, VPCs, remote users, contractors, user counts, and current connectivity model.
• Applications and destinations: SaaS, public apps, private apps, APIs, infrastructure targets, protocols, ports, hostnames, and IP ranges.
• Connectivity: VPN, MPLS, SD-WAN, direct Internet breakout, centralized backhaul, site-to-site needs, and private DNS architecture.
• Security stack: current SWG, NGFW, VPN/ZTNA, DLP, CASB, email security, logging, and compliance requirements.
• Identity: IdP, SCIM/group sync, group naming, multi-IdP needs, service accounts, and contractor/partner access.
• Rollout: pilot users/sites, blast radius, rollback path, support owners, and success criteria.

Access and SaaS Federation

• App shape: web app, API, SSH/RDP/VNC, database, SaaS app, public hostname, private IP, or private hostname. Retrieve Access application type docs before choosing.
• Access model: clientless browser access, private networking with device client, peer to peer connectivity, service connections with service tokens or mutual TLS, or SaaS SSO federation.
• Policy needs: user groups, device posture, session duration, mTLS, service tokens, and app launcher visibility. Retrieve Access policy docs before configuring selectors or evaluation order.
• SaaS details: SAML vs OIDC support, ACS/redirect URLs, Entity IDs/client IDs, required attributes, and tenant-control requirements.

Tunnel and Private Networking

• Sites and segments: which data centers, VPCs, offices, or network segments need connectivity.
• HA: dev/test single connector, production multiple connectors, or advanced multi-tunnel/site redundancy.
• Runtime: where cloudflared or WARP Connector/Mesh will run: VM, container, Kubernetes, bare metal, or other target.
• Egress: whether connectors can reach Cloudflare over the required outbound ports/protocols. Retrieve Tunnel connectivity prechecks before naming exact endpoints.
• Origin reachability: whether the connector can resolve and reach every private origin.
• Routing: required CIDRs/hostnames, overlapping IP spaces, virtual networks, Split Tunnels, and private DNS/resolver policy needs.
• Management model: prefer remotely managed/token-based tunnels for new deployments unless there is a clear reason for local config.

Gateway, TLS, and DLP

• Traffic controls: DNS categories, HTTP URL/path inspection, L4 ports/protocols, egress IP requirements, custom lists, and allow/block exceptions. Retrieve Gateway traffic policy docs for current selectors and order of enforcement.
• Identity: whether Gateway policies need user or group selectors, and whether users will be authenticated through WARP/IdP context. Check Gateway identity selectors and SCIM provisioning when groups are involved.
• TLS inspection: root CA deployment path, certificate-pinned applications, compliance exceptions, and FIPS requirements. Retrieve TLS decryption docs before enabling.
• DLP: sensitive data types, channels to inspect, TLS inspection readiness, DLP profiles, payload logging requirements, and false-positive tolerance. Retrieve DLP docs before creating enforcement.

CASB, Device Posture, and Risk

• CASB: SaaS vendors, admin access level, scan policy, org size, remediation owner, and whether inline protection is also required. Retrieve CASB findings docs before recommending remediation.
• Device posture: required checks, third-party EDR/MDM integrations, enrollment rules, device profiles, and split tunnel alignment.
• Risk scoring: relevant behavior signals, false-positive sources such as VPNs or service accounts, and whether risk is for investigation or enforcement. Retrieve user risk score docs before using risk in policies.

Cloudflare WAN / Site Connectivity

• Site topology, on-ramp type, route ownership, tunnel redundancy, static vs BGP-managed routes, network firewall needs, and appliance/profile ownership. Retrieve Cloudflare WAN and Cloudflare Network Firewall docs before proposing site connectivity changes.

Guardrails

• Access controls application authorization; Gateway controls traffic inspection/filtering. Use both when the requirement spans identity-aware app access and network/web security.
• For new Access deployments, create policies through the reusable policy API (/access/policies) and attach them to applications. Do not send inline policies in an application create/update request unless the current API documentation explicitly requires an app-scoped policy.
• Treat an app-scoped policy reported as reusable: false as legacy. Migrate existing policies with the documented make_reusable endpoint or replace them with reusable policies; do not create new legacy policies. Distinguish legacy policies from the deprecated legacy private-network application type.
• Public hostname Access apps can be clientless. Private destination apps require WARP/Device client or another network on-ramp plus routes and DNS resolution. Retrieve self-hosted private app docs before configuring private destinations.
• Cloudflare Tunnel is an off-ramp from a private network to Cloudflare. Cloudflare WAN and Mesh are other off-ramps which can also be on-ramps.
• Group-based policies depend on IdP group claims or SCIM. If group sync is missing, do not invent group selectors.
• Private hostnames need explicit DNS routing/resolution; creating an Access app alone is not enough. Use resolver policies and review Connect a private hostname
• HTTP inspection and DLP for encrypted web traffic require TLS inspection and planned Do Not Inspect exceptions.
• Gateway DNS, Network, HTTP, and Egress policies have different evaluation semantics. Retrieve order of enforcement docs before explaining precedence.
• Start broad block/allow/DLP/TLS policies disabled limited to a pilot with specific target users or groups unless the user approves a wider rollout.

Identity and Access

• Access Groups are Cloudflare objects; IdP/SCIM groups are identity claims. Gateway group selectors use synced IdP groups, not Access Groups.
• Group names and SAML/OIDC attributes are case-sensitive. Verify exact claim names and values before creating group-based rules.
• SCIM changes and group membership can be stale until sync and re-authentication complete. Troubleshoot with the user's last authenticated identity, not just the IdP state.
• Access policies are default-deny. A private app with routes but no Allow policy still blocks access.
• Access policy selectors can use IP lists, not Gateway domain or URL lists.
• SaaS federation handles authentication into the SaaS app. SaaS authorization and tenant restrictions usually require SaaS-side roles and/or Gateway tenant controls.
• Browser Rendering for SSH/VNC/RDP is an Access capability. Browser Isolation renders general web content remotely. Do not conflate them.

Device Client Deployment

• The Cloudflare One device client is the on-ramp for user devices. Two components control it: enrollment rules (who can connect) and device profiles (how the client behaves after enrollment).

• The enrollment rule is an Access application of type warp, not a device setting. It accepts reusable Access policies. Look in Access for enrollment debugging, not Devices.

• For headless or autonomous devices (services, kiosks, Linux hosts), use service token enrollment. Non-human devices authenticate as non_identity@[team-domain].cloudflareaccess.com and have no group membership - device profiles targeting IdP groups will not match them. Target headless devices explicitly with the non-identity email, specific conventions about the devices (OS information, etc.),or let them fall to the default profile.

• Device profiles control connection mode, split tunnel configuration, user permissions (disable, switch lock), auto-reconnect, and captive portal behavior. Profiles are matched by user group or device attributes in precedence order - first match wins, default profile catches the rest.

• Split tunnel mode is the single most impactful client setting. Choose the mode based on the deployment goal:

  | Goal | Mode | Rationale | |---|---|---| | VPN replacement only (private apps) | Include | Route only specified private CIDRs and hostnames through the client. Everything else goes direct. Minimal blast radius. | | SWG only (internet security) | Exclude | All traffic through the client