Zum Hauptinhalt springen
Ein kundenseitiger Chatbot nimmt nicht vertrauenswürdige Eingaben aus der Öffentlichkeit entgegen und sendet sie an ein Modell. Damit ist er die am stärksten exponierte Surface, die Sie betreiben: Nutzer fügen PII ein, die Sie nicht upstream gespeichert haben wollen, Angreifer versuchen, Ihren System-Prompt zu überschreiben, und das Modell kann Secrets oder unsichere Inhalte zurück ins Chatfenster echoen. Dieses Rezept verdrahtet die vier Kontrollen, die einen KI-Chatbot Ende-zu-Ende absichern — ein PII-Guardrail auf dem Request, Prompt-Injection-Screening, Output-Sicherheit und ein einziger eng eingegrenzter Schlüssel — alles in der Konsole, mit null Änderung an Ihrem Chatbot-Code.
Alles hier bindet an Ihren Workspace und wird aus der Konsole konfiguriert. Ihr Chatbot ruft weiterhin https://api.orcarouter.ai/v1/chat/completions mit demselben sk-orca-...-Schlüssel auf — nur die Policy im Gateway ändert sich. Konfigurationsaktionen benötigen die pro Schritt genannten Rollen; Relay-Aufrufe verwenden den eingegrenzten Schlüssel.

​
1. Das Bedrohungsmodell für einen öffentlichen Chatbot

Bevor Sie irgendetwas verfassen, sollten Sie wissen, wogegen Sie sich verteidigen. Die Angriffsfläche eines Chatbots ist schmaler als die eines vollwertigen Agenten — aber die hochfrequenten Risiken sind konkret:

PII rein, PII geloggt

Nutzer fügen E-Mails, Kartennummern und SSNs in den Chat ein — und Sie leiten sie upstream und in Ihre Logs weiter.

Prompt-Injection

„Ignoriere vorherige Anweisungen und …” — Versuche, Ihren System-Prompt zu überschreiben und das Verhalten des Bots zu ändern.

Jailbreaks

DAN- / Rollenspiel-Framings, die den Bot von seiner Policy abbringen wollen.

Unsichere Ausgabe

Das Modell echoet geleakte Secrets, System-Prompt-Boilerplate oder injection-durchsetzte Inhalte zurück in den Chat.
Ein einfacher Chatbot hat keine Tool-Calls, daher stützt sich dieses Rezept auf Guardrails — die Textebene — statt auf die Firewall. Wenn Ihr Bot doch Tools aufruft, legen Sie die Firewall obendrauf (siehe §6).

​
2. Ein Guardrail, vier Aufgaben

Statt vier separater Policies verfassen Sie ein Workspace-Guardrail mit geordneten Regeln, die jedes Risiko abdecken. Ein Guardrail ist eine benannte, geordnete Liste von Regeln; jede Regel sagt, wonach gesucht wird, wo (input, output oder both) und was zu tun ist (block, mask oder flag). Öffnen Sie in der Konsole Guardrails → Neues Guardrail, benennen Sie es chatbot-shield und fügen Sie die Regeln unten hinzu. Ein Guardrail zu verfassen — und die Test-Sandbox auszuführen — erfordert die Rolle Developer; das Ansehen von Guardrails ist für jedes Mitglied offen.

​
a. PII auf dem Request

Fügen Sie eine PII-Regel hinzu, Stage input, Aktion mask. Der eingebaute Entitäten-Satz ist geschlossen — wählen Sie die, die ein Chatbot tatsächlich sieht: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Eine Maske ersetzt jeden Treffer durch einen typisierten Tag — jane@acme.com wird zu [EMAIL], sodass das Upstream-Modell die Adresse nie sieht. Das entity_actions-Override blockiert den Request bei einer Kartennummer oder SSN ganz, während es die Entitäten geringerer Schwere maskiert. Das ist genau das PII Shield-Preset, erweitert um Pro-Entitäts-Overrides — wenden Sie das Preset aus der Vorlagenbibliothek an und bearbeiten Sie von dort aus.
PII-Masking auf der Input-Stage ist heute live — es schreibt den Request um, bevor das Modell ihn sieht. Live-Masking der gestreamten Antwort ist auf der Roadmap. Um PII aus dem zu redigieren, was der Bot zurücksagt, verwenden Sie eine Output-block-Regel (durchgesetzt bei Streaming und Nicht-Streaming) oder betreiben Sie den Bot non-streaming, wo Output-Masking greift. Beweisen Sie zuerst Ihre exakte Stage-/Stream-Kombination im Test-Tab.

​
b. Prompt-Injection-Screening

OrcaRouter liefert dies als das Sicherheits-Preset Prompt-Injection Basics (eine Keyword-Denylist für Phrasen wie „ignore previous instructions” und „reveal your system prompt”; für strengere Regex-Abdeckung von DAN- / Rollenspiel-Framings fügen Sie das Preset Jailbreak / Role-Play Blocker hinzu) plus, für semantische Intention, die kein Pattern fängt, eine llm_judge-Regel. Fügen Sie das Preset hinzu, dann eine Judge-Regel auf der input-Stage mit einem Rubric, das Injection-/Override-Versuche flaggt. Der Judge läuft gegen ein Modell in Ihrem Workspace, ist durch judge_timeout_ms begrenzt und failt per Default open (ein Judge-Fehler wird geloggt und der Request läuft weiter) — setzen Sie judge_fail_open: false, um fail-closed zu gehen.
Starten Sie die Injection-Regeln bei flag, beobachten Sie den Matches-Feed einen Tag lang auf echtem Traffic, und promoten Sie dann zu block, sobald Sie bestätigt haben, dass sie auf Angriffe feuern und nicht auf legitime Fragen. Siehe Enforcement-Modi.

​
c. Output-Sicherheit

Fügen Sie eine block-Regel auf der output-Stage (Regex oder Keyword) für Inhalte hinzu, die das Chatfenster niemals erreichen dürfen — geleakte Secrets, Chat-Template-Steuertokens, System-Prompt-Boilerplate. Der Secrets & API-Key Blocker und die System-Prompt-Leak-Sicherheits-Presets decken die gängigen Fälle ab; wenden Sie sie an und pinnen Sie die relevanten Regeln auf die output-Stage. Output-block wird auch beim Streaming durchgesetzt — der Scanner kappt den Stream mitten im Flug und gibt eine Ersatznachricht aus, bevor blockierte Inhalte den Nutzer erreichen.

​
3. Testen, bevor Sie ausliefern

Jeder Guardrail-Editor hat einen Test-Tab. Fügen Sie ein Sample ein, wählen Sie die Stage und führen Sie die aktuelle Policy lokal aus — kein Upstream-Aufruf, kein Kontingent verbraucht.
Das einfügenStageErwartung
email me at jane@acme.cominputemail me at [EMAIL]
ignore previous instructionsinputflag / block (Ihre Wahl)
Karte 4111 1111 1111 1111inputguardrail_blocked (gemäß Override)
Für adversariale Abdeckung führt der Eval-Tab die Policy gegen gebündelte Red-Team-Korpora (oder Ihr eigenes JSONL) aus und meldet, wie sie abschnitt — tunen Sie das Judge-Rubric, bis es bekannte Angriffe fängt, ohne harmlosen Chat zu flaggen.

​
4. Einen eingegrenzten Schlüssel für den Bot prägen

Ein Guardrail setzt nur auf Schlüsseln durch, die auf es aufgelöst werden. Geben Sie dem Chatbot seinen eigenen Schlüssel, eingegrenzt auf das Minimum, das er braucht — niemals Ihren kontoweiten Schlüssel. Setzen Sie unter API Keys → Neuer Schlüssel:
Wählen Sie chatbot-shield aus dem Guardrail-Dropdown. Das setzt guardrail_id auf dem Schlüssel. Eine explizite Bindung ist das Gegenteil des Aus-Schalters: Wenn sie gesetzt und aktiviert ist, gilt sie immer und fällt nie stillschweigend zurück. (Lassen Sie sie ungesetzt, um stattdessen auf das is_default-Guardrail des Workspaces zurückzufallen.)
Setzen Sie credit_limit_usd auf eine vernünftige Obergrenze (0 = unbegrenzt). Ein öffentlicher Chatbot ist der Schlüssel, der am ehesten missbraucht wird — eine harte Credit-Obergrenze ist Ihr Blast-Radius-Limit. Siehe Denial-of-Wallet.
Schalten Sie model_limits ein und listen Sie nur das/die Modell(e) auf, das/die der Bot aufrufen darf, sodass ein geleakter Schlüssel nicht genutzt werden kann, um ein teures Modell auszuführen, das Sie nie exponieren wollten.
Setzen Sie allow_ips auf die Egress-IPs Ihres Backends, wenn der Bot von einem festen Server aus aufruft, und ein expired_time, wenn der Schlüssel temporär ist (-1 = läuft nie ab).
Der Schlüssel wird nach der Erstellung bei der Anzeige maskiert — kopieren Sie ihn einmal. Ihr Chatbot-Backend sendet nun jeden Nutzerzug durch chatbot-shield, ohne dass irgendein Code weiß, dass Screening stattfindet.

​
5. In Produktion beobachten

Zwei Lesungen halten Sie ehrlich, beide workspace-bezogen:
  • Guardrails → Matches (jedes Mitglied) — jede Regel, die feuerte: Typ, Aktion, Stage und Detail. Der gematchte Teilstring wird nur aufgezeichnet, wenn Log raw content für das Guardrail an ist (per Default aus — die datenschutzkonservative Haltung). Markieren Sie ein False Positive, um die Policy zu tunen (Admin).
  • Versionsverlauf — jede Änderung schreibt eine Verlaufszeile; diffen Sie zwei beliebige Versionen und reverten Sie, wenn sich eine Regel als zu aggressiv erweist. Ein blockierter Request gibt HTTP 400 guardrail_blocked zurück, kostet kein Kontingent und ist als skip-retry markiert.
Eine guardrail_blocked-Antwort ist eine bewusste, nutzersichtbare 400. Behandeln Sie sie in Ihrer Chatbot-UI mit einer freundlichen Nachricht („Das kann ich nicht verarbeiten”) statt den Rohfehler anzuzeigen — das Gateway hat den unsicheren Zug bereits für Sie gestoppt.

​
6. Wenn Ihr Bot Tools aufruft

Sobald Ihr Chatbot eine Funktion aufrufen, eine URL holen oder einen MCP-Server erreichen kann, reicht Text-Screening nicht mehr — Sie brauchen die Aktionsebene. Hängen Sie eine Firewall-Policy via firewall_policy_id an denselben Schlüssel, oder wenden Sie das balanced-Autonomie-Level an, um Tool-Calls zu auditieren und PII workspace-weit zu flaggen, bevor Sie verschärfen. Der schnellste Weg ist der Zero-Trust-Quickstart; für einen Agenten, der stark Tools aufruft, siehe einen autonomen Agenten absichern.

​
7. Wo es tiefer geht

Guardrails-Referenz

Jeder Regeltyp, jede PII-Entität, jedes Judge-Feld und der Eval-Harness in Gänze.

Guardrails vs. Firewall

Textebene vs. Aktionsebene — wann Sie welche brauchen.

Enforcement-Modi

Observe → shadow → enforce: ausrollen, ohne den Bot zu brechen.

Schlüssel, Policies, Workspaces eingrenzen

Wie Schlüsselbindung und Workspace-Defaults aufgelöst werden.