Proxies and gateways

Pipelock vs Open Source MCP Gateways

Routing gateways centralize auth and multi-server policy, and several now add guardrails. Pipelock adds payload inspection on routed traffic and optional signed receipts.

Reviewed: September 2026
Read: 5 min
Sources: 6 checked

At a glance

Pipelock source Open source MCP gateways

Job Agent firewall. Mediates HTTP, WebSocket, and MCP traffic routed through it, scans it for secret leaks, prompt injection, SSRF, and tool poisoning, and can emit signed action receipts for mediated decisions when a signing key is configured. One entry point in front of many MCP servers: routing, authentication, tool-level access control, and increasingly a guardrail hook.

Enforcement point Network path, outside the agent process MCP transport, between clients and a fleet of servers

Source Open source, Apache-2.0 core; Enterprise under ELv2 Open source: Docker MCP Gateway (MIT), agentgateway (Apache-2.0), Obot (MIT), Lasso MCP Gateway (see its repository)

Pricing shape Free core; paid Pro and Enterprise tiers Free to run; some projects sell hosted or enterprise editions

Runs as Single Go binary, self-hosted; container and Helm Container, binary, or Python package depending on the project

Pick Open source MCP gateways

You front many MCP servers and need centralized auth, routing, and tool-level access policy before anything else.

Pick Pipelock

You need to read the tool descriptions, arguments, and responses for poisoning, leaks, and injection, cover HTTP and WebSocket too, and keep a signed record.

Run both

Put the gateway in front for identity and routing. Put Pipelock on the wire for inspection and receipts. Each layer stops a failure the other cannot see.

Want the runtime boundary, not just another checklist?

Get Pipelock See Pricing

The short version

Open source MCP gateways handle routing, access control, and multi-server policy. Pipelock inspects what flows through its mediated connection and can record its decision. So this is Pipelock next to gateways rather than Pipelock versus gateways.

The honest change since this page was first written: two of the gateways below now document content guardrails of their own. agentgateway ships prompt guards (regex and built-in PII detectors, plus OpenAI moderation, AWS Bedrock Guardrails, Azure AI Content Safety, and Google Model Armor integrations) and an external-policy MCP guardrail hook. Obot documents inspect, reject, and modify filters on MCP requests and responses. That narrows the gap on “content inspection: yes or no”. It doesn’t change the depth: none of them document tool-description fingerprinting, rug-pull drift detection, encoding-aware DLP across HTTP and WebSocket, or signed offline-verifiable receipts.

For the category definitions, see the MCP gateway and MCP proxy guides.

Open source MCP gateway comparison

Product	Primary job	Content inspection	Auth and access control	Suited for
Docker MCP Gateway	Containerized MCP gateway with catalog and profiles	Secret blocking on by default; no injection or drift scanning documented	OAuth handling, gateway policy	Teams standardizing on Docker for MCP
agentgateway	Routing and policy for LLM, MCP, and A2A traffic; Linux Foundation project	Prompt guards (regex, PII, moderation services); MCP guardrails via an external policy server	JWT, API keys, OAuth; CEL-based RBAC and MCP authorization	Teams that want Envoy-style routing and telemetry
Lasso MCP Gateway	Security-first Python gateway	Guardrail plugins: PII masking, token masking, prompt injection, harmful content; server reputation and tool-description scanner	Simpler than infrastructure gateways	Teams focused on masking and injection with light setup
Obot	MCP and LLM gateways inside a governance platform	Inspect, reject, or modify MCP requests and responses with MCP or webhook filters	Identity-provider groups, scoped credentials, audit logs	Teams that want routing, auth, and a broader internal platform
Pipelock	Scanning proxy and agent firewall	Encoding-aware DLP, injection normalization, tool fingerprinting and drift, A2A, across mediated MCP, HTTP, and WebSocket	Tool policy via config; not multi-server RBAC	Teams that need inspection plus signed evidence

Four of these are gateways in the routing sense. Pipelock is the inspection layer that complements them.

Where the gateways are stronger

Multi-server routing. One address, one policy surface, many backends. The gateway decides which server serves which tool call.

Authentication and access control. agentgateway centralizes JWT, API keys, and OAuth and applies CEL-based rules to which tools, prompts, and resources a client can reach. Obot scopes access by identity-provider group and issues scoped credentials.

Catalog and platform workflows. Docker and Obot both manage a fleet of servers as a platform problem, with catalogs and shared configuration.

Shared control plane. A central team can roll out auth, policy, rate limits, and observability across many agents and many servers at once.

If your main problem is “how do I manage many MCP servers safely”, start with a gateway.

Where Pipelock is stronger

Tool description scanning and drift. Pipelock reads descriptions, parameter descriptions, and schemas on its mediated MCP path, which is where tool poisoning lives, and fingerprints them so a mid-session change is caught.

Argument DLP with encoding awareness. Mediated tool arguments are checked for credentials after base64, hex, and URL decoding, using the same engine that scans mediated HTTP bodies.

Response inspection through normalization. Mediated responses are scanned before they re-enter the agent’s context, with normalization passes that catch obfuscated injection.

HTTP and WebSocket coverage. Pipelock also scans HTTP and WebSocket egress routed through it, in addition to MCP.

Signed evidence. With a signing key configured, the flight recorder can emit signed receipts for mediated decisions. The verifier checks them offline against a key the operator holds.

If your main problem is “how do I stop poisoned tools, leaked credentials, and injected responses in live traffic, and prove it”, start with Pipelock.

MCP gateway vs MCP proxy

	MCP gateway	MCP proxy
Primary job	Routing, auth, access control	Content inspection
Scale model	One gateway in front of many servers	Usually one wrapper per server or upstream
What it reads	Server identity, policy metadata, and increasingly a guardrail verdict	JSON-RPC payload contents
Main failure it stops	Unauthorized or misrouted tool access	Poisoned descriptions, leaked credentials, injected responses
Examples	Docker MCP Gateway, agentgateway, Obot	Pipelock MCP proxy

Recommended deployment patterns

One MCP server, high sensitivity. Start with Pipelock. The risk is in what the server returns, not in routing.

Many servers, shared identity and policy. Start with a gateway. Centralized auth and routing come first.

Production with sensitive data. Run both. Gateway in front for routing and access control; Pipelock on the traffic path for inspection and receipts.

Developer laptops on Docker Desktop. Docker MCP Gateway provides a local Docker workflow for centralizing servers. Add Pipelock when you need inspection as well as isolation.

When to use both

Agent -> MCP gateway -> Pipelock MCP proxy -> MCP server

The gateway answers which agent this is, which server and tool it may reach, and what quota applies. Pipelock answers whether the tool description is safe to show the model, whether the arguments leak credentials, whether the response tries to inject instructions, and records the answer.

“Gateway versus proxy” is usually the wrong buying question. The better one is which layer you’re missing today.

Sources checked

Third-party descriptions on this page come from the public materials below, read on the dates shown. Features and pricing change; check the current documentation before you decide.

docker/mcp-gateway README checked 2026-09-01
agentgateway README checked 2026-09-01 · a Linux Foundation project; v1.5.0 released August 2026
agentgateway docs index (prompt guards, MCP guardrails, MCP authorization) checked 2026-09-01
lasso-security/mcp-gateway README checked 2026-09-01
Obot documentation checked 2026-09-01
obot-platform/obot LICENSE checked 2026-09-01

Third-party product names and marks belong to their owners. PipeLab is not affiliated with, sponsored by, or endorsed by the makers of any product compared on this page. Descriptions of other products come from their own public materials on the dates listed above and reflect PipeLab's reading of them. If something here is wrong or out of date, tell us and it will be corrected.

Frequently asked questions

What is the best open source MCP gateway?

The right gateway depends on the job. Docker MCP Gateway provides container isolation and local Docker workflows. agentgateway provides routing, auth, CEL-based authorization, prompt guards, and an MCP guardrail hook. Lasso’s gateway lists guardrail plugins and a server scanner. Obot bundles an MCP gateway into a governance platform with request and response filters. If you need payload inspection across MCP, HTTP, and WebSocket, route that traffic through Pipelock and configure signed receipts where you need them.

Is Pipelock an open source MCP gateway?

Not in the routing sense. Pipelock is an open-source agent firewall and MCP proxy. It wraps a server or an MCP HTTP upstream, scans mediated tool descriptions, arguments, and responses, covers routed HTTP and WebSocket egress, and can emit signed receipts when a signing key is configured. It complements gateways rather than replacing their routing and access-control role.

Do I need an MCP gateway or an MCP proxy?

If you need to route across many servers, centralize auth, or apply tool-level access rules, start with a gateway. If you need to inspect what is inside tool descriptions, arguments, and responses, add a scanning proxy. A deployment that cares about both access control and payload content needs both.