Wie du PII aus LiteLLM-gerouteten AI-Calls redigierst

Das Problem: ein Router, viele Modelle, viele Leak-Pfade

LiteLLM ist das, was dem LLM-Oekosystem am naechsten an einem universellen Client kommt. Ein SDK, eine API-Form, 100+ Modell-Anbieter. Teams nutzen es, weil sie ihren Code nicht an einen Anbieter binden und Modelle nach Kosten, Latenz oder Faehigkeit tauschen koennen wollen.

Diese Bequemlichkeit erzeugt ein Problem: jedes Modell, an das du routest, ist ein weiterer Exfiltrations-Kanal fuer alles, was deine Nutzer getippt haben. Eine Regex, die du fuer OpenAI geschrieben hast, hilft nicht, wenn derselbe Prompt bei Anthropic landet. Provider-spezifische Redaktions-Logik skaliert nicht.

Du brauchst eine Redaktions-Policy im Request-Pfad, bevor LiteLLM entscheidet, wohin geroutet wird.

Das Setup

Grepture ist ein Proxy. LiteLLM ist auch ein Proxy/Router. Sie komponieren natuerlich — zeige LiteLLMs api_base pro Modell auf Grepture, und Grepture redigiert vor dem Forward.

Option 1: LiteLLM-SDK mit Grepture als Base-URL

from litellm import completion

response = completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": user_input}],
    api_base="https://proxy.grepture.com/v1",
    extra_headers={
        "X-Grepture-Auth": f"Bearer {GREPTURE_API_KEY}",
        "X-Grepture-Auth-Forward": f"Bearer {OPENAI_API_KEY}",
    },
)

Der X-Grepture-Auth-Forward-Header transportiert den Upstream-Provider-Key. Grepture redigiert den Request-Body, leitet an OpenAI weiter, stellt reversible Tokens in der Antwort wieder her.

Option 2: LiteLLM-Proxy-Server mit Grepture upstream

Wenn du LiteLLM als self-hosteten Router fuer ein Aggregator-Produkt betreibst, zeige api_base jedes Modells in deiner config.yaml auf Grepture:

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_base: https://proxy.grepture.com/v1
      api_key: os.environ/OPENAI_API_KEY
      extra_headers:
        X-Grepture-Auth: os.environ/GREPTURE_API_KEY
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_base: https://proxy.grepture.com/v1
      api_key: os.environ/ANTHROPIC_API_KEY
      extra_headers:
        X-Grepture-Auth: os.environ/GREPTURE_API_KEY

Jeder Provider in deinem LiteLLM-Router fliesst jetzt durch dieselben Grepture-Redaktions-Regeln. Eine Policy, jedes Modell.

Was abgefangen wird, unabhaengig vom Upstream

Weil Grepture im Request-Pfad sitzt, bevor LiteLLM einen Provider entscheidet, laeuft dieselbe Erkennung fuer jedes Modell:

PII (reversibel): E-Mail, Telefon, SSN, Kreditkarte, IP-Adresse, Postadresse, Personennamen, Geburtsdaten
Secrets (permanente Ersetzung): API-Keys, Tokens, Passwoerter, Webhooks ueber 25+ Credential-Familien — OpenAI, Anthropic, AWS, GitHub, Stripe, Slack
Streaming erhalten: SSE-Chunks werden in Echtzeit detokenisiert, kein Buffering

Der Aggregator-Use-Case

Wenn dein Produkt ein Multi-Modell-Aggregator ist — Nutzer bringen Intention, du routest an das beste Modell — ist jeder Provider in der Kette ein weiterer Exfiltrations-Kanal fuer alles, was der Nutzer getippt hat. Eine Redaktions-Policy vor der Routing-Entscheidung ist das Einzige, was skaliert:

Migration von rohem LiteLLM

Wenn du LiteLLM bereits ohne Redaktion betreibst, ist der Wechsel eine Base-URL-Aenderung pro Modell. Keine Anwendungscode-Aenderungen, kein Prompt-Scrubbing pro Aufruf, keine provider-spezifische Regex.

Bei app.grepture.com anmelden.
api_base jedes Modell-Eintrags (oder in deinen SDK-Calls) auf den Grepture-Proxy aendern.
PII- und Secret-Kategorien im Dashboard auswaehlen.
Im Traffic-Log Erkennungen pruefen, bevor Enforcement aktiv wird.

Naechste Schritte

Preise ansehen — kostenlos bis 1.000 Requests/Monat
Docs — SDK-Referenz und Dashboard-Guide