Pipelock

I'm a plumber who taught himself Linux and security and built this because nothing else solved the problem. Pipelock sits between an AI agent and the network and scans what it tries to send out for leaked secrets, prompt injection, and SSRF, then blocks it at the boundary. The part I care about most: when it blocks something, it writes a signed receipt you verify yourself, offline, so you don't have to take my word for any of it. There's a live challenge in the browser, run a real agent against a real attack and try to get the secret out. Come break it and tell me what you find.

Running as a single Go binary between the agent and network is a clean approach — avoids the sidecar/proxy sprawl most agent security tools introduce. The signed, offline-verifiable receipts for each allow/block decision stand out too, since most firewalls just log without giving you something you can audit independently. Have you benchmarked the added latency on MCP traffic under load?

A plumber who taught himself Linux and security is a better origin story than most decks I've read. The offline-verifiable receipts are the part I'd actually look at first. I build a self-hosted product too, so that's where I'd push. Where does the private key live? If it's mine, a receipt proves the binary decided something, but nothing stops me from quietly dropping the receipts I don't like. If the key is yours, it isn't really self-hosted anymore, and "verify against the published key" reads like it might be yours. Is there a hash chain or append-only log tying receipts together, or is each one standalone? The other thing is false positives, which nobody asks about until it bites them. Secret detection on a coding agent's egress is a classifier, and coding agents push things that look exactly like secrets all day: fixtures, base64 blobs, test keys, high-entropy hashes. What's the threshold, and can I tune it per route? A firewall that blocks one legitimate push tends to get switched off by the dev the same afternoon, and then it protects nothing. You published agent-egress-bench but there isn't a single number in the launch. Detection rate and FP rate on your own corpus would tell me more than the live challenge does, even if they're unflattering. Especially if they're unflattering. Dmitrii's latency question is still open and I'd read that answer too. For an inline egress filter that's the number that decides adoption.

There's a live challenge in the browser, run a real agent against a real attack and try to get the secret out. Come break it and tell me what you find.

AI agent security verification is becoming a critical friction point for teams deploying autonomous agents. Most organizations lack clear visibility into what agents are allowed to do, making it hard to meet compliance requirements and catch exfiltration attempts before they happen. Having an open-source firewall that runs between agents and the network, with verifiable offline decision signing, solves a real trust and audit gap. The ability to test agents against real attack patterns and measure detection effectiveness is especially valuable for teams shipping mission-critical AI agents to production.

Scanning MCP traffic specifically is the underrated part here. Most agent-security tooling stops at the prompt boundary and implicitly treats tool calls as trusted, which is backwards - egress is where the damage actually happens. One real question about the threat model: does the network-boundary approach cover stdio MCP servers? Most MCP servers people install run as a local subprocess over stdio rather than HTTP or SSE, so a firewall sitting between the agent and the network would not see that traffic at all. If you do handle stdio, say so loudly on the landing page, because that is the exposure most people actually have and it is not obvious from the runtime diagram. Signed receipts you can verify offline against a published key is a good call - Apache 2.0 plus auditable decisions is a far easier sell to a security team than a black box.

The receipts and the boundary model are the right foundation, so my question is about coverage rather than the decision layer: an egress firewall only helps for the bytes it can actually read. Two gaps worth addressing on the landing page. First, TLS — do you terminate/MITM outbound HTTPS to scan the body (and how does that interact with agents that pin certs), or are you matching on destination + metadata when the payload is encrypted? Second, and harder: exfiltration through an allowed channel. If an agent is permitted to reach a GitHub API or a Slack webhook, a secret can leave inside a perfectly legitimate request to a legitimate host — no SSRF, no odd destination, just content the classifier has to catch mid-stream. Detection vs. false-positive numbers specifically for that allowed-channel case would tell a security team more than the live challenge does.