Zum Hauptinhalt springen
Der Tag, an dem Sie einen Agenten vor Nutzer setzen, ist der schlechteste Tag, um herauszufinden, dass ein Jailbreak direkt durch Ihre Content-Policy spaziert, oder dass ein Tool, das Sie zu steuern vergaßen, beim ersten Lauf feuert. Ein Pre-Launch-Red-Team verwandelt diese Überraschungen in eine Zahl, die Sie lesen können, bevor Sie ausliefern — und OrcaRouter gibt Ihnen drei Wege, sie zu produzieren, alle ohne Ihren Agenten-Code zu berühren oder einen einzigen Live-Request zu senden, den Sie nicht beabsichtigt haben. Dieses Rezept ist der Dry-Run-Durchlauf: eine Policy gegen bekannte Angriffe messen, sie gegen Ihren eigenen Traffic shadowen und eine engere Haltung simulieren, bevor Sie sich auf sie festlegen.
Alles hier ist schreibgeschützt oder gesandboxt — kein nutzersichtbarer Block, kein Produktions-Traffic betroffen. (Keyword-, Regex- und PII-Regeln laufen vollständig lokal; eine llm_judge-Regel ruft trotzdem ihr konfiguriertes Modell auf, sodass ein Eval über eine Judge-Policy diesen Aufruf doch macht.) Der Sinn ist, Dinge zu brechen, bevor der Launch erfolgt, zu Ihren Bedingungen.

​
1. Wie man einen KI-Agenten vor dem Launch red-teamt

Ein Pre-Launch-Red-Team beantwortet drei Fragen, und OrcaRouter hat ein Tool für jede:

Fängt mein Guardrail Angriffe?

Den Eval-Harness des Guardrails gegen gebündelte adversariale Korpora laufen lassen und Precision / Recall / F1 zurücklesen.

Was würde meine Firewall brechen?

Den Shadow-Mode einschalten und beobachten, welche echten Tool-Calls abgelehnt würden — ohne bereits einen davon abzulehnen.

Ist eine engere Haltung sicher?

Ein Autonomie-Level simulieren, um genau vorzuschauen, was es gegen Ihren Traffic ändern würde, bevor Sie es anwenden.
Das erste testet Ihre Guardrails (die Textebene); das zweite und dritte testen Ihre Firewall (die Aktionsebene). Eine echte Launch-Checkliste führt alle drei aus.

​
2. Ihr Guardrail gegen adversariale Korpora bewerten

Der schnellste Weg zu wissen, ob eine Content-Policy den Kontakt mit einem Angreifer überlebt, ist, ein Korpus bekannter Angriffe darauf zu werfen und die Punktzahl zu lesen. Der Eval-Tab des Guardrail-Editors tut genau das: Er spielt jedes Sample in einem Korpus durch Ihre aktuelle Policy und vergleicht das Verdikt gegen das erwartete Ergebnis jedes Samples — er spielt das Korpus lokal gegen Ihre Regeln ab, niemals gegen Live-Traffic. OrcaRouter liefert gebündelte Red-Team-Korpora, sodass Sie nicht Ihre eigenen beschaffen müssen. Darunter:
KorpusWas es ist
advbench_harmful_behaviorsDer kanonische Adversarial-Suffix-Zielsatz — jede Zeile ist ein unsicherer Request, den ein Guardrail blockieren sollte.
anthropic_hh_redteamEchte mehrstufige Human-Red-Team-Transkripte gegen einen Assistenten.
deepset_prompt_injectionsGelabelte Prompt-Injection- vs. harmlose Requests — eine Precision/Recall-Baseline für einen Input-Stage-Block.
databricks_dolly_benignEine reine harmlose Baseline: Eine überstrenge Policy sollte keinen davon blockieren.
Paaren Sie ein Angriffs-Korpus immer mit einem harmlosen. Eine Policy, die 100 % der Angriffe blockiert, aber auch databricks_dolly_benign blockiert, ist nicht sicher — sie ist unbrauchbar. Der harmlose Lauf ist Ihr False-Positive-Budget.
Führen Sie ein Eval gegen das gebündelte deepset_prompt_injections-Korpus aus: 
curl https://api.orcarouter.ai/api/guardrail/123/eval \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{ "corpus_name": "deepset_prompt_injections" }'
Die /api/guardrail/*-Routen verwenden Ihre Konsolen-Session / Ihren Access-Token, nicht einen sk-orca-...-Relay-Schlüssel — und sie sind über X-Workspace-Id workspace-bezogen. In der Praxis führen Sie dies aus dem Eval-Tab in der Konsole aus; das curl ist hier, um die Form zu zeigen. Ein Eval auszuführen ist für jedes Mitglied offen.
Der Lauf meldet die Erkennungsmetriken, berechnet gegen die erwarteten Aktionen:
  • TP / FP / FN / TN — wahre/falsche Positive und Negative, wobei ein „False Positive” auch das Fangen eines Angriffs mit der falschen Aktionsklasse umfasst (z. B. Maskieren, wenn Sie einen Block erwarteten).
  • Precision / Recall / F1 — die Schlagzeilen-Zahlen. Niedriger Recall bedeutet, Angriffe schlüpfen durch; niedrige Precision bedeutet, Sie blockieren harmlosen Traffic.
Öffnen Sie den Lauf, um die Fehlschläge Sample für Sample zu inspizieren, tunen Sie die Regel oder das Judge-Rubric und führen Sie erneut aus, bis die Punktzahl hält. Custom-Korpora funktionieren genauso — laden Sie Ihr eigenes JSONL hoch (Developer+), um gegen die exakten Angriffsformen zu testen, denen Ihr Produkt gegenübersteht.
Wo die Prompt-Injection-Verteidigung lebt. Das gebündelte Prompt-Injection Basics-Preset ist eine Keyword-Regel auf der flag-Aktion — sie legt gängige Jailbreak-Phrasen zur Überprüfung offen, ohne den Nutzer zu blockieren. Für semantische Injection-Intention, die keine Keyword-Liste einfängt, fügen Sie eine llm_judge-Regel hinzu und red-teamen Sie sie auf dieselbe Weise: Evaluieren Sie sie gegen deepset_prompt_injections und anthropic_hh_redteam und lesen Sie den F1. Siehe die Guardrail-Referenz.

​
3. Die Firewall im Shadow-Mode gegen echten Traffic

Ein Guardrail-Eval testet Text gegen ein festes Korpus. Ihre Firewall hingegen muss gegen die chaotische Realität dessen getestet werden, was Ihr Agent tatsächlich tut — und der sicherste Weg, das vor dem Launch zu tun, ist der Shadow-Mode. Der Shadow-Mode ist ein Pro-Policy-Flag, das die Firewall dazu bringt, jeden Tool-Call genau so auszuwerten und zu loggen, wie sie es in Produktion täte, aber jedes durchsetzende Verdikt auf audit herabzustufen. Ein deny wird zu einer Audit-Zeile, deren Grund mit [shadow] would … vorangestellt ist. Nichts wird blockiert. Nichts bricht. Aber der Events-Feed zeigt Ihnen nun die präzise Liste der Aufrufe, die Ihre Policy abgelehnt hätte. Das ist das Firewall-Red-Team: Verfassen Sie Ihre strengste beabsichtigte Policy, schalten Sie den Shadow-Mode ein, führen Sie Ihren Agenten durch eine realistische Launch-Probe und lesen Sie dann die [shadow] would …-Events.
Bauen Sie Ihre durchsetzende Policy in der Konsole (Developer+) — für einen Launch-Dry-Run setzen Sie default_verdict auf audit und fügen Sie die Deny-Regeln hinzu, die Sie auszuliefern beabsichtigen. Schalten Sie den Shadow-Mode ein. Die ganze Policy loggt nun, ohne durchzusetzen.
Führen Sie Ihre echten Agenten-Flows gegen das Gateway mit einem Schlüssel aus, der an die geshadowte Policy angehängt ist. Jeder Tool-Call — inbound, response, MCP-Dispatch, egress — wird ausgewertet und geloggt.
Öffnen Sie Firewall → Events (Developer+) und filtern Sie nach den [shadow] would …-Gründen. Jeder davon ist ein Aufruf, den Ihre Policy in Produktion abgelehnt hätte. Bestätigen Sie, dass jeder Eintrag ein Aufruf ist, den Sie abgelehnt haben wollen — und dass nichts Legitimes auf der Liste ist.
Sobald die Would-block-Liste sauber ist, schalten Sie den Shadow-Mode aus. Der allernächste matchende Aufruf wird echt durchgesetzt — keine andere Änderung.
Paaren Sie den Shadow-Mode mit dem Observe-Mode (einer Workspace-Einstellung) für Abdeckung, nicht nur Korrektheit. Der Observe-Mode loggt jeden Tool-Call, der auf keine Policy aufgelöst wird, als Lücke und füllt die Discovered tools-Ansicht — sodass Sie das Tool fangen, für das Sie eine Regel zu schreiben vergaßen, nicht nur die Regeln, die Sie falsch hatten. Siehe Enforcement-Modi.

​
4. Eine engere Haltung simulieren, bevor Sie sich festlegen

Der dritte Red-Team-Schritt ist der billigste: Bevor Sie ein strengeres Autonomie-Level anwenden, simulieren Sie es. Der Simulator schaut vor, was das Anwenden von tight (oder einem beliebigen Level) gegen den jüngsten Traffic Ihres Workspaces ändern würde — wie viele Aufrufe auf deny flippen würden — ohne eine einzige Policy-Zeile zu schreiben. 
curl "https://api.orcarouter.ai/api/workspace/firewall/simulate?level=tight" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>"
Das Lesen des Simulators ist für jedes Mitglied offen. Verwenden Sie ihn, um „ist mein Agent bereit für tight?” vor dem Launch zu beantworten: Wenn die Vorschau eine Wand von Würde-Ablehnungen auf Aufrufen zeigt, von denen Ihr Agent abhängt, haben Sie Regeln zu erweichen vor dem Go-live, keinen Vorfall danach.
Simulate ist nur Vorschau — es mutiert nie Ihre Policies. Ein Autonomie-Level anzuwenden ist eine separate Developer+-Aktion, und es ist eine Transaktion mit Ein-Klick-Undo, falls das Live-Ergebnis Sie trotzdem überrascht.

​
5. Die Pre-Launch-Red-Team-Checkliste

Setzen Sie die drei Durchläufe zusammen, und Sie haben ein Launch-Gate:
DurchlaufToolGrün, wenn
Content-PolicyGuardrail-Eval vs. Angriffs- + harmlose KorporaHoher Recall auf Angriffen, keine Blocks auf harmlosen
Aktions-PolicyFirewall-Shadow-Mode vs. Proben-TrafficJedes [shadow] would … ist beabsichtigt
AbdeckungObserve-Mode + Discovered toolsKein überraschendes Tool sitzt in einer Abdeckungslücke
HaltungDas Ziel-Autonomie-Level simulierenVorschau entspricht dem, was Sie erwarten
Lassen Sie alle vier grün laufen, dann setzen Sie durch: Schalten Sie den Shadow-Mode aus und wenden Sie Ihr Autonomie-Level an. Weil jede Bindung am Schlüssel im Gateway lebt, ist der Wechsel vom Dry-Run zum Live eine Konfigurationsänderung, kein Deploy — Ihr Agent ruft weiterhin https://api.orcarouter.ai/v1/... exakt wie zuvor auf.
Output-Stage-Masking und Live-Response-Scanning reifen noch — ein Eval-Lauf beweist die Logik einer Regel in der Sandbox, aber bestätigen Sie Ihre spezifische Stage- und Streaming-Kombination gegen die Guardrail-Notizen, bevor Sie sich in Produktion darauf verlassen.

​
6. Nächste Schritte

Enforcement-Modi

Observe → shadow → enforce, das sichere Ausrollen, das dieses Rezept probt.

Die Secure-Agents-Baseline

Was jedes Autonomie-Level setzt — und wie simulate es vorschaut.

Prompt-Injection

Die Bedrohung, gegen die Ihr Guardrail-Eval bewertet.

Go-live

Der Produktions-Cutover, nachdem das Red-Team besteht.
Für die vollständigen Engines hinter jedem Durchlauf siehe die Guardrails- und Firewall-Referenzen sowie die verwandten Bedrohungen: Jailbreaks und Gefährliche Tool-Calls.