> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloudflare WARP

> Route selected traffic through Forge and optionally discover broader AI activity from Cloudflare Gateway logs.

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](https://developers.cloudflare.com/fundamentals/api/reference/permissions/)
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.

### Gateway analytics (recommended)

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.