Pipelock vs Cloudflare AI Gateway

Pipelock vs Cloudflare AI Gateway is a comparison across deployment models and trust boundaries. Pipelock emits mediator-signed action receipts from outside the agent trust boundary, scanning HTTP, MCP, and WebSocket egress on the agent’s network path. Cloudflare AI Gateway is a hosted observability and policy layer that sits at Cloudflare’s edge in front of LLM API calls, providing caching, rate limiting, retries, fallbacks, analytics, and prompt-and-completion scanning for harmful content and sensitive data. One sits on the agent side and watches every protocol the agent speaks. The other sits at the edge and watches LLM-API traffic specifically.

The short version

Pipelock is an open-source agent firewall. It scans HTTP, MCP, and WebSocket traffic for credential leaks, prompt injection, SSRF, and tool poisoning. Single Go binary, self-hosted, Apache 2.0 core. Every decision can emit a mediator-signed action receipt from a signing key Pipelock holds outside the agent trust boundary.

Cloudflare AI Gateway is a hosted gateway service that sits between an application and one or more LLM providers. Configuration takes about one line of client code change: instead of calling api.openai.com, the application calls Cloudflare’s gateway endpoint, and Cloudflare relays the request to the upstream provider. The gateway adds caching, rate limiting, request retry, model fallback, analytics on token usage and cost, plus Guardrails for harmful-content moderation and DLP profile scanning on prompts and completions. It supports OpenAI, Anthropic, Google Gemini, Workers AI, Groq, xAI, AWS Bedrock, Azure OpenAI, and Replicate, with a unified API that doubles as an OpenAI-SDK-compatible drop-in replacement.

Pipelock inspects what the agent process sends and receives over the network. Cloudflare AI Gateway inspects what the application sends to and receives from the LLM API.

Feature comparison

When to pick Pipelock

Your threat model extends past the LLM call. An agent that calls MCP servers, fetches web pages, opens WebSockets, or makes arbitrary HTTP requests is doing things the LLM-API gateway does not see. A POST body containing a leaked AWS key sent from the agent process to a third-party logger does not traverse the LLM API. Neither does a tool call that runs a destructive shell command. Pipelock scans the network the agent actually emits.

You need MCP-specific awareness. Pipelock parses MCP framing, detects poisoned tool descriptions, flags drift when a previously trusted tool changes its schema mid-session, and scans tool call arguments and responses bidirectionally. Cloudflare AI Gateway’s documented surface does not extend into MCP.

You want offline-verifiable evidence from outside the actor. Pipelock’s mediator-signed action receipts are produced by a signing key Pipelock holds, separate from the agent process. An external verifier can validate any receipt against the published public key without involving the agent or the gateway. The reference Python verifier (pipelock-verify) demonstrates cross-language byte-for-byte validation. Gateway logs sit on the application’s or vendor’s side; the trust model is different.

You want to run the entire stack yourself. Pipelock is a single Go binary under Apache 2.0. No hosted service, no API keys to a third party, no telemetry leaving the host. The Cloudflare service is hosted on Cloudflare’s edge by design; that is its operational shape, not a configuration choice.

When to pick Cloudflare AI Gateway

Your application is a chatbot, RAG pipeline, or copilot calling a hosted LLM. The control point that matters is what enters the model API and what comes out. Cloudflare AI Gateway sits exactly there, with caching that reduces cost and Guardrails plus DLP scanning that catch a meaningful slice of prompt and completion risk.

You want one line of code to add observability. Switching the API base URL from api.openai.com to the gateway endpoint is the integration. Token counts, request volumes, error rates, and per-provider cost analytics show up in the Cloudflare dashboard with no other application changes.

You value hosted scale and edge distribution. Cloudflare runs the gateway on its global network. Latency to the gateway is the operator’s existing distance to a Cloudflare POP. There is no infrastructure to manage on the application side beyond the dashboard.

You want resilience patterns the application would otherwise have to build. Configurable retries on transient errors, fallback from one provider to another when the first fails, and rate limits scoped at the gateway are operational features that an application-side library would replicate by hand.

Architecture differences

The two products answer different questions.

Cloudflare AI Gateway asks: is this LLM-API request well-formed, cacheable, allowed under the rate limit, and free of harmful or sensitive content? The answer comes from the gateway sitting in the request path between the application and the upstream LLM provider. Configuration changes are application-side: pointing the SDK at the gateway endpoint and adjusting rate limits and Guardrails policies in the dashboard. Anything outside the LLM-API request path (MCP traffic, HTTP egress to non-LLM services, arbitrary WebSocket egress, DNS-based exfiltration) is outside the control surface.

Pipelock asks: what is actually moving across the agent’s network boundary, and is any of it unsafe? The answer is content inspection on every protocol the agent speaks: HTTP, WebSocket, MCP. Outbound request bodies get checked for leaked credentials. MCP tool descriptions get checked for poisoning and drift. Response bodies get checked for prompt injection across multiple normalization passes. SSRF checks run before DNS resolution so DNS queries cannot be used to encode and exfiltrate secrets. The deployment shape is a process the operator runs, not a hosted service.

These are different enforcement points. A team that wants edge-scale observability for its LLM bills and self-hosted security enforcement for its agent egress can run both, with Cloudflare AI Gateway sitting in front of the LLM API and Pipelock sitting on the agent’s network path.

A note on evidence

Both tools produce records of their decisions, but the shape and the trust model differ.

Cloudflare AI Gateway records gateway logs in the customer’s Cloudflare account: request and response payloads, token counts, costs, decisions taken by Guardrails and DLP. Cloudflare’s documentation describes log access through the dashboard and APIs. The records sit on the vendor side; the customer reads them through Cloudflare’s surfaces.

Pipelock emits a mediator-signed action receipt from a signing key Pipelock holds outside the agent process. The receipt contains the action, the policy hash, the decision, and a chain-link hash to the previous receipt in the session. An external verifier can validate any receipt against Pipelock’s published public key without involving Pipelock, the agent, or any application code. The format is open and pairs with a separate reference Python verifier for cross-language byte-for-byte validation.

This is not a claim that one is better than the other. It is a claim about where the evidentiary anchor sits. For compliance and incident-response workflows that need attestable records from outside the process that generated them, the signer location matters.

Third-party feature descriptions are based on public materials reviewed in May 2026. Features and pricing may change. Check each project’s current documentation for the latest.

Further reading

• Pipelock : the full product page
• What is an agent firewall? : category definition and evaluation checklist
• Agent egress security : why egress is the control point for agents
• Open source AI firewall : the category Pipelock sits in
• MCP security tools : the broader MCP-security landscape
• Action receipt spec : the wire format for Pipelock’s mediator-signed action receipts
• Cloudflare AI Gateway documentation : the product page
• Pipelock on GitHub