Passer au contenu principal
Un pack de conformité est un framework — SOC 2, HIPAA, GDPR, ISO 27001, l’OWASP LLM Top 10 — mis en correspondance avec les contrôles de la passerelle qui le satisfont. Lorsque vous installez un pack de conformité, OrcaRouter ne se contente pas de mettre le framework en favori : il matérialise les contrôles du pack en un Guardrail réel et éditable (le plan de contenu) et une politique Firewall réelle (le plan d’appels d’outils), tagués avec la provenance du pack de sorte que chaque application, attachement et chemin d’historique existant fonctionne inchangé. Les installations atterrissent en mode observe — le guardrail signale au lieu de bloquer, le firewall tourne en shadow — de sorte que vous collectez des preuves « aurait bloqué » avant que quoi que ce soit n’affecte le trafic réel. Vous le passez en production plus tard, délibérément, depuis la console.
Parcourir le catalogue et vérifier la readiness est gratuit pour tout membre de l’espace de travail. Installer un pack est une action réservée à l’Admin de l’espace de travail et requiert un plan payant — la passerelle applique les deux barrières côté serveur, donc un appel API direct ne peut pas contourner la porte.

​
1. Ce que « installer un pack de conformité » fait réellement

Un appel d’installation écrit trois choses atomiquement dans votre espace de travail :
Les contrôles du plan de contenu du pack fusionnent en un guardrail nommé — <Pack> (Compliance) (par ex. SOC 2 (Compliance)). En mode observe, chaque action (et chaque action par entité) est contrainte à flag, de sorte qu’il annote les correspondances sans bloquer ni masquer le trafic réel.
Les contrôles d’appels d’outils du pack fusionnent en une politique firewall nommée — <Pack> (Compliance — tools) (par ex. SOC 2 (Compliance — tools)) — créée avec shadow_mode activé, de sorte qu’elle évalue et journalise chaque appel couvert comme [shadow] would … mais ne refuse jamais.
Une ligne de pack de conformité d’espace de travail relie les deux politiques matérialisées, épingle la version du catalogue, enregistre quels contrôles vous avez sélectionnés, et estampille qui l’a installé — plus une entrée de log d’audit.
Parce que l’installation produit des objets guardrail et firewall standard, vous pouvez les ouvrir dans la console ensuite, lire chaque règle, les ajuster, et attacher la politique firewall à une clé par firewall_policy_id — exactement comme n’importe quelle politique que vous avez rédigée à la main.

​
2. Installer un pack de conformité depuis la console

La configuration de conformité utilise votre session console (UserAuth), pas une clé de relais. Faites-le dans la console :
1

Ouvrez le catalogue de conformité

Allez dans Compliance dans la console de l’espace de travail. Parcourez le catalogue et ouvrez le framework dont vous avez besoin — par exemple SOC 2 (soc2) ou l’OWASP LLM Top-10 (owasp_llm). Chaque pack liste ses contrôles, sur quel plan chaque contrôle atterrit, et la référence officielle.
2

Choisissez les contrôles (ou prenez-les tous)

Installez tout le framework, ou sélectionnez un sous-ensemble de contrôles. Une sélection vide installe chaque contrôle du pack.
3

Installez

En tant qu’Admin de l’espace de travail sur un plan payant, cliquez sur Install. Le pack se matérialise en mode observe immédiatement. Réinstaller un pack déjà installé est idempotent — il renvoie l’enregistrement existant, pas un doublon.
4

Surveillez les preuves, puis passez en production

Laissez le guardrail et le firewall en shadow accumuler les correspondances « aurait bloqué ». Lorsque la posture a l’air correcte, passez le pack en production pour activer les actions déclarées et (optionnellement) promouvoir les politiques en défaut de votre espace de travail. Voir Observer vs appliquer.
Installez d’abord le pack OWASP LLM Top-10 si vous ne savez pas par où commencer — il correspond directement aux menaces que couvre cette section de docs (injection, gestion non sûre des sorties, divulgation d’informations sensibles, fuite du prompt système et agence excessive) et vous donne une posture concrète à observer.

​
3. L’appel sous-jacent

La console pilote un seul endpoint. Il est documenté ici pour que vous puissiez en voir la forme, l’auditer, ou scripter un flux de provisioning interne — mais la passerelle requiert un token de session d’Admin de l’espace de travail et un plan payant pour l’atteindre : 
POST /api/compliance/packs/{key}/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ "controls": ["owasp.llm01_injection", "owasp.llm08_excessive_agency"] }
Un corps vide installe tous les contrôles du pack : 
POST /api/compliance/packs/owasp_llm/install
La réponse est l’enregistrement d’installation — la clé du pack, la version épinglée, mode: observe, et les ids des guardrail_id et firewall_policy_id matérialisés afin que vous puissiez les ouvrir immédiatement.
Un corps malformé (non vide mais impossible à parser) est rejeté, pas silencieusement traité comme « tout installer » — de sorte qu’un bug de sérialisation côté client ne peut jamais élargir discrètement une installation partielle vers le framework complet. Envoyez du JSON valide, ou n’envoyez rien du tout.

​
4. Après l’installation

EnsuiteOù
Voir ce qui est dans le packContenu du pack
Le passer en productionObserver vs appliquer
Générer des preuves signéesRapport signé
Installer est le premier geste bon marché et réversible : cela ne coûte aucun trafic réel, c’est idempotent, et désinstaller retire proprement les deux plans matérialisés. L’étape délibérée est le passage en production — c’est là que les actions block/mask/deny déclarées s’activent.
Pourquoi un plan payant pour installer et pas seulement pour appliquer ? Matérialiser un framework en politique éditable en direct est le moment de valeur — la passerelle le garde à l’installation et à nouveau au passage en production de sorte que la frontière de mise à niveau soit explicite, jamais un 403 surprise en plein déploiement.

​
5. En lien

Plan gating

Exactement quelles actions de conformité sont gratuites, et lesquelles requièrent un plan payant.

Observer vs appliquer

Comment le mode observe collecte les preuves et ce qui change au passage en production.

Matrice de contrôles

Comment chaque contrôle de framework correspond aux guardrails et règles firewall de la passerelle.

OWASP LLM Top 10

Le pack qui correspond aux menaces de sécurité des agents de cette section.

Référence Guardrails

Le plan de contenu qu’une installation matérialise — règles, PII, actions.

Référence Agent Firewall

Le plan d’appels d’outils qu’une installation matérialise — verdicts et surfaces.
Pour la vue d’ensemble de quel côté de la ligne vous possédez versus la passerelle, voir Responsabilité partagée ; pour le catalogue de frameworks, voir Frameworks.