Say you run the backend for a health app. Users trust it with sensitive things, and you'd like to stop knowing which phone each request came from. You don't want the IP addresses. Your servers already sit behind Cloudflare, so you assume the privacy tooling is a switch you flip.
This post says it isn't, and then reports what Cloudflare did about it.
Start with the idea. Cloudflare has opened a closed beta of a managed gateway for Oblivious HTTP, the IETF standard that lets, in the company's words, "app backends receive HTTP requests without seeing user IP addresses." OHTTP splits each request across two independently operated hops. A relay sees the client's IP and TLS fingerprint but only ciphertext. A gateway decrypts the request for your app server but never sees who sent it. As Cloudflare puts it: "The separation of trust between relay and gateway is critical: it ensures that no single party sees both client identifiers and request contents."
There are no adoption figures here, only named customers. Flo Health uses OHTTP for its app's Anonymous Mode. Apple's Private Cloud Compute uses it "to disassociate AI inference requests from user identities." So you'd be in recognizable company.
Now the catch, and it's the reason the product exists. Cloudflare already had a relay, launched in 2022. But if your servers sit behind Cloudflare, you couldn't use it. Cloudflare would see both the client metadata and the decrypted contents of your requests, "breaking OHTTP's privacy model." The company's own relay was off limits to its own customers.
So Cloudflare renamed the 2022 product Cloudflare OHTTP Relay and built the other half: a gateway that pairs with a third-party relay instead. For you, that means picking who runs the relay, and keeping Cloudflare on only the gateway side. It's a paid add-on enabled per zone. It answers at a well-known path, /.well-known/ohttp-gateway, and chunked OHTTP is recommended so requests can be processed incrementally. Non-OHTTP traffic passes through untouched, so your existing users aren't disturbed.
If you'd want to wire this up through the API, the catalog shows where it attaches. The Cloudflare provider page lists 650 API pages, and a per-zone add-on is configured through the Cloudflare Zones API and the Cloudflare Zone Settings API. The agentic access profile maps 3,118 operations, 1,576 of them acting. The Kin Score is 81.3, exemplar band. Agent Readiness is 74.8, agent-native, still the highest this series has recorded, with sixteen dimensions lit.
Here is the turn that matters. The design lesson is about Cloudflare's own record. The company noticed that its own product couldn't be used by its own customers without breaking the trust model. It fixed that by building the piece it should not operate alongside the piece it does, then letting the customer choose which side Cloudflare sits on. That is the same separation an agent platform needs between the party that knows who the user is and the party that executes the request.
And the catalog files a gap against that very record. On these scores, the unlit dimension is still consent identity. Cloudflare has made it possible for an app not to know who is asking. The record has yet to show the matching contract for an agent proving on whose behalf it is asking.
What you take away is practical. If you want your backend blind to user identity, the relay and the gateway must be run by different parties, and being a Cloudflare customer changes which pairing is allowed. You can now keep Cloudflare on the gateway side with a relay you choose. And when you think about agents calling your API, ask the mirror question: who proves whose behalf the request is made on, and does anyone publish that contract yet? On this record, no one has.
Read the original: https://apis.io/2026/10/19/cloudflare-builds-an-ohttp-gateway-so-no-single-party-sees-both-halves/