Vendor comparison

Pipelock vs Lakera Guard

Agent-external attestation vs inference-boundary classification. Different trust boundaries, different evidence.

Want the runtime boundary, not just another checklist?

Pipelock vs Lakera Guard is a comparison across trust boundaries. Pipelock emits mediator-signed action receipts from outside the agent trust boundary, scanning HTTP, MCP, and WebSocket egress. Lakera Guard is an inference-boundary classifier API that Check Point acquired in September 2025 and now ships as part of their AI security platform. One protects the actions the agent takes. The other protects the conversation with the LLM.

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.

Lakera Guard is a runtime classifier API for LLM applications, now part of the Check Point security platform after the September 2025 acquisition. The integration shape is a POST to /v2/guard on each LLM interaction: the application sends the raw user input (and optionally the model’s response) and Lakera returns classification verdicts for prompt injection, data leakage, jailbreaks, toxic content, and multilingual or multimodal attacks. The default deployment is SaaS; enterprise customers like Dropbox run the same logic as a Docker container inside their own infrastructure.

Pipelock inspects what the agent sends and receives over the network. Lakera Guard classifies what the application sends to and receives from the model.

Feature comparison

FeaturePipelockLakera Guard
ArchitectureNetwork proxy (single binary, self-hosted)Classifier API (SaaS, with enterprise Docker option)
Primary enforcement pointAgent egress: HTTP, HTTPS, CONNECT, WebSocket, MCP stdio, MCP HTTP/SSEInference boundary: prompts into the LLM, completions out of it
HTTP egress scanningYesNo
WebSocket frame scanningYesNo
MCP awareness (tools, args, responses)Yes, bidirectionalNot documented in public docs
DLP / credential pattern matching48 built-in patterns with 6-pass encoding normalizationData-leakage classifier on prompt and completion content
Prompt injection detection25 deterministic patterns plus 6-pass normalizationML classifier, continuously updated against Gandalf crowd-sourced attacks
Tool poisoning and rug-pull detectionYesNot applicable (no MCP surface)
SSRF and private-IP blockingYes, before DNS resolutionNot applicable
Detection approachDeterministic regex plus normalization passesModel-based classifier
Per-decision signed evidenceMediator-signed action receipts plus flight recorderVerdict JSON in API response; application logs it
Compliance mappingsOWASP MCP Top 10, OWASP Agentic Top 15, NIST 800-53, EU AI Act, SOC 2OWASP LLM Top 10 (cited in OWASP 2025 landscape guide)
Process sandboxYes (Landlock, seccomp, netns on Linux)No
Source availabilityOpen source (Apache 2.0 core)Closed source, commercial
Self-hostedYes (standard deployment)Enterprise Docker only; default is SaaS
Model-agnosticYes (any agent, any LLM)Yes (any model)
PricingFree (Apache 2.0); Pro starts at $49/moContact sales (Check Point enterprise pricing)

When to pick Pipelock

Your threat model extends past the LLM call. Agents that call MCP servers, fetch web pages, open WebSockets, or make arbitrary HTTP requests take actions that a classifier on prompt and completion I/O cannot see. A tool call to rm -rf / does not traverse the LLM API at execution time. A leaked AWS key in a POST body does not either. Pipelock scans the traffic the agent actually emits.

You need MCP-specific awareness. Pipelock parses MCP framing, detects poisoned tool descriptions, flags rug-pull drift when a previously trusted tool changes its schema mid-session, and scans tool call arguments and responses bidirectionally. Lakera Guard does not operate on the MCP surface.

You want deterministic enforcement and offline-verifiable evidence. Pipelock’s detection patterns are open source; every match is reproducible from the same input. Every blocked decision can emit a mediator-signed action receipt that an external verifier (including the published Python verifier in pipelock-verify-python) can validate without running Pipelock. Classifier decisions are harder to reproduce and harder to audit after the fact.

You want to run the entire security stack yourself. Pipelock is a single Go binary under Apache 2.0. No SaaS account, no API keys to the vendor, no telemetry to a third party. The Docker option Lakera offers is enterprise-gated; the default posture is SaaS.

When to pick Lakera Guard

Your application shape is a chatbot, a RAG pipeline, or a copilot that talks to an LLM API. The control point that matters is what enters the model and what leaves it. Lakera Guard is purpose-built for that boundary, and one API call in front of each LLM interaction is a clean integration shape.

You value continuously-updated classifier coverage over deterministic patterns. Lakera’s detection is updated from Gandalf, their crowd-sourced jailbreak game. When novel injection wording appears in the wild, the classifier absorbs it without requiring a rule rewrite on your side.

You already run Check Point for network security. After the September 2025 acquisition, Lakera Guard is positioned as part of a broader Check Point platform. If your security team is a Check Point shop, the vendor consolidation story is a real buyer consideration.

You need sub-50 ms latency on prompt classification. Lakera publishes sub-50 ms latency for classifier calls. Any content-inspection proxy, including Pipelock, adds more latency because the inspection work is deeper.

Architecture differences

Pipelock and Lakera Guard answer different questions.

Lakera Guard asks: is this prompt or completion safe to pass through the LLM boundary? The answer comes from a classifier trained on real-world attacks. The integration point is the application code that talks to the model: the application makes a POST to /v2/guard before and after each LLM call, and the verdict gates the conversation. Anything that does not traverse the LLM API (direct tool calls, MCP traffic, arbitrary HTTP egress) 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 HTTP, WebSocket, and MCP. Every outbound request body gets checked for leaked credentials. Every MCP tool description gets checked for poisoning and drift. Every response coming back gets checked for prompt injection patterns across six normalization passes. SSRF checks run before DNS resolution so DNS queries cannot be used to exfiltrate secrets.

These are different enforcement points. A deployment that cares about both the model conversation and the agent’s actions downstream of the model can run both. Lakera Guard guards the LLM boundary. Pipelock guards everything after.

A note on evidence

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

Lakera Guard returns a verdict in the API response. The calling application can log it. The application holds the record, and the application can also choose not to log it.

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 the application code. The format is open and pairs with a separate reference Python verifier (pipelock-verify-python) 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 April 2026. Features and capabilities may change. Check each project’s current documentation for the latest.

Further reading

Frequently asked questions

What's the difference between Pipelock and Lakera Guard?
Pipelock is an open-source agent firewall that scans HTTP, WebSocket, and MCP traffic between an agent and the internet for credential leaks, prompt injection, SSRF, and tool poisoning. Lakera Guard is a classifier API that Check Point acquired in September 2025; it sits between the application and the LLM, classifying prompts and completions for prompt injection, data leakage, jailbreaks, and toxic content. Different enforcement points, different evidence.
Does Lakera Guard scan MCP or HTTP egress traffic?
Lakera Guard integrates via a POST to /v2/guard on each LLM interaction. Its control surface is the prompt going into the model and the completion coming out. Tool calls, MCP traffic, and arbitrary HTTP egress that do not traverse the LLM API are outside that surface. Pipelock scans HTTP, WebSocket, and MCP traffic bidirectionally and operates on the agent’s network egress, not the LLM conversation.
Can I use Pipelock and Lakera Guard together?
Yes. They enforce at different boundaries. Lakera Guard protects the model conversation: what the application sends to the LLM and what the LLM sends back. Pipelock protects the agent’s actions downstream of the model: the HTTP requests, the MCP tool calls, the WebSocket frames. A deployment that cares about both layers runs both, with each tool doing what it is best at.

Want the runtime boundary, not just another checklist?

See all comparisons →