Pipelock vs iron-proxy

The short version

Pipelock is an open-source agent firewall. It scans HTTP, WebSocket, and MCP traffic routed through it for credential leaks, prompt injection, SSRF, and tool poisoning, and can emit signed action receipts for mediated decisions when a signing key is configured.

iron-proxy is an open-source egress proxy for AI agents. Its core idea is boundary secret rewriting: the proxy holds the real secrets, the sandbox only ever sees placeholder tokens, and the proxy swaps them in at egress. A compromised sandbox can’t leak a credential it never had. Around that core it has grown a domain allowlist, TLS-terminating inspection, MCP tool authorization, a policy model it calls the LLM Judge, and a fleet control plane. The repository moved to the paradigmxyz GitHub organization; the old path redirects.

iron-proxy answers “may this leave, and with which credential?” Pipelock answers “what is in this traffic, and can I prove what I decided?” The two overlap more than they used to, and they still answer different questions.

Where they overlap now

iron-proxy’s recent releases moved onto surfaces Pipelock has covered for a while. MCP is first-class: a default-deny tool allowlist, tools/call denials returned as JSON-RPC errors, and tools/list filtering so denied tools never reach the agent’s catalog. The LLM Judge transform asks a model for an allow or deny decision on outbound HTTP requests. The control plane handles enrollment, fleet policy, and audit search.

So the distinction is no longer that one does MCP and the other doesn’t. It’s the kind of MCP control. iron-proxy decides which tools may be called. Pipelock reads the tool descriptions, arguments, and responses and looks for poisoning, drift, and injection. A serious MCP deployment wants both.

Feature comparison

When to pick Pipelock

You want content inspection across HTTP, WebSocket, and MCP. Pipelock scans outbound URLs, headers, and bodies for 65 credential patterns, decoding base64, hex, and URL encoding first, and runs injection patterns through several normalization passes on scanned responses. Tool descriptions and arguments get the same treatment. If your threat model includes a poisoned tool description or a secret hidden in a request body, this is the layer that sees it.

You need MCP content awareness. Pipelock fingerprints tool descriptions, flags rug-pull drift when a trusted tool changes mid-session, and inspects arguments and responses. iron-proxy’s MCP feature decides which tools may run; it does not read what they say.

You need evidence, not just logs. With a signing key configured, Pipelock can emit signed receipts for mediated decisions. An auditor can verify the chain offline against your published key without trusting the proxy’s own logs. iron-proxy’s audit search is a log you read through its control plane.

When to pick iron-proxy

Your first worry is credential exposure inside the sandbox. Boundary secret rewriting is a different design. The proxy holds the real keys, the sandbox gets a placeholder, and the swap happens at egress. Pipelock doesn’t do this; it relies on deployment isolation to keep the proxy and the secrets apart.

You want default-deny egress with credential brokering. iron-proxy mints and injects OAuth tokens, JWT bearer assertions, and cloud service-account credentials per request from a secrets manager. If the shape you’re shopping for is “the agent never touches a real credential”, that’s this project.

You already treat the sandbox as untrusted and want the proxy to be the trust anchor for credentials. The placeholder-token pattern maps directly onto that design.

Architecture differences

iron-proxy asks: how do we stop the sandbox from ever seeing real secrets? It terminates TLS for ordinary HTTP so it can rewrite headers, relays WebSocket and server-sent-event streams natively, with no frame-level inspection documented, and substitutes real credentials at the edge. A malicious response or a compromised process can’t exfiltrate a credential the sandbox never held.

Pipelock asks: what is moving across the mediated boundary, and can I prove what I did about it? Routed request bodies are checked for leaked or encoded secrets, routed tool descriptions for poisoning, scanned responses for injection, and SSRF is checked before DNS resolution. With a signing key configured, Pipelock can emit signed receipts for mediated decisions.

These compose. Put iron-proxy at the credential boundary and Pipelock on the content path.

Two implementation notes, stated fairly

iron-proxy’s credential injection is fail-open by default. In the OAuth transform, require defaults to false, and the source comment says a mint failure is logged and the request is forwarded without the token so one broken credential doesn’t take down every matching request. That’s a defensible availability choice, and you can set require: true per entry. It’s worth knowing before you rely on the swap as a security boundary. Pipelock’s mediated enforcement paths fail closed: a timeout or a parse failure blocks the request, and the block is receipted.

iron-proxy’s payload inspection applies to ordinary HTTP request paths. Its README describes WebSocket upgrades as proxied natively as streams, and no frame-level inspection is documented for that path. Pipelock scans WebSocket frames in both directions.

Neither note is a defect. They’re design choices, and a default can change in one commit, which is why the sources below carry dates.

Further reading

• Pipelock: the product page
• What is an agent firewall?: definition and evaluation checklist
• Agent egress security: why egress is the control point for agents
• AI egress proxy: how egress proxies fit into agent security
• Pipelock vs open source MCP gateways: the routing-gateway side of the same question
• Pipelock on GitHub