pipelock: an open source AI agent firewall that signs what it blocks

What problem pipelock solves, and for whom

An agent with $PROVIDER_API_KEY in its environment and shell access can leak that key in a single request. The README's own example is a curl call that puts the key in a query string, and the comment next to it says "game over, unless pipelock is watching". That is the whole premise: every machine action an agent takes should cross a boundary between your secrets and the open internet, and pipelock is meant to be that boundary.

The audience is narrow and technical. You need agents that already run through something you control: a proxy, an MCP wrapper, a sandbox, a host containment model, or a cluster deployment topology. The README lists Claude Code, OpenAI Codex, Cline, OpenCode, Zed, Cursor, VS Code, JetBrains, the OpenAI Agents SDK, Google ADK, AutoGen, CrewAI and LangGraph as integrations. If your agent talks directly to the internet from a laptop you cannot intercept, pipelock has nothing to stand on.

The second audience is the reviewer rather than the operator. The project's distinguishing claim is that a person outside the agent runtime can verify what the boundary decided, using a receipt and a public key, with no account and no server. That is a different product from a scanner that reports findings into a console.

How the mediation and receipt chain actually work

pipelock sits between the agent and the network and 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 only, which is a real ceiling: without interception you see where the connection goes, not what it carries.

On the detection side the README names secret exfiltration, prompt injection, SSRF, tool poisoning and risky tool-call chains. The decision is content-aware, and the output is a mediator-signed action receipt. The receipt records the boundary decision and the key holder's signature over it, so verification happens outside the agent runtime rather than inside it.

The honesty notes in the README matter more than the feature list. The demo signs with an ephemeral key it prints for the run, so those receipts prove self-consistency rather than a named identity. The operator running pipelock 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. pipelock anchor receipts records receipt-chain checkpoints to a local backend or a Rekor transparency log, and the README states that operator-independent verification against that anchor is still being proven end to end. Anyone evaluating this for compliance should read that sentence twice before treating receipts as third-party attestation.

The repository layout backs the architecture: internal/ holds the engine, cmd/pipelock is the CLI entry point, schemas/ and configs/ carry configuration and receipt shapes, and charts/ plus deploy/ cover cluster installation. The Go module pulls in go-jose for signing, gobwas/ws for WebSocket handling, go-spiffe for workload identity, modernc.org/sqlite, and Prometheus and OpenTelemetry clients, which is consistent with a proxy that signs decisions and exports metrics.

Install pipelock and run a first check

The README's primary install path is from source with Go 1.25 or later. The go install command fetches the CLI directly from the module path.

# Install from source (Go 1.25+)
go install github.com/luckyPipewrench/pipelock/cmd/pipelock@latest

Alternatives listed in the README are a downloaded binary from the releases page, a container image at ghcr.io/luckypipewrench/pipelock:latest, and a Homebrew tap on macOS. Note that the Dockerfile in the repository builds with Go 1.27.0 and fails the build on a toolchain mismatch, while go.mod declares go 1.25.0; if you build the container yourself, the pinned base image is the constraint that matters.

After installing, generate a configuration and wire up local agent integrations:

pipelock init

The first real use is the scanner check, which needs no agent at all. The README shows one URL that should be blocked and one that should be allowed:

pipelock check --url "https://evil.com/?k=AKIAIOSFODNN7EXAMPLE"  # blocked: AWS Access ID
pipelock check --url "https://docs.python.org/3/"                # allowed

If the first command is allowed, your detection rules are not loading and nothing downstream is worth testing yet. There is also a live playground at pipelab.org if you want to see the scanner behave before installing anything.

Verify a receipt offline before you trust the pipeline

The demo is the fastest way to see the evidence format, and it needs no config and no network. According to the README it fires real attack scenarios, blocks them, and writes seven signed receipts plus the public key to disk.

pipelock demo --receipts-dir ./out
pipelock verify-receipt "$(ls ./out/*.json | head -1)" --key ./out/signer.pub

Each receipt is named after its action id, so the glob picks one arbitrarily. The verification step checks the signature against the key in the same directory, which is why the README calls this self-consistency rather than identity. To get receipts tied to a named identity you need the playground path, which verifies against a key pipelock publishes.

For a real run, the flight recorder is the mechanism. init names a recorder directory and generates its signing key, run records while your agent works, and the evidence viewer produces a static offline report or serves the same report read-only.

pipelock init --output ./pipelock.yaml
pipelock run --config ./pipelock.yaml
pipelock evidence view --receipt-dir ./recorder --out report.html
pipelock evidence serve --receipt-dir ./recorder

The README states that the evidence viewer is free and needs no license. That distinction matters because the repository carries an enterprise/ directory and a Dockerfile.license-service alongside the Apache-2.0 LICENSE, so some capability is gated. The README does not document which features sit behind that gate beyond the viewer being free.

Where pipelock stops protecting you

The sharpest limitation is stated by the project itself: the operator holds the signing key. A receipt proves what the boundary decided and that the key holder signed it. It does not prove the operator is honest, and it does not cover anything that happened outside the boundary pipelock mediates. If your threat model includes the person running the firewall, signed receipts from that person are not the control you need.

The second limitation is coverage. Without TLS interception, CONNECT tunnels are scanned only at the hostname and URL level. An agent that exfiltrates a secret in an encrypted request body to an allowed host will not be caught by content inspection on that path. Enabling interception changes your certificate story for every client on the boundary, and the README does not document rollback for that configuration.

The third is verification maturity. Anchoring to a local backend or a Rekor transparency log exists as a command, but the README says operator-independent verification against the anchor is still being proven end to end. Treat the anchor as a checkpoint mechanism you are testing, not a finished audit control.

Finally, the Gauntlet workflow is described as the product's scheduled candidate exam against a pinned corpus commit, and the README says it does not auto-publish a public score. There is a public agent-egress-bench corpus that exercises the detections, but the README does not present published results from it. If you need third-party detection numbers before adopting, this project does not hand them to you.

pipelock compared with LlamaFirewall and gateway proxies

LlamaFirewall is the comparison people search for, and the difference is architectural rather than a feature count. LlamaFirewall is a guardrail layer inside the agent stack: you call it from your agent code and it returns a verdict on a prompt, a plan or an output. pipelock is out-of-process. It mediates traffic the agent sends, so the agent does not have to cooperate with the check and does not see the decision path. That is stronger against a compromised or prompt-injected agent, and useless if you cannot route the traffic.

Against a conventional egress proxy or API gateway, the difference is the evidence model. A gateway logs requests and applies allowlists. pipelock adds content-aware inspection for exfiltration patterns, prompt injection, SSRF and tool poisoning, and it signs the decision so a reviewer can check it offline with a key they hold rather than querying the operator's log store. The gateway comparison is also where the trade-off bites: pipelock needs to understand MCP and A2A semantics, which means more configuration surface than a hostname allowlist.

If your agents already run behind an MCP wrapper or in a cluster, pipelock fits into the topology you have. If your only control point is application code, a library-level guardrail is the realistic choice and pipelock is the wrong tool.

Maintenance, licensing and upgrade cost

The repository is not archived. The last push was on 2026-08-20, the same day v3.4.0 was released, following v3.3.0 on 2026-07-31 and v3.2.0 on 2026-07-17. That is a roughly monthly release cadence across the three most recent tags, and the changelog plus release directory in the repository are where the upgrade notes live. The README does not document a rollback procedure for a bad upgrade, so pin a version, keep the previous binary, and read CHANGELOG.md before moving.

Upgrade cost has one sharp edge worth planning for: the Dockerfile asserts the Go toolchain version literally and exits the build on a mismatch, with a comment explaining that a build argument could be overridden and therefore cannot be trusted for the check. If you build the image yourself rather than pulling ghcr.io/luckypipewrench/pipelock:latest, a base image tag change requires editing the tag, the digest and the literal expectation together. That is deliberate friction, not an accident.

Licensing: the repository is Apache-2.0, and the LICENSE file is at the root. A separate enterprise/ directory and Dockerfile.license-service exist, so not everything in the tree is necessarily under the same terms. The README states the evidence viewer is free and needs no license, which implies other parts may not be. Read both LICENSE and enterprise/LICENSE before shipping anything commercially; this is a description of what is in the repository, not legal advice.

Editorial conclusion

Adopt pipelock if your agents run with real credentials and shell access and you need evidence of what crossed the boundary, not a dashboard you have to trust. Skip it if you cannot route agent traffic through the proxy, MCP wrapper, sandbox or cluster topology it needs, or if you expect the receipts to prove the operator is honest, which the README says they do not. Before rollout, run pipelock demo --receipts-dir ./out and verify one receipt with the printed signer.pub, then decide whether a local backend or a Rekor anchor is required for your audit trail.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes