Pipelock vs iron-proxy

Pipelock vs iron-proxy is content scanning vs boundary secret rewriting. Two open-source Go proxies solving agent egress from different angles.

The short version

Pipelock is an open-source network proxy. It scans HTTP, MCP, and WebSocket traffic for credential leaks, prompt injection, SSRF, and tool poisoning. Runs locally as a single binary. Works with any agent whose traffic is routed through it.

iron-proxy is an open-source Go egress firewall for AI agents, created by mslipper. Its core approach combines a domain allowlist with boundary secret rewriting: the proxy holds the real secrets, and the sandbox only ever sees placeholder tokens that get rewritten on the way out. That means a compromised sandbox cannot leak real credentials because it never had them.

Pipelock inspects content. iron-proxy protects credentials at the identity boundary. Same transport (Go egress proxy), different threat model focus.

Feature comparison

When to pick Pipelock

You want content inspection across HTTP, WebSocket, and MCP. Pipelock scans outbound requests for 48 credential patterns (base64, hex, and URL encoding aware) and runs 25 injection patterns through 6 normalization passes on scanned responses. Tool descriptions and tool call arguments get the same treatment. If your threat model includes prompt injection, tool poisoning, or data exfiltration hidden inside request bodies, that content inspection layer matters.

You need MCP-specific awareness. Pipelock parses MCP framing, scans tool descriptions for poisoning, detects rug-pull drift when a previously-trusted tool changes its prompt, and inspects tool call arguments and responses. Agents using Claude Code, Cursor, or Codex with MCP servers get that protection automatically once routed through the proxy.

You want SSRF protection out of the box. Pipelock blocks requests to private IP ranges, cloud metadata endpoints, and link-local addresses, with DNS rebinding protection baked in. Whether iron-proxy’s DNS layer applies similar protections is not documented in public docs.

When to pick iron-proxy

Your primary concern is credential exposure inside the sandbox. iron-proxy’s boundary secret rewriting is a genuinely different approach. The proxy holds the real API keys and tokens. The sandbox (or agent process) gets a placeholder. When the agent makes an outbound request, the proxy swaps the placeholder for the real secret on the egress path. A compromised sandbox cannot leak real credentials because it never had them. Pipelock does not do this.

You want a focused, minimal egress firewall. iron-proxy is scoped tightly around domain allowlisting and boundary secrets. If that covers your threat model and you want something small to audit and run, the focused scope is a feature, not a limitation.

You are building an identity-first sandbox model. If your architecture already treats the agent sandbox as untrusted and wants the proxy to be the trust anchor for credentials, iron-proxy’s model maps directly to that design. The placeholder-token pattern is the feature you are shopping for.

Architecture differences

Pipelock and iron-proxy answer different questions.

iron-proxy asks: How do we stop the sandbox from ever seeing real secrets? iron-proxy acts as a TLS-terminating proxy with full payload visibility, not just SNI inspection. The primary answer is boundary secret rewriting. The sandbox runs with fake tokens. Every outbound request passes through the proxy, which substitutes real credentials at the edge. A malicious tool response or compromised process cannot exfiltrate what the sandbox does not hold.

Pipelock asks: What is actually in the traffic flowing through? The answer is content scanning. Every request body gets checked for leaked credentials, encoded secrets, and prompt injection. Every tool description and tool response gets checked for poisoning. SSRF attempts get blocked at the resolver.

These are compatible designs. iron-proxy protects credentials by never letting them reach the sandbox. Pipelock protects against injection and data leaks by inspecting what moves across the wire. You can run both, with iron-proxy handling the credential boundary and Pipelock handling content inspection.

Third-party feature descriptions are based on public materials reviewed in April 2026. Features and capabilities may change. Check each project’s current documentation for the latest.

Further reading

• Pipelock : the full product page
• What is an agent firewall? : full 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
• iron-proxy on GitHub
• Pipelock on GitHub