AI Agents

Pipelock MCP proxy + HTTPS_PROXY: stop secret exfiltration from prompt-injected tool calls without changing agent code

Sahil Kathpal

• 3 min read

Prompt injection becomes operationally dangerous when an agent can both read secrets and make network or tool calls. Pipelock addresses that boundary problem by sitting between the agent, MCP servers, and the network. This article is for developers running coding agents locally or in CI who want a practical control point without patching the agent runtime.

The short version

  • MCP traffic needs MCP-aware inspection; generic HTTP proxies do not understand tools/list and tools/call semantics.
  • Pipelock can wrap MCP servers and scan tool definitions, tool arguments, and tool responses.
  • HTTPS_PROXY is a useful first step for outbound HTTP(S), but it is not a hard boundary unless direct egress is blocked.
  • The strongest pattern is capability separation: the agent has credentials; the proxy has network access; the agent cannot bypass the proxy.

Why this problem exists

MCP servers expose tools through JSON-RPC. The official MCP tools spec defines tools/list for discovery and tools/call for invocation. Tool definitions include names, descriptions, and JSON Schema input definitions; tool calls include structured arguments. Those fields are exactly where secrets and prompt-injection payloads can travel.

A compromised prompt can ask the agent to call a benign-looking fetch tool with an API key in the query string. A poisoned MCP response can tell the agent to read ~/.ssh/id_rsa and send it elsewhere. The model may not reliably distinguish trusted instructions from untrusted data once both are in context.

Pipelock’s public docs describe it as an open-source agent firewall with HTTP, WebSocket, and MCP scanning. Its MCP proxy mode wraps MCP servers and scans both directions: outbound arguments before execution and inbound responses before they reach the agent.

A practical deployment shape

For MCP servers, wrap each server command:

pipelock mcp proxy --config pipelock.yaml -- npx -y @modelcontextprotocol/server-filesystem ./work

Then point your MCP client at the wrapper command rather than the raw server. The agent still thinks it is talking to the same MCP server, but every discovery and call crosses the proxy.

For HTTP(S), start with environment proxying:

export HTTPS_PROXY=http://127.0.0.1:8080
export HTTP_PROXY=http://127.0.0.1:8080

This catches clients that honor proxy variables. It is convenient for developer workstations and quick evaluations.

Do not stop there for sensitive workflows. A prompt-injected agent can unset environment variables, use a library that ignores them, or exfiltrate through DNS before an HTTP request is even made. Treat HTTPS_PROXY as routing configuration, not a security boundary.

Make the proxy the only way out

A stronger local setup is:

  1. Run the agent in a container, VM, or network namespace.
  2. Deny direct outbound egress from the agent environment.
  3. Allow connections only to the Pipelock proxy.
  4. Let the proxy make approved upstream connections.

That creates capability separation. The agent may hold provider tokens because it needs to call models or tools. The proxy should not need those tokens. The proxy sees the traffic and can block or redact before data leaves.

In a container, the rough idea is:

# Sketch only: adapt to your platform.
docker run \
  --network agent-net \
  -e HTTPS_PROXY=http://pipelock:8080 \
  -v "$PWD:/workspace" \
  your-agent-image

Then enforce egress policy at the Docker network, firewall, or Kubernetes NetworkPolicy layer. If the agent can still open arbitrary TCP connections, the proxy is advisory.

What to scan

For MCP, focus on these paths:

  • tools/list responses: scan names, descriptions, and nested inputSchema descriptions for hidden instructions.
  • tools/call arguments: scan for API keys, tokens, private keys, SSH material, high-entropy strings, and suspicious destinations.
  • Tool responses: scan for indirect prompt injection before text enters model context.
  • Tool inventory changes: treat mid-session changes as suspicious unless explicitly re-approved.

For HTTP(S), inspect URLs, headers, bodies, and redirects. Secrets often leak in query strings, hostnames, headers, JSON bodies, or encoded fragments.

Gotchas

TLS interception is required for body-level HTTPS inspection unless the agent sends plaintext to the proxy. That means certificate installation and operational risk. If you cannot intercept TLS, you can still enforce destinations and scan CONNECT metadata, but you will miss request and response bodies.

DLP is not perfect. Encodings, chunking, novel prompt-injection phrasing, and sanctioned APIs can bypass simple rules. Use scanning as one layer alongside least privilege, short-lived credentials, per-tool allowlists, and audit logs.

Also separate read and write tools. Blocking a leaked token is useful; preventing the agent from calling a write-capable deployment tool without approval is better.

For this kind of agent workflow, we have been building Grass: run Claude Code or Opencode on a managed GrassVM or on your own machine, then approve tool actions, review diffs, and resume sessions from iPhone/iPad. If you are already putting a proxy in front of agent egress, Grass gives you a mobile control surface for the human-in-the-loop parts without leaving a laptop open.

You can try it at https://codeongrass.com.

Conclusion

Pipelock’s MCP proxy and HTTPS_PROXY support give teams a low-friction way to put an enforcement point around existing agents. The important detail is deployment: proxy variables help, but network isolation makes the proxy meaningful. Start by wrapping MCP servers, route HTTP through the proxy, then close direct egress so prompt-injected tool calls cannot simply go around it.

Sources

  • Pipelock GitHub and PipeLab docs
  • MCP official tools specification
  • Microsoft guidance on indirect prompt injection in MCP