Passer au contenu principal
Quand votre application envoie du code dans un modèle — pour le réviser, le compléter, ou le faire passer par un agent — vous voulez que le modèle soit averti des parties risquées et que l’espace de travail soit empêché de faire fuiter des secrets dans la même passe. Un guardrail de sécurité du code fait exactement cela : il exécute vos règles de sécurité du code sur la requête avant que le modèle en amont ne voie un seul token. C’est une page d’atterrissage ciblée. Pour le moteur de guardrail complet — types de règles, étapes, résolution, le sandbox de test — voir la référence Guardrails et la vue d’ensemble des guardrails.

1. Ce que fait réellement un guardrail de sécurité du code

OrcaRouter livre une famille de presets code_security que vous appliquez depuis le sélecteur de templates. Chacun est une règle de guardrail ordinaire — à portée d’espace de travail, ordonnée, attachable à n’importe quelle clé — réglée pour le code :

.env / Secret-File Block

Bloque les affectations de secrets de style .env (DATABASE_URL=, AWS_SECRET_ACCESS_KEY=, API_TOKEN=…) et les dumps de config multi-lignes collés avant qu’ils n’atteignent le fournisseur. Se base sur la syntaxe d’affectation, pas sur la valeur.

License Compliance (copyleft)

Signale les requêtes transportant des en-têtes copyleft fort — tags SPDX GPL / AGPL / LGPL / SSPL ou noms de licence complets — afin qu’un relecteur puisse confirmer que le code est sûr à mélanger dans une base de code permissive. Flag-seulement.

GPL/AGPL Provenance (output)

Flag à l’étape output sur les suggestions du modèle qui portent des signatures de provenance copyleft — un marqueur que le modèle a peut-être régurgité des données d’entraînement copyleft dans le code généré.

Insecure-API Advisory

Annote le prompt d’un avis de sécurité lorsqu’il référence un sink à haut risque — eval( / exec( / os.system( / subprocess.run( / pickle.loads( / child_process.exec(. Non-bloquant.
Les trois premiers réutilisent des actions que vous connaissez déjà — block et flag. L’Insecure-API Advisory utilise annotate : au lieu de rejeter ou redacter la requête, il l’augmente d’une note que le modèle lit avant de répondre. La même primitive alimente la décoration CVE/SBOM (ci-dessous).
Les presets code_security sont déterministes — pure regex, aucun appel réseau, sûrs sur le chemin à chaud. Les scanners réseau (recherche CVE, SBOM, SAST) sont des connexions externes séparées, pas des presets. Voir §3.

2. Annotate — avertir le modèle sans changer le trafic

Les actions que vous configurez sur un guardrail sont block (rejeter l’appel, HTTP 400), mask (redacter la correspondance), et flag (journaliser seulement). La sécurité du code ajoute un quatrième comportement sous le capot : annotate, qui ne bloque ni ne masque. Quand une règle annotate correspond, la passerelle enregistre une courte note et le relais l’injecte en amont comme un avis système — afin que le modèle se voie dire, par exemple, “this request references a high-risk API (code eval, shell execution, or unsafe deserialization); prefer safer alternatives”avant qu’il ne réponde. Le texte de l’utilisateur n’est jamais rejeté et jamais réécrit.

Un exemple concret

Appliquez le preset Insecure-API Advisory à un guardrail et attachez-le à une clé. Puis envoyez du code qui appelle un sink dangereux :
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)"}
    ]
  }'
La requête passe non modifiée — même contenu, même modèle — mais la passerelle préfixe un avis de sécurité que le modèle lit d’abord. La complétion revient orientée vers des API paramétrées et la validation des entrées, sans changement de code dans votre application et sans second aller-retour.
Annotate se compose avec les autres actions. Un seul guardrail peut masquer un secret et annoter la même requête — le texte est redacté et une note est ajoutée en une passe.

3. Décoration CVE et SBOM via scanners externes

La primitive d’avis se généralise. Connectez un scanner de sécurité du code comme fournisseur externe et ses findings empruntent le même chemin annotate :
Extrait les imports et les pins de manifeste du texte de la requête et les croise avec la base de données de vulnérabilités publique OSV. Un hit décore le prompt avec, par exemple, “requests@2.0.0 has CVE-2014-1830 (HIGH). Fixed in 2.20.0.” — afin que le modèle soit informé d’une vulnérabilité connue dans un package qu’on lui a demandé d’utiliser. Gratuit et non authentifié, donc il n’y a pas de champ de clé API. Par défaut annotate ; vous pouvez le mettre sur flag ou block à la place.
Connectez un scanner SBOM (software bill-of-materials) ou SAST (analyse statique) de la même façon que vous connectez n’importe quel fournisseur externe — une URL de base plus des credentials, stockés chiffrés et masqués en lecture. Chaque finding porte une identité stable, donc un finding que vous avez déjà trié ne se redéclenche pas à chaque requête.
Les scanners externes suivent le même défaut fail-open que chaque règle avancée : une erreur ou un timeout du scanner est enregistré comme télémétrie et la requête continue. Mettez fail_open à false sur la règle pour fail closed pour les politiques où un scan manqué est inacceptable.

4. Associer aux règles de secrets et de licence

Un guardrail de sécurité du code roule rarement seul. La forme courante est un guardrail avec quelques règles :
ObjectifRègle
Arrêter les credentials collés.env / Secret-File Block (block)
Attraper les valeurs de secrets en ligneSecrets Blocker (block)
Contrôler le code copyleftLicense Compliance (flag)
Orienter les sinks dangereuxInsecure-API Advisory (annotate)
Ajoutez-les tous à une politique nommée, attachez-la à la clé de votre agent de codage, et chaque requête est filtrée — block sur les violations non ambiguës, annotate sur les jugements, flag pour le reste à revoir.
Une requête bloquée renvoie une HTTP 400 guardrail_blocked et ne coûte aucun quota — un block à l’étape input se déclenche avant la mesure. Elle est aussi marquée skip-retry, donc ré-exécuter le même prompt contre un autre canal ne fait que bloquer à nouveau. Voir l’erreur guardrail_blocked.

5. Le configurer (console + rôles)

Tout ici est configuré dans la console, pas via la clé de relais. Les routes de gestion (/api/guardrail/*) s’authentifient avec votre session / token d’accès, pas la clé de relais sk-. Les lectures — lister les guardrails et le flux Matches — sont ouvertes à tout membre de l’espace de travail. Les écritures (créer / modifier / supprimer) et le sandbox de test nécessitent le rôle Developer ou au-dessus : le sandbox peut déclencher des appels de modèle payants et des requêtes sortantes vers des fournisseurs, donc il est contrôlé comme une écriture.
1

Créer le guardrail

Dans la console, ouvrez Guardrails → New guardrail. Le split-button vous dépose dans la bibliothèque de templates — choisissez un preset Code security comme point de départ.
2

Modifier librement

Un preset est une graine, pas un verrou. Réglez la regex, ajoutez une règle Secrets Blocker, changez une action. Utilisez l’onglet Test pour prouver qu’une règle se déclenche comme vous l’attendez contre un texte d’échantillon avant de l’attacher à une clé.
3

Attacher une clé

Définissez le guardrail sur une clé API (guardrail_id), ou marquez-le comme défaut de l’espace de travail. La liaison vit sur la clé dans la passerelle, donc modifier le guardrail déplace chaque clé attachée au prochain appel.
Les findings atterrissent dans le flux Matches de l’espace de travail (type de règle, action, étape, détail). La sous-chaîne correspondante n’est enregistrée que lorsque Log raw content est activé — désactivé par défaut, la posture conservatrice en matière de confidentialité. Voir journalisation & confidentialité.

6. Où aller ensuite

  • Bloquer les secrets — la règle compagne qui attrape les valeurs de credentials dans les arguments de requête.
  • Actions — block, mask, flag, annotate et spotlight en profondeur.
  • Compliance logger — gardez un enregistrement immuable de chaque finding de sécurité du code.
  • Test & éval — prouvez que votre politique attrape le code connu-mauvais avant de la livrer.
  • Référence Guardrails — le moteur complet.
  • Sécuriser les agents IA — où les rails de sécurité du code s’inscrivent dans la pile de contrôle zero trust.