Continue.dev MCP Security: Scanning with Pipelock

Continue.dev is an open-source AI coding assistant that runs inside VS Code and JetBrains IDEs. It is MCP-native: tools, context providers, and integrations get loaded from MCP servers declared in the Continue config. Pipelock wraps each of those servers so every tool call and response runs through its MCP proxy.

Why Continue.dev needs an agent firewall

Continue sessions frequently involve:

Pipelock sits inline on each MCP server. It scans tools/call arguments outbound for DLP, scans tool responses inbound for prompt injection, scans tool definitions for poisoned descriptions, and emits signed action receipts so an operator can prove what happened.

Install pipelock

# Go
go install github.com/luckyPipewrench/pipelock/cmd/pipelock@latest

# Homebrew (macOS / Linux)
brew install luckyPipewrench/tap/pipelock

Wrap each MCP server with pipelock continue install

pipelock continue install wraps the supported MCP entries in Continue’s YAML config so they launch through pipelock mcp proxy. JSON entries and remote entries with headers need manual wrapping. It reads ~/.continue/config.yaml and every .yaml or .yml file in ~/.continue/mcpServers/. Preview first, then apply:

pipelock continue install --config "$PWD/pipelock.yaml" --dry-run
pipelock continue install --config "$PWD/pipelock.yaml"

--dry-run prints the rewritten files without touching anything. --config (-c) names the Pipelock config the wrapped servers pass to pipelock mcp proxy. --path points at a different config.yaml and --mcp-dir at a different standalone block directory. Each changed file gets a .bak backup, and the command prints Wrapped Continue MCP servers in N file(s).

The installer wraps local command servers and remote url servers. It refuses a remote entry with nonempty headers, because the generated launch doesn’t forward them; wrap that server by hand using --header-file. It also refuses a legacy ~/.continue/config.json when no config.yaml exists, because wrapping JSON would be inert.

To undo it, run pipelock continue remove (also accepts --dry-run, --path and --mcp-dir). Removal restores only entries that carry Pipelock’s wrapping metadata and leaves your other servers alone.

Wrap by hand instead

If you’d rather edit the files yourself, or need a server the installer refuses, Continue supports MCP servers in a top-level mcpServers block and in standalone files under .continue/mcpServers/. Continue’s current docs show standalone YAML files with name, version, schema, and a mcpServers list; if your setup uses the global config.yaml, edit the same mcpServers list there.

For stdio servers, keep Continue’s transport as stdio and replace the original command with pipelock mcp proxy. Put the original command and arguments after --. This is the same shape pipelock continue install writes.

A command-based MCP server changes from:

name: Local MCP Servers
version: 0.0.1
schema: v1
mcpServers:
  - name: filesystem
    type: stdio
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/tmp"

to:

name: Local MCP Servers
version: 0.0.1
schema: v1
mcpServers:
  - name: filesystem
    type: stdio
    command: pipelock
    args:
      - mcp
      - proxy
      - --config
      - /home/you/.config/pipelock/local.yaml
      - --
      - npx
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/tmp"

A remote MCP server changes from Continue’s direct remote transport:

name: Remote MCP Servers
version: 0.0.1
schema: v1
mcpServers:
  - name: remote-example
    type: streamable-http
    url: https://api.example.com/mcp

to a local stdio wrapper that points Pipelock at the upstream URL:

name: Remote MCP Servers
version: 0.0.1
schema: v1
mcpServers:
  - name: remote-example
    type: stdio
    command: pipelock
    args:
      - mcp
      - proxy
      - --config
      - /home/you/.config/pipelock/local.yaml
      - --upstream
      - https://api.example.com/mcp

If your workspace already has JSON MCP config from Claude Desktop, Cursor, or Cline, Continue can load it from .continue/mcpServers/. Wrap those servers the same way (the installer only reads YAML), but preserve the JSON file’s existing object shape. Continue’s own docs are the authoritative reference for the exact schema of each MCP server block.

Restart Continue

Quit and reopen your IDE so Continue reloads its configuration and spawns each MCP server through pipelock instead of the original command.

What gets scanned

When the redaction section is enabled in the pipelock config, matched secrets inside tools/call arguments are rewritten in place with typed placeholders before they reach the MCP server.

Forward proxy for HTTP egress

For HTTP that Continue’s agent makes outside the MCP surface (curl-style tool calls, REST clients), run pipelock as a forward proxy and point the IDE shell at it:

pipelock run --config ~/.config/pipelock/pipelock.yaml &
export HTTPS_PROXY=http://127.0.0.1:8888
export HTTP_PROXY=http://127.0.0.1:8888
export NO_PROXY=127.0.0.1,localhost

These variables route proxy-aware clients only. HTTPS content inspection needs TLS interception and CA trust, and preventing direct bypass needs containment such as pipelock contain.

Choosing a config

Start with balanced.yaml to see what gets flagged. Switch to claude-code.yaml or strict.yaml once you have verified no false positives in your workflow.

Verify

pipelock discover reports MCP servers across every IDE it knows about, including Continue.dev. Once the wrap is in place (by installer or by hand), every server should show as protected.

Action receipts

For Continue workflows that touch production source code, enable the flight recorder so each tool call produces a verifiable receipt:

flight_recorder:
  enabled: true
  dir: /var/lib/pipelock/continue-evidence
  signing_key_path: /etc/pipelock/agents/receipt-signing/id_ed25519
  sign_checkpoints: true
  redact: true

Generate the key into that path with pipelock keygen receipt-signing --keystore /etc/pipelock, run as the account that runs Pipelock so it can read the key. pipelock keys status --config <your-config.yaml> confirms the recorder can load it. Pin the matching public key when you verify: pipelock verify-receipt <file> --key /etc/pipelock/agents/receipt-signing/id_ed25519.pub. Without signing_key_path the recorder writes no signed receipts, and a receipt the recorder fails to write is logged rather than blocking traffic unless require_receipts is set. Receipts verify byte-for-byte against the published Python verifier. The format is open and the verifier is independent of the Pipelock binary; see Action Receipt Spec.

Limitations

• Re-run after adding a server. pipelock continue install wraps the servers present when it runs. Run it again after you add a new MCP server; it’s idempotent.
• Remote servers with headers. The installer refuses them. Wrap those by hand.
• Tool response redaction. Credential redaction rewrites request arguments only. Responses go through response scanning instead, which detects prompt injection and tool poisoning and, with the strip action configured, rewrites matched injection content before delivery.
• IDE restart required after editing the Continue config.

See also: Pi · Claude Code · Cursor · VS Code · Grok Build · Full documentation