Self-Hosted Sure with Pipelock: Secure AI Assistant Egress

Inside the Sure chart

Sure is an open-source personal finance app maintained at we-promise/sure. It is a community-maintained fork of Maybe Finance, with a Rails 8 app, Sidekiq workers, optional Postgres and Redis, and a first-party Helm chart at charts/sure.

Starting with v0.6.9, Sure’s chart ships Pipelock as a first-class deployable component. Self-hosters running Sure with the external AI assistant feature get a security boundary between the assistant and the LLM provider or MCP servers it talks to, without rolling their own proxy.

The egress gap Pipelock closes

Sure’s external AI assistant feature lets a self-hoster connect an LLM provider to the app for natural-language queries over financial data. That introduces an outbound network path from inside the cluster to a third-party LLM API, plus optional MCP servers feeding tools to the assistant. Two security exposures follow.

Outbound credential and PII leakage. The AI assistant can read account and transaction data exposed to it by the app. A poisoned tool description or a crafted prompt can coax the assistant into including sensitive data in a tool argument. The request leaves the cluster through the LLM API endpoint. Without content scanning at the egress layer, the operator has no last-hop check before the data leaves.

MCP tool poisoning and rug-pull. Third-party MCP servers can hide instructions in tool descriptions or change tool semantics across sessions. The assistant follows the description it sees. An MCP server an operator added in good faith can turn a benign-looking tool into one that asks for sensitive account data.

Pipelock sits between Sure’s assistant and the network. The forward proxy scans outbound requests. The MCP reverse proxy scans inbound tool definitions and responses. Both run as a separate deployment in the same namespace, sharing nothing with the Sure web pods.

Enabling Pipelock

The chart’s pipelock: values block is disabled by default. Minimum config to turn it on:

pipelock:
  enabled: true
  mode: balanced
  requireForExternalAssistant: true

requireForExternalAssistant: true is the safety guard. With that guard set, helm template and helm install fail if rails.externalAssistant.enabled=true and pipelock.enabled=false. Operators can make the assistant path depend on the security layer instead of relying on a checklist.

mode controls Pipelock’s enforcement posture:

• strict: blocks on anything Pipelock flags. Highest false-positive rate. For high-sensitivity deployments.
• balanced: default. Blocks high-confidence detections, warns on lower-confidence ones.
• audit: logs every detection, blocks nothing. For initial rollout to measure traffic before enforcing.

The current Sure chart pins pipelock.image.tag to 2.0.0 for stable installs. Override the image tag in your values file only after testing the newer Pipelock release against your assistant traffic.

Chart pieces Pipelock renders

Setting pipelock.enabled: true renders these chart components in the same namespace as Sure:

• Deployment running the Pipelock binary with two listeners.
• Service exposing port 8888 (forward proxy) and port 8889 (MCP reverse proxy).
• ConfigMap with the rendered pipelock.yaml from chart values.
• Optional Ingress for external MCP clients reaching the reverse proxy.
• Optional ServiceMonitor for Prometheus scraping /metrics on the forward proxy.
• Optional PodDisruptionBudget to protect Pipelock during node drains.

Sure’s web and worker pods route their outbound traffic to Pipelock’s forward proxy via HTTPS_PROXY env wiring that the chart installs when pipelock.enabled=true.

Verify the install

From a checkout of we-promise/sure, build the chart dependencies and render the guard path before installing:

helm dependency build charts/sure

helm template sure charts/sure \
  --set rails.externalAssistant.enabled=true \
  --set pipelock.enabled=false \
  --set pipelock.requireForExternalAssistant=true

That command should fail with the chart guard because the external assistant is enabled without Pipelock. Then render the protected path:

helm template sure charts/sure \
  --set rails.externalAssistant.enabled=true \
  --set pipelock.enabled=true \
  --set pipelock.requireForExternalAssistant=true

After install, check that the Pipelock deployment, service, and configmap exist in the Sure namespace:

kubectl get deploy,svc,cm -n <namespace> -l app.kubernetes.io/component=pipelock

What this does not cover

This integration protects the external assistant path. It gates outbound LLM requests through the forward proxy and inbound MCP traffic through the reverse proxy.

It does not replace Sure application hardening, database access controls, Kubernetes NetworkPolicy, secret management, or operator review of which MCP servers are exposed. If you set MCP_API_TOKEN directly through environment variables, Helm cannot infer that from the rails.externalAssistant values block. In that case, keep pipelock.enabled=true as an explicit deployment rule.

Going further

The full Pipelock options surface (trusted domains, MCP tool redirect profiles, ingress, ServiceMonitor, extraConfig escape hatches) lives in the chart README:

• Sure chart README, Pipelock section
• Sure product site
• Sure documentation site
• Pipelock on GitHub for the firewall itself

If you’re deploying Sure with Helm and you have turned on the external AI assistant, turn on Pipelock and set the guard. The chart already wired the deployment path.