Comparison: Pipelock vs Other Agent Security Tools#

An honest matrix anchored on enforcement and evidence provenance, with a feature-level appendix below.

Enforcement and Evidence Provenance (May 2026)#

The 2026 agent-security field splits along three independent axes: where the decision is computed, where it is enforced, and what evidence artifact the system emits. The matrix below locates current peers on those axes. The narrative after the table covers the nuance, and the per-feature appendix further down preserves the earlier comparison against AIP / agentsh / srt for continuity.

Why three location fields, not one. A Guardian's decision (where the allow/deny/modify is computed) is logically independent from its enforcement (where the decision is applied) and from its evidence profile (what the receipt cryptographically proves). Conflating them lets a tool claim provenance properties it cannot deliver. The matrix lists each axis separately so the receipt's strength is auditable in the same units Pipelock intends to propose for Agent Control Standard verdicts.

The cooperative-vs-non-cooperative distinction. As Pipelock's maintainer told Help Net Security in May 2026:

"Most agent-security tools still need the agent to cooperate."
— Joshua Waldrep, Help Net Security, May 4 2026

The article's point was that SDKs, decorators, middleware, and wrapper APIs only work while the agent keeps calling them. The provenance matrix makes that distinction precise. In-process SDKs (Cupcake, AgentMint, AGT) make decisions and emit artifacts while the agent cooperates; sidecar / network-mediator / kernel-boundary tools (Pipelock, CAPSEM, Signet) emit stronger evidence for mediated traffic from outside the agent process. Both have their place. The receipt's decision_location and enforcement_location fields tell you which you're looking at.

Boundary honesty. Pipelock receipts prove what Pipelock mediated. Traffic outside Pipelock's control point — direct egress in deployments without containment, processes Pipelock did not intercept — does not appear in receipts and is not bound by them. See the Audit Packet threat model for the explicit limits.

Feature Appendix (legacy matrix)#

The matrix below compares Pipelock to earlier-generation tools (AIP, agentsh, srt) on a feature-level basis. The provenance matrix above is the load-bearing comparison for current peers; this appendix is retained for historical reference and continuity.

When to Use What#

Use mcp-scan / Snyk agent-scan when:#

• You want a quick static audit of MCP server tool definitions before connecting
• You need to detect known-malicious tool descriptions in a registry
• You want MCP-specific policy checks and JSON output around MCP server/tool risk

Use Docker MCP Gateway when:#

• You're already in the Docker ecosystem and want native MCP server management
• You want a Docker-native gateway and lifecycle surface for MCP servers
• You want MCP server management more than cross-transport content inspection

Use Pipelock when:#

• You need to prevent credential exfiltration from AI agents with API keys
• You want content inspection (DLP, injection detection) on what agents fetch
• You need audit logging for network activity mediated by the proxy
• You want a single binary with no dependencies or kernel modules
• You're running agents in CI/CD and need machine-readable output
• You want workspace integrity monitoring to detect file tampering

Use AIP when:#

• You prefer native OS dialog HITL (Pipelock uses terminal prompts, AIP uses OS-level dialogs)
• You're focused specifically on MCP server security (AIP is an MCP-native proxy)
• You want per-argument regex validation on MCP tool calls (AIP validates argument schemas; Pipelock scans argument content for DLP/injection patterns)

Use agentsh when:#

• You need eBPF-based enforcement and "steering" to redirect denied operations to safe alternatives
• You're comfortable with kernel modules and more complex setup
• You want redirect-based control (SIGKILL to SIGTERM) rather than block/scan-based control

Use srt when:#

• You're using Claude Code specifically (srt is built into it)
• You need OS-level process sandboxing (sandbox-exec on macOS, bubblewrap on Linux)
• You want domain-level allow/deny without content inspection
• You don't need DLP, audit logging, or injection detection

Pipelock vs mcp-scan#

mcp-scan focuses on MCP-specific auditing and policy checks around server/tool risk. Pipelock scans mediated traffic with pattern matching, Unicode normalization, entropy analysis, and covers HTTP and WebSocket traffic in addition to MCP. They're complementary: mcp-scan for MCP-specific auditing and guardrails, Pipelock for deep content inspection across cross-transport agent egress.

Pipelock vs Docker MCP Gateway#

Docker MCP Gateway aggregates MCP servers and provides Docker-native MCP lifecycle and gatewaying. Pipelock provides deep content inspection (65 DLP patterns, BIP-39 seed phrase detection, 32 injection detection patterns, entropy analysis, tool poisoning, and request-body prompt-injection hard-blocking) across more than MCP. They're complementary: Gateway handles Docker-native routing and lifecycle, while Pipelock handles content inspection and signed mediation evidence.

Using Tools Together#

These tools operate at different layers and complement each other well.

Pipelock + srt#

srt provides the OS sandbox (process isolation, filesystem restrictions). Pipelock provides content inspection (DLP, injection detection, audit logging). Use srt to prevent the agent from bypassing Pipelock, and Pipelock to inspect what passes through.

Pipelock + agentsh#

agentsh provides kernel-level enforcement (the agent literally cannot make unauthorized syscalls). Pipelock provides the content inspection layer (scanning what the agent fetches and detecting secrets in URLs). agentsh ensures the agent uses Pipelock; Pipelock ensures the content is safe.

Architecture Comparison#

┌─────────────────────────────────────────────────────────┐
│ Layer 4: Application │
│ ┌──────────┐ ┌──────────┐ │
│ │ Pipelock │ │ AIP │ Agent firewall: DLP, │
│ │ │ │ │ injection, scanning │
│ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────────────────┤
│ Layer 3: Shell / Process │
│ ┌──────────┐ │
│ │ agentsh │ Syscall interception, FUSE, │
│ │ │ process steering │
│ └──────────┘ │
├─────────────────────────────────────────────────────────┤
│ Layer 2: OS Sandbox │
│ ┌──────────┐ │
│ │ srt │ sandbox-exec, bubblewrap, │
│ │ │ binary allow/deny │
│ └──────────┘ │
├─────────────────────────────────────────────────────────┤
│ Layer 1: Container / VM │
│ Docker, Firecracker, gVisor │
└─────────────────────────────────────────────────────────┘

Defense in depth: use tools at multiple layers. A compromised agent must bypass all layers to exfiltrate data.

Links#

• Pipelock
• Microsoft Agent Governance Toolkit
• CAPSEM
• Signet
• AgentMint
• Cupcake
• mcp-scan / Snyk agent-scan
• Trail of Bits mcp-context-protector
• Docker MCP Gateway
• Coder Agent Firewall
• AIP
• agentsh
• srt
• Help Net Security: Pipelock feature
• OWASP Agentic Top 10