Pipelock vs Cloudflare AI Gateway

The short version

Pipelock is an open-source agent firewall. It scans HTTP, WebSocket, and MCP traffic routed through it for credential leaks, prompt injection, SSRF, and tool poisoning and can emit signed action receipts for mediated decisions when a signing key is configured. Single Go binary, self-hosted.

Cloudflare AI Gateway is a hosted gateway between an application and its LLM providers. The integration is a base URL change: the application calls the gateway endpoint instead of the provider directly, and Cloudflare relays the request upstream. The gateway adds caching, rate limiting, retries and provider fallback, analytics on token usage and cost, and two beta features, Guardrails and Data Loss Prevention, that inspect prompts and completions. It supports Workers AI, Anthropic, Google Gemini, OpenAI, Replicate, and other providers, and is available on all Cloudflare plans.

Pipelock inspects what the agent process sends and receives over the network when that traffic is routed through it. Cloudflare AI Gateway inspects what the application sends to and receives from the model API.

Feature comparison

When to pick Pipelock

Your threat model extends past the model call. An agent that calls MCP servers, fetches pages, opens WebSockets, or POSTs to third-party APIs is doing things a model-API gateway never sees. A leaked cloud key in a request to a logging service doesn’t traverse the LLM API. Neither does a poisoned tool description. Pipelock scans the traffic the agent actually emits.

You need MCP content awareness. Pipelock parses MCP framing, flags poisoned tool descriptions, detects drift when a trusted tool changes mid-session, and scans arguments and responses. Cloudflare AI Gateway’s documented surface doesn’t extend into MCP.

You want evidence you can verify without the vendor. Pipelock’s receipts are signed by the deployment’s own key, outside the agent process, and the shipped verifier checks them offline. That’s a different trust model from reading gateway logs through a vendor’s dashboard. It’s still the operator’s key, so it proves what the mediator decided, not that the operator is honest.

You want to run the whole stack yourself. No hosted service, no API key to a third party, no telemetry leaving the host.

When to pick Cloudflare AI Gateway

Your application is a chatbot, RAG pipeline, or copilot. The control point that matters is what enters and leaves the model. The gateway sits exactly there.

You want one line of code to add observability. Switch the base URL and token counts, request volumes, error rates, and per-provider cost show up in the dashboard.

You want resilience patterns you’d otherwise build by hand. Retries on transient errors, fallback from one provider to another, response caching, and gateway-side rate limits.

You want a hosted, edge-distributed service. Nothing to run; latency is your existing distance to a Cloudflare POP.

Architecture differences

Cloudflare AI Gateway asks: is this model request well-formed, cacheable, within the rate limit, and free of content the guardrail policy flags? Anything outside the model-API path, meaning MCP traffic, HTTP to non-model services, arbitrary WebSocket egress, is outside the control surface.

Pipelock asks: what is moving across the mediated agent network boundary, and is any of it unsafe? Routed request bodies are checked for leaked credentials. Routed tool descriptions are checked for poisoning and drift. Scanned responses are checked for injection. SSRF checks run before DNS resolution. With a signing key configured, Pipelock can emit signed action receipts for mediated decisions.

Run both when you want edge-scale observability for the model bill and self-hosted enforcement for the agent’s actions.

A note on evidence

Cloudflare AI Gateway records gateway logs in the customer’s account: payloads, token counts, costs, and the decisions Guardrails and DLP took. You read them through Cloudflare’s dashboard and APIs.

With a signing key configured, Pipelock can emit signed action receipts for mediated decisions, containing the action, the policy hash, the decision, and a hash link to the previous receipt. The shipped verifier checks a receipt chain against the deployment’s public key offline, without contacting the Pipelock service, the agent, or any application code. The action receipt format is public.

The difference is where the evidentiary anchor sits, not which product is better. For incident response and compliance work that needs records produced outside the process that acted, the signer’s location matters.

Further reading

• Pipelock: the 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
• Action receipt spec: the wire format for Pipelock’s signed receipts
• Pipelock on GitHub