Skip to main content
The Cloudflare WARP integration has two separate data paths:
  • Inline routing sends selected native-provider, LLM Gateway, MCP Gateway, and Resource traffic through Forge. This path supports Forge identity, inspection, Network Access policy, content policy, and detailed activity.
  • Full catalog discovery imports metadata from Cloudflare Gateway HTTP activity in the background for broader Shadow AI visibility. This asynchronous path does not send content through Forge and cannot enforce Forge content or tool policy.
Do not treat Gateway logs as an inline-routing receipt. In Live > Traffic, Forge identifies the source and its visibility limits. Cloudflare keeps these paths separate because an account can publish at most 1,000 hostname routes. Inline protection reserves routes for destinations required by active policy, then uses remaining capacity for observed catalog destinations in a stable priority order. Full catalog discovery still finds AI traffic that does not fit within that limit and makes it available to Forge’s catalog and policy compilation. This background network-metadata path is specific to Cloudflare’s route limit. Other network integrations do not gain a parallel logging path from this feature. Only capabilities marked Available for the connection can be selected. Forge does not infer availability from a configured route or an earlier test; each client and protocol is enabled only after its own live qualification.

​
Before you begin

Confirm that the Cloudflare account has:
  • Cloudflare One with Gateway, enrolled WARP devices, HTTP policies, and a named Cloudflare Tunnel for Forge.
  • WARP running in Traffic and DNS mode on the devices you intend to protect.
  • Gateway hostname selection enabled. Cloudflare TLS decryption may remain enabled for other traffic, but the Forge-selected destinations below must bypass it so Forge is the only endpoint-facing inspection layer.
  • Cloudflare’s initial-resolved IPv4 and IPv6 ranges included in the relevant WARP profiles.
  • No Local Domain Fallback, split-tunnel exclusion, or higher-priority Gateway rule that bypasses the selected destinations.
  • QUIC disabled for the selected destinations so protected HTTPS traffic does not bypass inspection over HTTP/3.
  • The Forge trust authority, or a customer-signed Forge subordinate, trusted by managed endpoints. Forge-selected traffic must bypass Cloudflare TLS inspection so Forge remains the only endpoint-facing TLS inspection layer.
Create an account-scoped Cloudflare API token for this integration. Restrict it to the intended account. It must be able to read WARP profiles, registrations, Gateway configuration, rules, hostname routes, and Tunnel health; manage only the Forge-owned Gateway rules and hostname routes; and retrieve the selected Tunnel’s connector credential. Full catalog discovery also requires Account Analytics Read and Zero Trust PII Read. Use Cloudflare’s API token permission reference to select the current permission groups. Token permissions authorize provider API operations. Forge’s ownership checks limit the objects Forge changes, but do not reduce the token’s underlying account authority. Do not use a Global API Key. Keep temporary setup credentials separate from the steady-state integration token.

​
Connect Cloudflare WARP

  1. In Forge, open Integrations > Cloudflare WARP.
  2. Enter the Cloudflare account ID, the selected Tunnel ID, and the scoped API token. Choose fail open or fail closed for transport outages.
  3. Save the connection. Forge stores the API token and Tunnel credential in managed secret storage; they are never returned in connection readback.
  4. Run Test connection. Resolve every failed prerequisite before enabling production traffic.
  5. Enable inline protection. Forge first verifies route capacity, then publishes its owned Gateway rules and hostname routes and waits for provider and connector readback.
Forge does not take ownership of unrelated Cloudflare rules, routes, WARP profiles, users, groups, or devices.

​
Confirm readiness

The Cloudflare page reports inline protection and full catalog discovery separately. For inline protection, confirm that routing, TLS, identity, Tunnel, connector replicas, and destination readback are ready. A saved connection or a successful API request is not proof that traffic is protected. For full catalog discovery, confirm that GraphQL polling has advanced its cursor and that recent discovery activity is visible. Logpush has its own status because it is optional; GraphQL discovery does not depend on Logpush.

​
Cloudflare limits and preflight

Cloudflare applies separate account limits to Tunnel routes and Gateway DNS, HTTP, and Network policies. Forge reads current provider-owned and customer-owned usage before preparing a change. If all required routes or rules do not fit, Forge stops before the first write; it does not publish a partial destination set. The failed preflight reports the requested Forge rules, existing customer-owned rules, available slots, and account limit so an administrator can narrow the selection or request more capacity. Cloudflare is not a Forge policy engine. Forge does not copy users, groups, devices, Access rules, or domain-block semantics into Gateway policies. Every destination that requires Forge Access, content, tool, MCP, LLM, Resource, native-provider, or Sessions enforcement consumes inline routing capacity and is evaluated only by Forge/Envoy. If the complete required inline set does not fit, activation fails with the policies and destinations consuming capacity; Forge never substitutes a weaker provider-side rule. After admitting every required destination, Forge fills spare route capacity with best-effort observed catalog destinations in a stable priority order. Catalog destinations that exceed the remaining budget stay discovery-only and are reported as omitted because asynchronous discovery covers them. Forge publishes certificates and Envoy configuration only for the resulting inline set, managed gateway authorities, active Resource destinations, and a bounded rollback predecessor. Catalog growth can therefore use free capacity without displacing required protection or destabilizing active traffic.

​
Availability and connector state

The default transport failure behavior is fail open. If the Forge connector or Envoy origin remains unhealthy beyond the recovery window, Forge withdraws only its affected hostname routes, verifies the withdrawal, and records a bypass event before traffic resumes on the customer’s ordinary path. An administrator can explicitly choose fail closed for workloads that must not bypass Forge. An explicit Network Access denial always remains a denial in either mode. Readiness is not the same as high availability. Forge reports configuration, connector readiness, and current inline proof separately. The current embedded connector topology can run redundant connector processes, but it does not claim host-level HA. Host-level HA requires replicas placed on independently attested physical hosts with distinct workload identities and successful failure-and-recovery qualification.

​
Native client CA trust

Managed endpoints need one trust relationship for Forge inspection: the Forge trust authority, or a customer-signed Forge subordinate. Do not add a separate Cloudflare inspection root for Forge-selected traffic. Configure Cloudflare to bypass its own TLS inspection for those destinations and for the Forge ingress. Some signed native clients use a private runtime that may not read the operating-system trust store. Where a client provides a supported trust setting, point it to an additive PEM bundle containing the same Forge/customer trust chain while preserving the normal public roots. Fully restart the client after installation or CA rotation. Never disable certificate verification as a workaround.

​
Enable full catalog discovery

Full catalog discovery is off by default and independent from inline protection. Enabling it starts GraphQL polling. Forge resumes where the last successful read ended and safely ignores repeated observations. The resulting metadata can expand AI inventory and policy-compilation input. It cannot create a Forge Session, a prompt or response, a tool event, a Forge policy decision, or proof that a request followed the protected inline path. Forge can read Cloudflare’s unsampled cf1GatewayHttpRawGroups GraphQL analytics without steering every catalog hostname and without a Log Explorer subscription. Grant the integration token Account Analytics Read and Zero Trust PII Read. The latter permits Cloudflare user and device dimensions used for attribution. These rows are host/time/action/identity aggregates. Forge projects them into the shared catalog and Live > Traffic path, but labels request cardinality, method, status, body visibility, and Forge policy decisions as unavailable. Cloudflare may revise aggregate counts while recent activity settles; Forge updates the existing observation instead of creating another one. Adaptive Gateway analytics may add context, but does not replace the raw dataset because adaptive sampling can omit hosts.

​
Log Explorer (optional richer request metadata)

Cloudflare Log Explorer is a paid, consumption-based product. Forge never purchases or enables it automatically. If your account already has Log Explorer:
  1. Enable the account-level gateway_http dataset with All events and no sampling.
  2. Include AccountID, Datetime, RequestID, HTTPHost, HTTPMethod, Action, PolicyID, Email, UserID, DeviceID, RegistrationID, SessionID, SourcePort, DestinationPort, DestinationIP, and HTTPStatusCode.
  3. Use Logs Write during setup when Forge must read back dataset fields and filters. The steady-state SQL reader needs Logs Read.
  4. Agree on retention and cost, then run Forge’s real-row and replay check.
The source remains disabled until Forge verifies the dataset, fields, all-event filter, retention, a bounded real-row query, replay deduplication, identity, catalog attribution, and Live > Traffic projection.

​
Authenticated HTTP Logpush (optional richer request metadata)

HTTP Logpush avoids a Log Explorer subscription, but still requires a customer-approved Logpush destination and any Cloudflare plan entitlement for the gateway_http dataset. An account may expose the API while allowing zero jobs; a create failure reporting exceeded max jobs allowed requires Cloudflare to add capacity before this source can be enabled. Removing old jobs does not help when the job list is already empty.
  1. In Forge, enable Full catalog discovery. GraphQL polling starts, and Forge shows an optional HTTPS Logpush destination and authorization header once. Save those values only if you plan to use Logpush.
  2. Create an account-scoped Cloudflare Logpush job for gateway_http using the same complete field list above, including both Email for directory attribution and Cloudflare’s native UserID. Use RFC 3339 timestamps, NDJSON output, all events, and no sampling.
  3. Configure the Forge HTTPS receiver as the HTTP destination and pass the returned value in the Authorization header. Keep the credential out of job names and ordinary URL parameters.
  4. Complete Cloudflare’s gzipped destination validation, then run the Forge real-row, replay, duplicate, and catalog-attribution checks.
Automation that creates or reads back the job needs Account Logs Edit and, for Zero Trust datasets, Zero Trust PII Read. Keep that setup credential separate from steady routing credentials and remove it after setup if Forge is not managing the job lifecycle. Forge validates the authorization header, account ID, payload size, format, and required fields before accepting a delivery. Repeated RequestID values update the same observation. Even with exact request identifiers, this remains metadata-only evidence: it does not create Forge policy decisions, prompts, responses, tools, Sessions, or Governance events. Disabling the receiver immediately rejects future deliveries. Forge does not create storage buckets or paid Cloudflare services for this option.

​
Pause, disable, or disconnect

  • Pause inline protection withdraws Forge-owned routing after verified provider readback. It does not stop full catalog discovery.
  • Disable full catalog discovery stops GraphQL polling and disables the Forge Logpush receiver. It does not withdraw inline routes.
  • Disconnect and remove integration withdraws Forge-owned routing, stops discovery, revokes the Forge connector credential, and removes the stored connection secrets after cleanup is verified.
If you created a Logpush job, delete that job in Cloudflare after disabling discovery or disconnecting. The Forge receiver will already reject later deliveries, but removing the job prevents unnecessary retries. After Forge reports cleanup complete, revoke the integration API token in Cloudflare if it will not be reused. Historical inventory and activity that was collected while the integration was enabled remains available according to your Forge retention settings. It does not continue to act as current routing or enforcement proof.

​
Coverage boundaries

GraphQL raw groups contain host, time, action, aggregate request/user counts, and identity dimensions. They do not contain request IDs, methods, statuses, ports, or bodies and cannot create Forge sessions. Log Explorer or Logpush can provide richer per-request metadata when separately entitled and configured, but still do not contain request or response bodies. RequestID may be absent for bypass traffic; Forge labels those observations as metadata-deduplicated rather than exact request counts. Do Not Inspect, retention gaps, filters, sampling, and excluded traffic can reduce coverage. An empty query or successful delivery is not proof that the source is complete. Use inline routing for content-aware enforcement, prompt and response policy, native protocol parsing, tool governance, Forge sessions, and exact deny receipts. Use full catalog discovery for metadata-level Shadow AI inventory outside the limited inline set. Discovery is optional and independent of inline protection: a disabled or delayed source does not withdraw inline routes, and pausing inline protection does not turn Cloudflare metadata into content evidence.

​
Pilot validation and troubleshooting

Use one selected WARP device before widening the destination set. Verify current WARP connectivity, applied Forge routing, certificate trust, one allowed request, a scoped denied request, and recovery after removing the test policy. Confirm the evidence distinguishes decrypted request content from connection metadata. If API authentication works but routing remains unready, inspect the failed prerequisite: profile coverage, route capacity, Tunnel health, connector readback, TLS bypass, or device trust. Do not treat a successful GraphQL discovery query as proof that inline routing is active.