How it works
Bridgekeeper runs with your existing gateway — it does not replace it. It sits in front of your proxy and inspects what crosses, in either direction, entirely in-process. No external calls; provider-agnostic; works fully air-gapped with local Ollama.
- User
- Bridgekeeper
- Your gateway or model server
- Model
What it does today — prompt-injection containment
Compliance package — coming soon
In-process. No external calls. Provider-agnostic.
In-process containment
Today, Bridgekeeper contains prompt injection: it sanitizes the inbound request and runs outbound DLP on the response to block leakage of your sensitive content. Provenance tracking, tool/function-call authorization, outbound/exfiltration controls, and untrusted-content isolation are part of the compliance package — coming soon.
The plugin model
Shipped as a Docker image with a Kubernetes update path. It loads as a plugin in gateways (LiteLLM, OpenRouter, Portkey, Kong AI Gateway, Helicone), guards model servers you host (Ollama, vLLM, LM Studio, Text Generation Inference, llama.cpp), or wraps your SDKs and frameworks (LangChain, LlamaIndex).
What runs where
Every hop is inside your boundary. Signed rule updates flow in; your prompts, completions, telemetry, and logs do not flow out unless you configure it.
On your host / inside your network
Your app
users, agents, jobs
Bridgekeeper
in-process: pre + post hooks
Gateway / model server
LiteLLM, Ollama, vLLM…
Model provider
Anthropic / OpenAI / local
Every hop above stays within your boundary. The model provider is the only optional external call — and only if you choose a hosted model rather than a local one.
Update feed → in
Signed rule/heuristic updates flow into the Bridgekeeper process (the poller pulls a signed bundle and verifies it). Rules in; nothing about your traffic goes back the other way.
Telemetry → stays put
Detection telemetry stays on your host. Nothing leaves unless you explicitly opt in to the threat-intel network — and then it's metadata/signatures, not your prompts.
Logs → stays put
Request/response and audit logs are written to your infrastructure. Bridgekeeper does not ship prompts, completions, or logs off your host.
Feed directionality: rules flow in; prompts, completions, telemetry, and logs do not flow out unless you explicitly configure it.