Passer au contenu principal
Si votre équipe sécurité demande « comment cela tient-il face à l’OWASP LLM Top 10 ? », vous voulez une réponse qui pointe vers des contrôles en marche, pas une diapositive. OrcaRouter livre l’OWASP Top 10 for LLM Applications comme un vrai pack de conformité installable (owasp_llm) — pas seulement une vue de checklist. L’installer matérialise les règles de guardrail et la politique firewall auxquelles chaque risque correspond, sur le même chemin que chaque requête vers api.orcarouter.ai franchit déjà, et capture ce qui a été attrapé dans un rapport signé que vous pouvez remettre à un auditeur. Cette page fait correspondre chaque risque OWASP LLM couvert au contrôle OrcaRouter qui l’applique, montre comment installer le pack, et renvoie vers la référence approfondie pour chaque contrôle. Pour l’arc installer-et-passer-en-production à travers tous les frameworks, commencez par la Vue d’ensemble de la conformité.

​
1. L’OWASP LLM Top 10 mis en correspondance avec les contrôles OrcaRouter

Le pack owasp_llm est une correspondance de contrôles qui s’installe comme une politique réelle — chaque entrée ci-dessous est un contrôle que la passerelle applique, pas une description d’intention. Les risques à fort signal correspondent à des guardrails vivants et une politique firewall ; un risque (LLM05) est un contrôle organisationnel sans surface d’application de passerelle.
Un Guardrail sur l’entrée de la requête. Le pack combine le preset de sécurité Prompt-Injection Basics (signalement par mots-clés) avec une règle regex de jailbreak (modes DAN/STAN/AIM plus le smuggling de texte caché par tag-byte Unicode) pour attraper les tentatives d’injection directes et obscurcies. Associez-le à une règle llm_judge pour l’intention d’injection sémantique. Voir Injection de prompt et Jailbreaks.
Un Guardrail sur le stage de sortie qui bloque les réponses du modèle contenant des charges d’injection SQL classiques (UNION SELECT, OR 1=1, DROP TABLE) avant qu’elles n’atteignent un système en aval qui pourrait les auto-exécuter. Passez en revue les correspondances dans le flux de correspondances des Guardrails.
Un contrôle organisationnel — l’assurance de la chaîne d’approvisionnement pour vos modèles, données et dépendances est un processus que vous possédez, pas une vérification de passerelle au moment de la requête. Le pack le porte comme preuve dans le rapport de sorte que votre auditeur le voie pris en compte. Pour le côté runtime des outils tiers, voir Sécuriser les agents IA.
Deux Guardrails : le Secrets & API-Key Blocker (rejette les requêtes portant des références d’identification AWS / OpenAI / GitHub) et un PII Blocker strict (rejette les requêtes portant des emails, numéros de téléphone, SSN, cartes de crédit ou IPs). Les deux rejettent en dur sur la requête avant qu’elle n’atteigne le fournisseur. Voir les sections PII et secrets de Guardrails.
Un Guardrail sur le stage de sortie qui bloque les réponses du modèle renvoyant en écho des tokens de contrôle de chat-template (<|system|>, <|im_start|>) — preuve claire que le prompt système est en train de fuir. Ajustez la règle et passez en revue ses déclenchements dans le flux de correspondances.
Une règle de politique Firewall qui refuse les appels d’outils de classe shell / exec dangereux — le contrôle du plan d’action. C’est là que le firewall, pas un guardrail de contenu, fait le travail : il évalue les appels d’outils que votre modèle émet. Voir Appels d’outils dangereux et Agence excessive.
Le pack couvre le sous-ensemble à fort signal de la liste OWASP qui a une surface d’application de passerelle concrète — LLM01, LLM02, LLM06, LLM07, LLM08 comme contrôles appliqués, plus LLM05 comme preuve organisationnelle. Les risques qui vivent entièrement dans le code de votre propre application (vol de modèle, empoisonnement des données d’entraînement) sont hors du chemin de la passerelle et restent les vôtres à traiter — voir Responsabilité partagée.

​
2. Pourquoi guardrails et firewall, pas un seul contrôle

La liste OWASP LLM s’étend sur deux plans différents, et OrcaRouter sépare ses contrôles le long de la même ligne :
PlanCouvreContrôle
ContenuLLM01, LLM02, LLM06, LLM07Guardrails
ActionLLM08Firewall
Les guardrails filtrent le texte des prompts et des réponses ; le firewall évalue les appels d’outils et les actions sortantes. L’agence excessive (LLM08) est un problème d’action, donc elle correspond à une règle firewall — pas un filtre de contenu. La séparation est tout l’intérêt : lisez Guardrails vs Firewall pour savoir pourquoi un seul contrôle ne peut pas couvrir les deux.

​
3. Installer le pack

Parcourir le catalogue et la readiness est gratuit pour tout Member de l’espace de travail. Installer le pack matérialise les guardrails et la politique firewall, et est une action d’Admin de l’espace de travail gardée derrière un plan payant. Faites-le depuis la console — Compliance → Catalog → OWASP LLM Top-10 → Install.
Installez d’abord sur un espace de travail hors production, ou attachez la politique firewall matérialisée en shadow_mode de sorte que les verdicts appliquants journalisent comme [shadow] would … au lieu de refuser. Surveillez les événements firewall et le flux de correspondances de guardrail pendant une semaine, puis promouvez en application une fois que les correspondances ont l’air correctes.
L’installation crée des règles de guardrail et une politique firewall réelles et éditables dans votre espace de travail. Elles sont les vôtres à ajuster ensuite — ajustez la liste d’entités PII, échangez le deny LLM08 pour un verdict audit pendant que vous apprenez le comportement de vos agents, ou ajoutez une règle d’injection llm_judge par-dessus la base mots-clés/regex de LLM01. Attachez le guardrail à une clé via guardrail_id et la politique firewall via firewall_policy_id, ou définissez l’un ou l’autre comme défaut de l’espace de travail.

​
4. Prouvez-le avec un rapport signé

Une couverture que vous ne pouvez pas montrer n’est pas une couverture. Après que le pack tourne, générez un rapport de conformité — il est signé Ed25519 et estampillé SHA256, exportable en CSV / JSON / PDF, et publiquement vérifiable sans compte OrcaRouter.

Générer un rapport signé

Ce que le rapport capture et comment il est signé.

Vérifier un rapport

Remettez à un auditeur l’endpoint de vérification public — aucun compte nécessaire.
Le rapport liste chaque contrôle OWASP LLM, la règle qui l’adosse, et les correspondances qu’il a attrapées dans la fenêtre de rapport — de sorte que la réponse à « comment cela tient-il face à l’OWASP LLM Top 10 ? » est un artefact signé, pas une assurance verbale.

​
5. Où aller ensuite

Vue d'ensemble de la conformité

L’arc complet installer → appliquer → rapport → passage en production.

Ce qu'il y a dans un pack

Comment les contrôles d’un pack deviennent des guardrails et une politique firewall.

Tous les frameworks

Les autres packs IA, sécurité et confidentialité du catalogue.

Sécuriser les agents IA

Le référentiel qui durcit les agents contre ces risques de bout en bout.
La couverture OWASP LLM sur OrcaRouter est une politique en marche, pas une checklist : une installation câble les guardrails et règles firewall auxquels chaque risque correspond, et un rapport prouve qu’ils se sont déclenchés.