security
May 4, 2026
By Teun
Pipelock launches open-source firewall for AI agents and MCP traffic
Pipelock is an open-source security harness that sits between AI agents and the network. It scans HTTP, WebSocket, MCP stdio, and Google A2A traffic, enforcing rules from a RULES.md file. Ships as a single 20MB Go binary under Apache 2.0.
Pipelock has launched an open-source firewall built for AI agents and MCP traffic, aiming to give operators a way to control what agent-driven systems can send and receive on the network. According to the company, the tool sits between an AI agent and the outside world, where it inspects traffic and applies policy before requests are allowed through.
The project is designed for environments where agents are not just making chat-style requests, but are actively connecting to tools, services, and local processes. That matters because modern AI agents often use multiple communication paths at once, including HTTP, WebSockets, MCP stdio, and Google A2A traffic, which makes the attack surface broader than a simple web API.
⚡ New to this?
This is a security tool for AI agents, which are programs that can do tasks like calling APIs, using tools, or talking to other systems without a person clicking every step. MCP, or Model Context Protocol, is a standard that helps agents connect to tools and data, so it needs the same kind of access control as any other networked software.
A firewall is a control that decides what traffic is allowed in or out. Non-experts should care because AI agents can hold secrets, like API keys, and if they can talk to networks freely, they can also make unsafe requests or pass data where it should not go.
🦞 OpenClaw angle
If you run AI agents with shell access and API keys in environment variables, Pipelock addresses a real gap. It separates the agent process (holds secrets, no network) from the proxy (has network, no secrets), scanning everything that crosses the boundary.
MCP, short for Model Context Protocol, is a standard used to connect AI models and agents to external tools and data sources. A2A, or agent-to-agent communication, is another emerging pattern for letting automated systems talk directly to one another. Pipelock is meant to watch those channels and enforce security rules before they reach the network.
The company says the firewall uses a RULES.md file to define what is allowed. That setup gives teams a human-readable policy layer, instead of burying controls inside application code or scattered infrastructure settings. In practice, that can make it easier to review, update, and version the rules that govern what an agent may do.
Pipelock is shipped as a single 20MB Go binary and released under the Apache 2.0 license. The small binary footprint is a practical detail, since security tools that are simple to deploy tend to be easier to slot into local development, containers, and server environments without a lot of extra packaging.
The design also reflects a common security concern in agent deployments: the agent process itself often needs secrets such as API keys, but should not necessarily have unrestricted network access. By separating the agent from the network-facing component, Pipelock aims to create a boundary where traffic can be inspected before it leaves the system.
That kind of boundary is becoming more relevant as organizations move beyond single-purpose automation and start giving agents access to shells, internal APIs, and third-party services. Once an agent can act on a user’s behalf, the main question is no longer just what it can generate, but what it can reach.
Open-source licensing is another part of the pitch. Apache 2.0 is widely used in infrastructure software because it permits commercial use and modification, which can make adoption easier for teams that want to inspect the code or build on top of it.
Pipelock arrives as security teams are increasingly asked to treat AI agents less like chat interfaces and more like software components with network permissions, traffic patterns, and policy requirements of their own. The project’s core idea is straightforward: monitor the paths an agent uses, and decide what crosses the line before it leaves the box.
