I’m building Pipelock, an open-source agent firewall that sits between AI agents and the internet. It mediates HTTP, WebSocket, and MCP traffic and blocks secret leaks, prompt injection, SSRF, and unsafe tool calls. I also maintain Agent Egress Bench, a tool-neutral public attack corpus for testing agent-security controls, and Pipelock Rules, a community repository for signed detection content. The common thread is making agent security measurable instead of asking people to trust a product page.

I was building AI agents to automate scheduling, dispatch, and back-office work for a plumbing business. Those agents had shell access, API keys, and unrestricted network access. One poisoned response or bad instruction could send credentials straight out of the environment. I looked for something that sat between the agent and the internet and enforced policy independently of the agent. I could not find the boundary I wanted, so I started building it. Pipelock began as a homelab fix for a real operational problem and grew into a public security project.

I originally thought detection quality was the main problem. Better patterns would catch more attacks. That matters, but detection without an enforceable boundary is still advice the agent can ignore or bypass. The harder and more important problem is placing policy at the point of action, failing closed when the system cannot decide, and producing evidence outside the agent’s trust boundary. That changed Pipelock from a scanner into an agent firewall.

The CNCF Landscape listing was one of those moments. Pipelock had moved from something I built for my own environment into a public project that other people could place in the broader security ecosystem. The stronger signal came from people testing it, filing specific issues, and asking how to use it with their own agents. They were no longer reacting to an idea. They were depending on behavior, finding edge cases, and expecting the boundary to hold.

Distribution and trust. Security infrastructure asks people to put a new component in a sensitive part of their system. A technically correct tool still has to earn the right to sit there. I’m working on making that evaluation easier through public attack cases, reproducible benchmarks, signed evidence, clear limitations, and demos people can verify themselves. The challenge is helping the right people discover that proof without turning the project into empty security marketing.

Start with a problem you have personally touched. You will make better decisions when you understand what breaks, who feels the pain, and what a useful fix looks like. Then publish evidence, not just claims. Show the test, the failure case, the limitation, and the result. Shipping matters, but shipping is not distribution. Keep explaining the problem from different angles after launch day instead of expecting one announcement to carry the whole project.