Why Bridgekeeper
Gateways focus on routing; some add detection-style guardrails, sometimes via external providers depending on configuration. Bridgekeeper wins on a different axis: in-process prompt-injection containment and tool-call authorization that keep your prompts on your boundary — provenance tracking, deny-by-default tool gating, request binding, and anti-replay, all running in-process.
LiteLLM and OpenRouter are great at routing. Here's the prompt-injection containment and tool-call authorization they don't give you — the controls Bridgekeeper adds in-process.
| Capability | LiteLLM | OpenRouter | Bridgekeeper |
|---|---|---|---|
| Routing & gateway | ● | ● | — |
| Prompt-injection containment (inbound sanitization + outbound DLP)Bridgekeeper's core: sanitize the inbound request, scan the outbound response for leakage of your sensitive content. | — | — | ● |
| Detection-style guardrailsSome gateways add moderation/detection, often via external providers depending on configuration. | ◐ | ◐ | ● |
| Works fully air-gapped (no prompts to a third-party guardrail cloud) | ◐ | — | ● |
| Deny-by-default tool / function-call authorizationAgents execute only explicitly-allowed tool calls; privileged calls are gated, not self-granted. | — | — | ● |
| Request binding + anti-replayEach tool call is bound to its request (tool + args + hash + TTL); tampered or replayed authorizations are rejected. | — | — | ● |
| Provenance trackingUntrusted ingested content is labeled and tracked through to the outbound checks. | — | — | ● |
| Untrusted-content isolation | — | — | ● |
● full · ◐ partial · — not provided. Bridgekeeper runs with your gateway; it does not replace it.