Evaluation guide
Already running LiteLLM, Portkey, or Kong? Here's where PII redaction fits
- 01
Identify sensitive values
- 02
Replace with stable tokens
- 03
Restore only inside your boundary
Direct answer
LiteLLM, Portkey, and Kong AI Gateway are built to route and manage requests across multiple model providers — load balancing, fallback, retries, and cost tracking — not primarily to detect personal data. PII masking is usually handled through a plugin, middleware hook, or a separate service called from within the gateway, rather than being the gateway's core function.
Routing gateways solve a different problem than redaction
LiteLLM, Portkey, and Kong AI Gateway exist to make calling multiple LLM providers manageable: a consistent interface across providers, automatic fallback when one is down, request-level cost and usage tracking, and caching. That's a real and separate problem from detecting personal data in a prompt before it leaves an organization's control.
Some of these gateways expose hooks or plugins that can call an external service, including a redaction API, as part of the request lifecycle. That makes them a reasonable place to enforce a policy, but the detection logic itself typically comes from elsewhere.
Where PII masking plugs into an existing gateway
The common pattern is a pre-request hook: the gateway intercepts the outbound prompt, sends it to a redaction service, and forwards the transformed version to the model provider only after sensitive values are handled. The same hook point can apply consistent policy across every provider a team routes through, rather than requiring a separate integration per model.
- Pre-request hooks call an external redaction service before the prompt reaches a provider
- Policy can apply uniformly across every provider a gateway routes to
- The gateway still owns routing, retries, and cost tracking; redaction is a separate concern plugged into it
Running a gateway and a redaction layer together
Teams already invested in LiteLLM, Portkey, or Kong for routing don't need to replace that investment to add PII redaction — the more common integration is calling a redaction layer from within the gateway's existing hook system, so routing and data protection stay as separate, independently maintained concerns.
MaskFlare is designed to sit at that hook point: a base-URL or API call a gateway's pre-request hook can call before forwarding a prompt to OpenAI, Anthropic, or Gemini, without requiring a team to move off the routing layer it already runs.
Related PII guidance
Frequently asked questions
Do I need to replace LiteLLM or Portkey to add PII redaction?
No. Redaction is typically added as a call from within the gateway's existing hook or plugin system, not as a replacement for the routing layer.
Does routing through a gateway already protect personal data?
Not by default. Routing gateways manage provider selection, retries, and cost — they don't inspect prompt content for personal data unless a redaction step is explicitly added to the request path.
Which gateway hook point should call the redaction service?
Whichever pre-request hook the gateway exposes before the prompt is forwarded to a model provider, so redaction happens before the sensitive value ever leaves the organization's boundary.