Zum Hauptinhalt springen
Wenn Ihre Anwendung Code in ein Modell sendet — um ihn zu reviewen, zu vervollständigen oder über einen Agenten laufen zu lassen — wollen Sie, dass das Modell vor den riskanten Teilen gewarnt und der Workspace im selben Durchgang davon abgehalten wird, Secrets zu leaken. Ein Code-Security-Guardrail tut genau das: Es führt Ihre Code-Security-Regeln über den Request aus, bevor das Upstream-Modell auch nur ein einziges Token sieht. Dies ist eine fokussierte Landing-Page. Für die vollständige Guardrail-Engine — Regeltypen, Stages, Auflösung, die Test-Sandbox — siehe die Guardrails-Referenz und die Guardrails-Übersicht.

​
1. Was ein Code-Security-Guardrail tatsächlich tut

OrcaRouter liefert eine code_security-Preset-Familie, die Sie aus dem Template-Picker anwenden. Jedes davon ist eine gewöhnliche Guardrail-Regel — workspace-bezogen, geordnet, an jeden Key anhängbar — auf Code abgestimmt:

.env / Secret-File Block

Blockiert .env-artige Secret-Zuweisungen (DATABASE_URL=, AWS_SECRET_ACCESS_KEY=, API_TOKEN=…) und eingefügte mehrzeilige Config-Dumps, bevor sie den Anbieter erreichen. Schlüsselt auf die Zuweisungs-Syntax, nicht auf den Wert.

License Compliance (copyleft)

Markiert Requests, die Strong-Copyleft-Header tragen — GPL / AGPL / LGPL / SSPL SPDX-Tags oder vollständige Lizenznamen — damit ein Reviewer bestätigen kann, dass der Code sicher in eine permissive Codebasis eingemischt werden kann. Nur flag.

GPL/AGPL Provenance (output)

Output-Stage-Flag auf Modell-Vorschlägen, die Copyleft-Herkunftssignaturen tragen — ein Marker, dass das Modell Copyleft-Trainingsdaten in generierten Code zurückgegeben haben könnte.

Insecure-API Advisory

Annotiert den Prompt mit einem Sicherheitshinweis, wenn er einen Hochrisiko-Sink referenziert — eval( / exec( / os.system( / subprocess.run( / pickle.loads( / child_process.exec(. Nicht-blockierend.
Die ersten drei verwenden Actions wieder, die Sie bereits kennen — block und flag. Das Insecure-API Advisory verwendet annotate: Statt den Request abzulehnen oder zu redigieren, erweitert es ihn um eine Notiz, die das Modell liest, bevor es antwortet. Dasselbe Primitiv treibt die CVE/SBOM-Dekoration an (unten).
Die code_security-Presets sind deterministisch — reine Regex, kein Netzwerk-Aufruf, sicher auf dem heißen Pfad. Die vernetzten Scanner (CVE-Lookup, SBOM, SAST) sind separate externe Verbindungen, keine Presets. Siehe §3.

​
2. Annotate — das Modell warnen, ohne den Traffic zu verändern

Die Actions, die Sie auf einem Guardrail konfigurieren, sind block (den Aufruf ablehnen, HTTP 400), mask (den Treffer redigieren) und flag (nur loggen). Code-Security fügt unter der Haube ein viertes Verhalten hinzu: annotate, das weder blockiert noch maskiert. Wenn eine annotate-Regel matcht, zeichnet das Gateway eine kurze Notiz auf und der Relay injiziert sie nach Upstream als System-Hinweis — sodass dem Modell z. B. gesagt wird “this request references a high-risk API (code eval, shell execution, or unsafe deserialization); prefer safer alternatives” — bevor es antwortet. Der Text des Benutzers wird nie abgelehnt und nie umgeschrieben.

​
Ein konkretes Beispiel

Wenden Sie das Preset Insecure-API Advisory auf ein Guardrail an und hängen Sie es an einen Key. Senden Sie dann Code, der einen gefährlichen Sink aufruft: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user",
       "content": "Refactor this: result = eval(user_supplied_expr)"}
    ]
  }'
Der Request geht unverändert durch — gleicher Inhalt, gleiches Modell — aber das Gateway stellt einen Sicherheitshinweis voran, den das Modell zuerst liest. Die Completion kommt in Richtung parametrisierter APIs und Eingabevalidierung gelenkt zurück, ohne Codeänderung in Ihrer Anwendung und ohne zweiten Round-Trip.
Annotate setzt sich mit den anderen Actions zusammen. Ein einzelnes Guardrail kann ein Secret maskieren und denselben Request annotieren — der Text wird redigiert und eine Notiz in einem Durchgang hinzugefügt.

​
3. CVE- und SBOM-Dekoration via externe Scanner

Das Advisory-Primitiv verallgemeinert sich. Verbinden Sie einen Code-Security-Scanner als externen Anbieter und seine Befunde reiten denselben annotate-Pfad:
Extrahiert Imports und Manifest-Pins aus dem Request-Text und gleicht sie mit der öffentlichen OSV-Schwachstellendatenbank ab. Ein Treffer dekoriert den Prompt mit z. B. “requests@2.0.0 has CVE-2014-1830 (HIGH). Fixed in 2.20.0.” — sodass dem Modell von einer bekannten Schwachstelle in einem Paket berichtet wird, das es verwenden sollte. Kostenlos und nicht authentifiziert, daher gibt es kein API-Key-Feld. Standardmäßig annotate; Sie können es stattdessen auf flag oder block setzen.
Verbinden Sie einen SBOM- (Software Bill of Materials) oder SAST- (Static-Analysis-)Scanner auf dieselbe Weise, wie Sie jeden externen Anbieter verbinden — eine Basis-URL plus Credentials, verschlüsselt gespeichert und beim Lesen maskiert. Jeder Befund trägt eine stabile Identität, sodass ein Befund, den Sie bereits triagiert haben, nicht bei jedem Request erneut feuert.
Externe Scanner folgen demselben fail-open-Standard wie jede erweiterte Regel: Ein Scanner-Fehler oder Timeout wird als Telemetrie aufgezeichnet und der Request fährt fort. Setzen Sie fail_open auf der Regel auf false, um für Policies, bei denen ein verpasster Scan inakzeptabel ist, fail closed zu sein.

​
4. Paarung mit Secrets- und Lizenz-Regeln

Ein Code-Security-Guardrail reitet selten allein. Die übliche Form ist ein Guardrail mit ein paar Regeln:
ZielRegel
Eingefügte Credentials stoppen.env / Secret-File Block (block)
Inline-Secret-Werte fangenSecrets-Blocker (block)
Copyleft-Code gatenLicense Compliance (flag)
Gefährliche Sinks lenkenInsecure-API Advisory (annotate)
Fügen Sie sie alle zu einer benannten Policy hinzu, hängen Sie sie an den Key Ihres Coding-Agenten und jeder Request wird geprüft — block bei den eindeutigen Verstößen, annotate bei den Ermessensfällen, flag für den Rest zur Überprüfung.
Ein blockierter Request gibt HTTP 400 guardrail_blocked zurück und kostet kein Kontingent — ein Block der Input-Stage feuert vor der Messung. Er wird außerdem als skip-retry markiert, sodass das erneute Ausführen desselben Prompts gegen einen anderen Channel einfach wieder blockiert. Siehe den guardrail-blocked-Fehler.

​
5. Konfigurieren (Konsole + Rollen)

Alles hier wird in der Konsole konfiguriert, nicht über den Relay-Key. Die Management-Routen (/api/guardrail/*) authentifizieren mit Ihrem Session-/Access-Token, nicht mit dem sk--Relay-Key. Lesevorgänge — das Auflisten von Guardrails und der Feed Matches — sind für jedes Workspace-Mitglied offen. Schreibvorgänge (erstellen / bearbeiten / löschen) und die Test-Sandbox erfordern die Rolle Developer oder höher: Die Sandbox kann kostenpflichtige Modell-Aufrufe und ausgehende Anbieter-Requests feuern, also ist sie wie ein Schreibvorgang gegated.
1

Das Guardrail erstellen

Öffnen Sie in der Konsole Guardrails → New guardrail. Der Splitbutton bringt Sie in die Template-Bibliothek — wählen Sie ein Code security-Preset als Ausgangspunkt.
2

Frei bearbeiten

Ein Preset ist ein Keim, keine Sperre. Tunen Sie die Regex, fügen Sie eine Secrets-Blocker-Regel hinzu, ändern Sie eine Action. Verwenden Sie den Tab Test, um zu beweisen, dass eine Regel so feuert, wie Sie es gegen Beispieltext erwarten, bevor Sie sie an einen Key anhängen.
3

Einen Key anhängen

Setzen Sie das Guardrail auf einem API-Key (guardrail_id), oder markieren Sie es als Workspace-Default. Die Bindung lebt am Key im Gateway, sodass das Bearbeiten des Guardrails jeden angehängten Key beim nächsten Aufruf verschiebt.
Befunde landen im workspace-weiten Feed Matches (Regeltyp, Action, Stage, Detail). Der gematchte Teilstring wird nur dann aufgezeichnet, wenn Log raw content eingeschaltet ist — standardmäßig aus, die datenschutzkonservative Haltung. Siehe Logging & Datenschutz.

​
6. Wie es weitergeht

  • Secrets blockieren — die begleitende Regel, die Credential-Werte in Request-Args fängt.
  • Actions — block, mask, flag, annotate und spotlight im Detail.
  • Compliance Logger — führen Sie eine unveränderliche Aufzeichnung jedes Code-Security-Befunds.
  • Testing & Eval — beweisen Sie, dass Ihre Policy bekannt-schlechten Code fängt, bevor Sie ihn ausliefern.
  • Guardrails-Referenz — die vollständige Engine.
  • KI-Agenten absichern — wo Code-Security-Rails in den Zero-Trust-Control-Stack passen.