Sandboxing AI Coding Agents: Pipelock, OpenAFW, and Aperion Shield Compared — Only One Ships an Actual Open-Source License

AI coding agents run with more standing access than almost anything else on a developer's machine: they read your .env files, they shell out to git and psql, they fetch URLs an attacker embedded in a scraped web page, and they route every one of those actions through a model provider you don't operate. There's still no protocol-level answer to "what should be allowed to happen inside that loop" — MCP defines how a tool call is shaped, not whether it should be blocked. Into that gap, three separate projects showed up within weeks of each other in 2026, each proposing a different layer of the stack as the right place to intervene: Pipelock sits on the network edge and inspects HTTP/MCP/WebSocket/A2A traffic, OpenAFW sits between the agent and the model provider and swaps real credentials for fakes, and Aperion Shield sits directly in front of an MCP server and blocks specific tool calls before they execute.

All three are worth knowing about if you're running agents against production systems. But "sandbox your AI coding agent with one of these open-source firewalls" — the framing you'll see repeated across launch coverage — turns out to be only two-thirds accurate once you read the actual license files instead of the marketing copy. That distinction isn't pedantry. If you're an EU team planning to point at one of these tools as a GDPR Article 32 "appropriate technical measure," whether you can actually read and audit the code you're running is the whole ballgame.

What these tools are actually defending against

Reading each project's own documentation (not third-party coverage) gives a consistent threat model across all three, even though they intervene at different points:

• Secret exfiltration — an agent with a valid API key or database credential gets tricked (via prompt injection in a fetched page, a poisoned MCP tool description, or a compromised dependency) into sending that secret somewhere it shouldn't go.
• SSRF and network pivoting — an agent's HTTP tool is used to reach internal services, cloud metadata endpoints, or other systems it was never meant to touch.
• Destructive tool calls — DROP TABLE, rm -rf, unscoped UPDATE/DELETE, or a forced git push landing before a human reviews it.
• Tool/MCP-server poisoning — a malicious or compromised MCP server changes its tool descriptions mid-session to smuggle instructions the agent will follow.

None of that is hypothetical at this point — it's the exact list every agent-security writeup from the past year converges on. What's new isn't the threat model; it's that self-hostable, purpose-built tooling for it now exists outside of a vendor's SaaS dashboard.

The three tools, at a glance

Pipelock: open core, with a real license split

Pipelock is the most infrastructure-heavy of the three. It runs as a proxy — forward proxy with CONNECT tunneling, an authenticated MCP listener, and an A2A inspector — and scans traffic in an ordered pipeline: URL/scheme validation, SSRF checks against literal IPs, DLP against 65 built-in secret/token patterns (matched before DNS resolution, so a lookup itself can't leak the secret), and response-side prompt-injection detection with six passes of text normalization to catch zero-width characters, homoglyphs, and base64/hex-encoded payloads. Every mediation decision can be recorded as a signed "action receipt" — verifiable offline with pipelock verify-receipt, which the project frames as "demonstration over attestation": you get cryptographic evidence of what the proxy actually blocked, not just a dashboard claiming it did.

The core scanning engine and single-agent protection are Apache 2.0 — genuinely permissive, genuinely free. But the enterprise/ directory (per-agent identity, budgets, config isolation for multi-agent deployments) is licensed under the Elastic License 2.0, a source-available-but-not-OSI-approved license that requires a paid key. Worth knowing before you deploy: the pre-built Docker images and release binaries bundle the enterprise code (dormant without a key), while a source build via go install produces a community-only binary. If your compliance team asks "is this open source," the honest answer is "the part you'll actually use for one agent, yes — the part you'd need for a fleet, no."

Self-hosting is genuinely first-class: docker pull ghcr.io/luckypipewrench/pipelock:latest, a documented Kubernetes Helm chart, and a pipelock contain install command that sets up a three-UID operator/proxy/agent isolation model with nftables routing on Linux.

OpenAFW: the one with an unambiguous license, and a naming quirk

The project most people are calling "AgentFW" (that's the GitHub repository name, openguardrails/agentfw) actually calls itself OpenAFW in its own README and ships as the npm package @openafw/openafw — worth knowing if you're searching for it later. It runs as a local reverse proxy at http://localhost:9877/wire/<agent>/..., decoding and normalizing Anthropic, OpenAI, and MCP traffic into one trace format, with support wired in for Claude Code, Codex, Claude Desktop, OpenClaw, and Hermes (Cursor and Gemini need manual proxy configuration).

Its core trick is credential masking: real API keys, wallet keys, and bearer tokens get swapped for fixed fake values before a request leaves your machine, and the real values are restored in the response — so neither the model provider nor any relay in between ever sees your actual credentials, only your own local daemon does. It also runs lightweight security detectors over decoded traffic (flagging likely secret leaks and dangerous shell commands) and does per-route model routing, including special-casing Claude Code's subagent architecture so subagent calls can be routed independently of the main orchestrator.

OpenAFW is MIT-licensed, full stop — no enterprise carve-out, no separate binary tier. Install is npm install -g @openafw/openafw; there's no cloud account, and the project states its only outbound traffic is a disableable daily npm version check. Of the three, this is the one you can hand to a security-conscious procurement reviewer without a footnote.

Aperion Shield: the license says "no source distributed" — the repo says otherwise

This is the interesting one, and the reason this comparison is worth writing instead of just repeating launch-week coverage.

Aperion Shield is a local MCP proxy: it wraps any MCP server (Postgres, filesystem, git — anything reachable via a standard MCP config block) and intercepts tool calls before they execute, using a composite scoring system across raw severity, decision memory, workspace context, and burst detection. Its 65+ adaptive rules catch DROP DATABASE/DROP TABLE/TRUNCATE and unscoped UPDATE/DELETE with tautological WHERE clauses, recursive deletes targeting root or ~/.ssh/~/.aws, force-pushes to protected branches, curl | sh-style supply-chain patterns, and compound "read a secret, then make a network call" sequences via cross-tool taint tracking. Wrapping an existing MCP server is a one-line change — in Cursor's ~/.cursor/mcp.json, "command": "aperion-shield", "args": ["--", "npx", "-y", "@modelcontextprotocol/server-postgres", "postgres://..."] puts Shield in front of the Postgres MCP server with no changes to the server itself.

Here's the catch. The project's own LICENSE file, quoted directly: "This software is distributed only in compiled (object/container) form. No source code is licensed or provided under this agreement." It's a proprietary binary license — non-exclusive, revocable, forbids redistribution as a competing product and forbids reverse engineering "except to the extent applicable law expressly permits," governed by Texas state law. That's the opposite of open source by any OSI definition.

And yet the same repository's README says, in the license section itself, "Proprietary — binaries and images only, no source distributed" — directly followed a few paragraphs later by full git clone/cargo build --release instructions for building Shield from the Rust source that's sitting right there in src/, including the org-mode client code. The two statements in the same document contradict each other: the license text says no source is provided, and the same repo hands you the source and tells you how to compile it. Read charitably, the maintainers want the code auditable (there's an explicit note that "the code does not initiate any outbound traffic... until --enroll has been run") while reserving the legal right to distribute compiled binaries under stricter terms for anyone who isn't building from that source themselves. Read less charitably, it's a license mismatch nobody's cleaned up yet. Either way: don't take a launch post's "free, open-source" description at face value here — go read the LICENSE file, because in this specific case it says something narrower than the marketing.

Why the license actually matters for GDPR, not just for principle

If you're self-hosting one of these tools and want to point at it as evidence of an "appropriate technical measure" under GDPR Article 32, the license isn't a side issue. Article 32(1) requires controllers and processors to implement measures ensuring, among other things, "the ongoing confidentiality, integrity, availability and resilience of processing systems" (32(1)(b)) and "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing" (32(1)(d)). That second requirement is where source-inspectability stops being a philosophical preference: you can meaningfully test and audit the effectiveness of Apache-2.0-licensed Pipelock or MIT-licensed OpenAFW by reading exactly what the DLP patterns and credential-masking logic do. With a compiled-binary-only license — even one where the source happens to be visible in the repo, as with Shield — your right to actually verify that behavior against the binary you're running is legally narrower, and a reverse-engineering prohibition (even one qualified by "except as applicable law permits") sits awkwardly next to "regularly testing... the effectiveness" of a control you can't fully take apart. None of this means proprietary security tooling is unusable for GDPR purposes — plenty of controllers rely on closed-source firewalls and DLP products today — but if the whole appeal of "sandbox your agent with an open-source firewall" was auditability, only two of these three actually deliver on that specific promise.

A minimal self-hosted setup

If you want the actually-open-source pairing — network-edge scanning plus credential masking — running against agents on your own infrastructure:

# OpenAFW: local credential-masking proxy for the agent↔provider hop
npm install -g @openafw/openafw
openafw start   # listens on localhost:9877/wire/<agent>/...

# Pipelock: network-edge scanning for HTTP/MCP/WebSocket traffic
docker run -d --name pipelock \
  -p 8080:8080 \
  ghcr.io/luckypipewrench/pipelock:latest

Point your agent's outbound HTTP/MCP calls through Pipelock and route provider API calls through OpenAFW's local wire proxy, and you've got DLP + SSRF + prompt-injection scanning on one side and credential masking on the other — both under licenses you can actually read end to end, both running on a VPS you control rather than a vendor's SaaS. If a specific MCP server (a database, a filesystem tool) needs tool-call-level blocking on top of that, Shield's rule engine is still useful — just go in with clear eyes about what its license does and doesn't grant you.

There still isn't a standard

None of this is a substitute for the protocol itself defining a permission model — MCP doesn't currently mandate anything like a capability system, and every one of these three tools exists specifically because that gap hasn't been filled upstream. Until it is, "sandbox your coding agent" means picking one or more of these bolt-on layers yourself, reading the license before the launch post, and treating "open source" as a claim to verify rather than a badge to trust.

See also: Chatto's crypto-shredding pattern for another case where a project's own docs revealed more nuance than the press coverage did, and the MCP stateless spec and CRA Article 13 for what self-hosting an MCP server itself involves under EU vulnerability-handling rules.