Two different front doors to the same problem. Cloudflare puts your MCP servers behind one endpoint and your IdP, curated by an admin. KnoxCall puts them behind one token per server, bound under RFC 8707, with inspection on what travels in the arguments. If you already own Cloudflare Zero Trust, the honest answer is usually "both".
Give them their due
Read from Cloudflare's own docs and blog on 2026-08-25 — the portals documentation and the Zero Trust MCP announcement. If an org-wide front door with your existing identity provider is what you are missing, this is a strong product and we would tell you so.
Where they differ
Each row cites both halves. Cloudflare's column is quoted from the pages linked above; ours comes from the same code citations behind our control table. Where we could not evidence something about Cloudflare, the row says so rather than assuming absence.
| Cloudflare MCP Server Portals | KnoxCall | |
|---|---|---|
| Where it lives | Cloudflare One → Access controls → AI controls. A different product from Cloudflare AI Gateway, whose twelve enumerated features do not include MCP | The same gateway that governs your model traffic, on the same bill |
| Identity | Cloudflare Access with your org IdP; per-user sessions with 24h inactivity expiry | Tokens, not sessions: OIDC workload federation for CI, and X-KC-User attribution on every call |
| Token audience binding | Access authenticates the user to the portal; a per-server audience binding on the token is not something we could evidence | RFC 8707: wrong resource is 401, unbound is 401 fail-closed, non-tool-bound is 403 |
| Step-up controls on an authorised server | Cloudflare's own docs: independent MFA, purpose justification and temporary authentication are not enforced for servers authorised through portals | Not session step-up either — the equivalent is token-shaped: one token, one server, short TTL, DPoP-bindable, revocable |
| Empty tool allowlist | Curation is per portal; an admin chooses which tools appear | Empty advertises nothing; the caller's token intersects, never unions |
| PII / DLP on tool arguments | Cloudflare DLP names "tool call arguments and results in JSON payloads" explicitly, reusing Cloudflare One detection profiles | Built-in detectors on arguments and results. Your own custom recognizers do not reach the MCP path yet — model calls get both |
| Streamed responses | Documented: streaming responses are fully buffered before scanning, "expect increased time-to-first-token latency"; and "cache hits skip DLP scanning" | Hold-back state machine redacts inside the stream; CI asserts the hold-back emits before the upstream stream ends |
| Provider credential custody | Per-server: unauthenticated, per-user OAuth, or an admin credential | Envelope-decrypted and injected at the egress hop; your workload only ever holds a KnoxCall key. Or forward the caller's own credential in passthrough mode |
| Stated limits | No stdio-only servers; maximum 40 servers per portal; open beta since 2025-08-26 with no GA announcement found; pricing not evidenced | No global edge, and our own limits are on the MCP Gateway page rather than in a footnote |
Two claims we will not make, because we checked and they are false. "Cloudflare has no MCP story" is wrong — Portals is a real, shipped product, just not part of AI Gateway. "Cloudflare cannot see PII in tool arguments" is also wrong — its DLP docs name them explicitly. The distinction that survives contact with the documentation is the streaming one, and it is the only one we lean on.
And our own residual. KnoxCall does not run a global edge, our tool-governance surface is younger than Cloudflare One, and our tenant-specific PII recognizers do not yet run on the MCP path — the shipped detector set does. If your organisation already lives in Cloudflare Zero Trust, a portal in front and KnoxCall on the data plane is a better answer than either alone.
Choosing
you already run Cloudflare Zero Trust, your requirement is "my people reach an approved set of tools through our IdP", and you want that administered in the console your security team already opens every morning. That is a real product doing a real job, and we do not offer an org-wide portal.
your requirement is about the credential and the payload: that a stolen tool token opens exactly one server, that the upstream provider key never reaches the workload, that customer data in tool arguments is inspected, and that the same controls cover your model traffic on the same bill.
They compose: the portal is the front door and the identity check, KnoxCall is the credential custody and the payload inspection behind it. A page that told you one replaces the other would be selling rather than comparing.
No, and it is worth being precise because the opposite claim is easy to make and wrong. Cloudflare's MCP story is real, but it lives in Cloudflare One under Access controls, AI controls, MCP Server Portals, which is a different product on a different bill. AI Gateway's own features index enumerates exactly twelve capabilities, Caching, Spend Limits, Rate Limiting, Dynamic Routing, Guardrails, DLP, Authentication, BYOK, Analytics, Logging, Custom Metadata and Custom Costs, and MCP is not among them. Cloudflare's own reference-architecture post of 14 April 2026 places AI Gateway on the link between the MCP client and the model rather than on the MCP link itself. Verified against developers.cloudflare.com on 25 August 2026.
It has been in open beta since 26 August 2025 and we could find no GA announcement as of 25 August 2026. We also could not evidence its pricing: the Zero Trust plans page carries no per-user table for it and directs you to sales. Neither of those is a criticism, they are simply facts a buyer should have before planning around it, and we would rather say we could not evidence something than guess.
Cloudflare's own portals documentation states that independent MFA, purpose justification and temporary authentication are not enforced when servers are authorised through a portal. That is a vendor-stated limitation, not our inference. On the KnoxCall side the equivalent controls are token-shaped rather than session-shaped: a tool token is bound to one MCP server under RFC 8707, so presenting it at another server is a 401, and a token carrying no resource binding is also a 401 rather than being treated as unrestricted. The two designs answer different questions, and if per-server step-up matters to you it is worth reading both sets of docs rather than either of our summaries.
Yes. Its DLP documentation names tool call arguments and results in JSON payloads explicitly as in scope, and a comparison page that told you otherwise would be wrong. The real distinction is streaming: Cloudflare documents that DLP buffers the whole streamed response before scanning and to expect increased time-to-first-token latency, and that cache hits skip DLP scanning entirely. KnoxCall's hold-back state machine redacts inside the stream instead, which is the same protection without the first-token penalty. Documented against documented, both fetched 25 August 2026.
Yes, and if you already own Cloudflare Zero Trust you probably should. Portals give you an org-wide front door with your IdP, tool curation and per-request logging at the edge. KnoxCall sits on the data plane, holding the upstream credential out of the workload and governing what may travel in the arguments. Nothing in either design conflicts with the other, and the largest limit of a portal, that it has a maximum of 40 servers and no stdio servers, is a capacity question rather than a governance one.
Audience-confined tool tokens, allowlists that deny by default, PII detection on arguments and results — free to start.