Agent runtime security

Pipelock Open-source agent firewall

Pipelock scans mediated HTTP, MCP, and WebSocket traffic for secret leaks, prompt injection, and tool poisoning, then emits signed action receipts you can verify offline.

v3.5.0 Operator dashboard · Evidence viewer · Strict receipts

Core
Apache 2.0
Runtime
Single Go binary
Traffic
HTTP · MCP · WebSocket
Evidence
Signed decision records

The enforcement boundary

The agent keeps the keys. Pipelock guards the crossing.

Pipelock inspects mediated network and tool traffic without storing the agent's credentials. Routing or containment must prevent a direct path around it.

Privileged zone

Agent + credentials

The workload owns its secrets and initiates the request.

Outbound request → Pipelock scan · enforce · record ← Inbound response
Untrusted side

Web, APIs + tools

Content and destinations are checked before the agent trusts them.

First protected run

Protect one real path.

Install the binary, route one agent through it, then inspect a signed record. The full install guide owns package choices, upgrades, and editor-specific setup.

  1. Install the binary

    Use Go here or choose Docker, Homebrew, or a signed release binary in the install guide →

  2. Route Claude Code

    Wire one real agent through Pipelock. MCP servers and other agents have their own documented paths.

  3. Verify a receipt

    Configure receipt signing for your own traffic, or use the public replay archive to verify one now.

Current containerdocker pull ghcr.io/luckypipewrench/pipelock:3.5.0

Controls at the point of action

Inspect, enforce, and keep the record.

Four control groups replace the feature wall. Open the group you need, or scan the named controls without expanding anything.

Traffic inspection

Check both directions.

DLP and SSRF run on outbound traffic. Response scanning catches prompt injection before untrusted content reaches the agent.

  • 65 DLP patterns
  • Encoding-aware inspection
  • Media policy
  • Canary tokens
Open traffic controls

Cross-transport DLP. The same engine scans URLs, headers, request bodies, WebSocket frames, and MCP tool arguments. Cross-request detection catches secrets split across requests.

Response scanning. Normalization checks obfuscated prompt injection, control-flow hijacking, and authority assertions before the content reaches the agent.

Media policy. Audio and video are blocked by default. JPEG and PNG metadata is stripped, and SVG active content is hardened.

MCP control

Inspect the tool, call, and chain.

Pipelock scans tool descriptions and arguments, applies tool policy before execution, and tracks changes inside a session.

  • Tool policy
  • Session binding
  • Chain detection
  • Binary integrity
Open MCP controls

Tool policy. Allow, deny, and redirect rules run before execution. Shell-obfuscation checks resolve variable insertion and backtick substitution before matching.

Session binding. A SHA-256 baseline tracks tool definitions. Mid-session description changes can alert or block.

Tool chains. Subsequence matching finds configured multi-call patterns, while binary integrity verifies the wrapped MCP process before spawn.

Enforcement

Block when the answer is unknown.

Mediated enforcement paths fail closed. Operators can add adaptive policy, a process sandbox, and independent kill-switch sources.

  • Fail-closed
  • Adaptive enforcement
  • 6 kill sources
  • Learn-and-Lock
Open enforcement controls

Fail-closed paths. Timeouts, parse errors, oversized bodies, malformed JSON-RPC, and non-terminal human approval prompts block instead of passing.

Adaptive enforcement. Per-session threat scores can escalate policy, then recover as traffic stays clean.

Containment. Linux and macOS process controls can restrict the agent. Deployment isolation must still stop direct traffic from bypassing Pipelock.

Evidence and operations

Keep enough context to check later.

Decision records, hash-chained logs, signed assessments, and machine-readable reports keep enforcement evidence attached to the run.

  • Signed receipts
  • Flight recorder
  • Assess
  • HTML, JSON, SARIF
Open evidence controls

Flight recorder. Scanner decisions, policy actions, and session events are hash chained. Optional Ed25519 checkpoints can sign the chain.

Assess. Pipelock combines simulation, config scoring, install verification, and discovery into signed HTML and JSON evidence bundles.

CI. The current GitHub Action is luckyPipewrench/pipelock@v3.5.0. It can scan a diff and fail the job when it finds a blocking issue.

Session records. Versioned snapshots capture policy state, tool inventory, verdict summaries, and behavioral fingerprints.

Scanner pipeline

The order is part of the control.

v3.5.0Named checks. Fixed sequence.Read the tagged pipeline

For mediated target URLs, length and parsing happen first. Destination policy and credential checks run before the first DNS lookup; usage limits and a final context check close the path.

  1. Preflight

    Reject a broken target.

    Check the request context, length, parse result, canonical host, scheme, destination port, CRLF, and path traversal before policy runs.

    • Context + length
    • Parse + canonicalize
    • Scheme + port
    • CRLF + traversal
  2. Destination

    Apply destination policy.

    Run the strict allowlist and blocklist, then reject private or metadata IP literals before DNS.

    • Allowlist
    • Blocklist
    • Literal-IP SSRF floor
  3. Credentials

    Stop secrets before lookup.

    Normalize the exact SigV4 credential case, then run the immutable and configured DLP floors plus path, query, and subdomain entropy checks.

    • SigV4 handling
    • Core + configured DLP
    • Path + query entropy
    • Subdomain entropy
  4. No network yetDNS starts only after credential checks
  5. Resolution

    Resolve and contain.

    Resolve the hostname, then block private ranges, cloud metadata, and DNS rebinding.

    • DNS + SSRF
  6. Decision

    Budget and decide.

    Apply rate and data budgets, then check the request context again before returning an allow verdict.

    • Rate limit
    • Data budget
    • Final context
HTTP
Ordered URL scan plus body and response controls
WebSocket
Target URL scan, then frames in both directions
MCP
Separate message, tool, policy, and session controls
A2A
Separate task, artifact, and agent-metadata controls

Evidence you can inspect

See the decision. Check the signature.

The operator console keeps the scanner verdict, policy action, receipt timeline, and offline verification command together.

Pipelock operator console showing a signed receipt timeline and per-session evidence scorecardOperator console evidence view

Coordinate more than one agent

One engine. A separate security boundary for every agent.

Community keeps the full scanner and one default profile. Pro adds unlimited named profiles with their own policy, identity, budgets, behavior, and evidence.

$49/month

Founding price. Flat rate. No per-agent charge. Grandfathered for life.

01

Policy per agent

Separate DLP, allowlists, rate limits, budgets, enforcement mode, and MCP tool policy.

02

Identity that holds up

Bind profiles with dedicated listeners, source CIDRs, headers, and trusted domains.

03

Learn, then lock

Build per-agent behavior baselines, set thresholds, and control sandbox overrides.

04

Evidence that stays separated

Keep profile-scoped audit trails, receipts, metrics, roster views, and exemption inventory.

Go deeper

Keep going from here.

Frequently asked questions

What is Pipelock?
Pipelock is an open-source agent firewall. It sits between an AI agent and the internet as a local proxy and scans mediated HTTP, WebSocket, and MCP messages the agent sends or receives. Strict mode blocks unsafe traffic. Balanced mode blocks immutable-floor risks such as SSRF and core DLP secrets, and detects prompt injection and MCP tool poisoning. Pipelock is a single Go binary (Apache-2.0 core; Enterprise features under ELv2).
How does Pipelock differ from a WAF or AI firewall for LLM APIs?
A WAF protects a server from inbound attackers. An AI firewall for an LLM API protects the model endpoint. Pipelock protects the agent itself: it enforces the boundary between the agent and the outside world by scanning the agent’s own outbound requests and the responses it pulls in. Different traffic direction, different threat model.
What transports does Pipelock scan?
Pipelock mediates HTTP, WebSocket, MCP, and Agent-to-Agent (A2A) traffic across its supported proxy modes. For HTTP, that includes forward proxy, CONNECT, and fetch. MCP supports stdio wrapping, streamable HTTP, and HTTP reverse proxy. Target URLs use the ordered URL scanner. Response bodies, frames, MCP messages and tools, and A2A tasks and artifacts add controls for the data and actions each transport exposes.
Does Pipelock see the agent's real secrets?
No. Pipelock holds no agent credentials by design. The agent runs in the privileged zone with its own secrets. Pipelock runs in a separate trust zone with no secret access, inspecting traffic as it crosses the boundary. This capability separation is enforced at the deployment layer through container or process isolation.
Is Pipelock free?
The core is free and Apache-2.0 licensed. Its scanning, detection, and enforcement controls are in the open-source binary. Run the full firewall on as many agents as you want, free. Pipelock Pro adds coordination once you want multiple agents under one admin boundary. Enterprise adds fleet management and compliance.
What does Pipelock catch that a domain allowlist misses?
A domain allowlist decides where the agent can go. It does not inspect what the agent sends. Pipelock checks request bodies for credential patterns, responses for prompt injection, and MCP tool descriptions for poisoning and drift. These attacks can pass an allowlist because the destination is trusted while the content is not.
Does it fail open or closed?
Closed on mediated enforcement paths. Timeouts, parse errors, oversized bodies, compressed content, malformed JSON-RPC, and non-terminal HITL all block. If Pipelock cannot verify a mediated action is safe, it does not pass.
How are rules updated?
Community rules use Ed25519-signed bundles, CalVer versioning, and hot reload. pipelock rules install pulls the latest bundle. pipelock rules verify checks signatures against your trusted keyring. Built-in patterns update with each binary release.
Can agents reach internal services?
trusted_domains allows controlled exceptions for services with public DNS that resolve to private IPs, such as localhost development servers, local inference endpoints, and internal APIs. SSRF protection stays active for everything else.
What's the performance impact?
The current end-to-end performance benchmark shows sub-millisecond MCP stdio overhead and low-millisecond HTTP and tool-chain overhead on localhost. See the Pipelock performance guide for the full transport table, cold-start numbers, and reproduce command: https://pipelab.org/learn/performance/

Get started

Single Go binary (Apache-2.0 core; Enterprise features under ELv2). Install and the proxy is online.