Passer au contenu principal
Quand un auditeur demande comment votre passerelle IA applique un critère Trust Services, des captures d’écran d’un tableau de bord ne suffisent pas. Cette recette transforme les contrôles que vous exécutez déjà sur OrcaRouter en une preuve SOC 2 IA que les auditeurs peuvent vérifier de manière indépendante : installez le pack SOC 2, observez-le en mode observe, basculez en application, puis exportez un rapport d’état de préparation cryptographiquement signé et partagez un lien en lecture seule. Tout ce qui suit est une configuration d’espace de travail dans la console — votre app continue d’appeler /v1/chat/completions inchangée.
Parcourir le catalogue et lire l’état de préparation sont ouverts à tout Member et gratuits. Installer un pack, générer un rapport, passer en direct, et définir la résidence sont des actions Admin de l’espace de travail et nécessitent un plan payant — la passerelle applique les deux côté serveur. Les routes de gestion de conformité sous /api/compliance/* utilisent votre session de console, pas une clé de relais.

​
1. Le flux de preuve SOC 2 IA en quatre mouvements

Une piste de preuve SOC 2 sur OrcaRouter est quatre étapes que vous exécutez une fois, puis vous réexécutez le rapport chaque fois que l’auditeur veut un nouveau snapshot :

Installer le pack

Le pack soc2 matérialise un guardrail et une politique firewall mappés aux Trust Services Criteria — installés en mode observe d’abord.

Observer, puis appliquer

Observe rassemble la preuve « aurait bloqué » avec zéro rayon d’explosion ; le go-live bascule les mêmes contrôles en application.

Générer un rapport signé

Exportez un rapport d’état de préparation signé Ed25519 et hashé SHA-256 en PDF, JSON ou CSV.

Partager avec l'auditeur

Remettez un lien de partage en lecture seule ; l’auditeur vérifie la signature contre la clé publique d’OrcaRouter — aucun compte requis.
Le reste de cette page parcourt les quatre avec un exemple SOC 2 concret.

​
2. Installez le pack SOC 2

Ouvrez Conformité dans la console et parcourez le catalogue (GET /api/compliance/catalog, Member). Le pack soc2 correspond aux AICPA SOC 2 Trust Services Criteria. Ses contrôles appliqués par la passerelle sont la manipulation de données confidentielles (TSC CC6.1), la surveillance système (TSC CC7.2), et une piste d’audit d’appels d’outils (TSC CC7.2). Installez-le (Admin de l’espace de travail, plan payant) : 
POST /api/compliance/packs/soc2/install
L’installation matérialise deux objets d’application en une transaction atomique :
  • un guardrail d’espace de travail — le plan de politique de contenu (PII, secrets, et le reste des critères qui filtrent le texte de requête/réponse), et
  • une politique firewall d’espace de travail — le plan action (appels d’outils, dispatchs MCP, et egress qui correspondent aux critères d’accès et de gestion du changement).
Le pack atterrit en mode observe par défaut. En observe, les actions de guardrail sont coercées à flag et la politique firewall s’exécute en shadow — chaque contrôle enregistre ce qu’il aurait fait sans toucher une seule requête en direct. C’est votre premier lot de preuves.
Certaines clauses Trust Services sont organisationnelles — formation du personnel, accords avec les fournisseurs — et une passerelle ne peut pas les appliquer. Le rapport les divulgue honnêtement comme des lacunes plutôt que de revendiquer une couverture qu’il ne peut pas produire. Voir modes d’application pour savoir comment observe, shadow et enforce diffèrent.

​
3. Lisez votre état de préparation en direct

Avec le pack installé, Conformité → Readiness (GET /api/compliance/readiness, Member) montre votre posture par framework : combien de contrôles appliquent, combien sont encore en observe, et combien restent des lacunes. Chaque clause correspond au contrôle de guardrail ou de firewall qui la satisfait, avec un état de couverture dans lequel vous pouvez plonger.
Exécutez une semaine en observe avant d’appliquer. La vue d’état de préparation plus le flux Matches de guardrail et le flux Events de firewall vous disent exactement ce qui aurait été bloqué — de sorte que vous ajustiez les faux positifs avant qu’aucune requête réelle ne soit gouvernée.

​
4. Basculez d’observe à enforce

Une fois que la preuve « aurait bloqué » semble propre, passez le pack en direct (Admin) : 
POST /api/compliance/packs/soc2/golive
Le go-live restaure les actions déclarées du guardrail (flag devient block/mask comme conçu) et sort la politique firewall du mode shadow, de sorte que les mêmes contrôles appliquent maintenant sur le chemin de relais. Optionnellement, promouvez le guardrail du pack au défaut de l’espace de travail dans le même appel, afin que chaque clé en hérite.
Enforce est un vrai changement de posture : un prompt bloqué renvoie maintenant une HTTP 400 guardrail_blocked et un appel d’outil refusé renvoie une HTTP 400 firewall_blocked. Un block ne coûte aucun quota — les blocks d’input sont pré-metering et les blocks de sortie sont remboursés — mais il arrêtera le trafic qui viole un contrôle. C’est le but ; confirmez juste votre preuve d’observe d’abord.

​
5. Générez un rapport signé

C’est l’artefact que vous remettez à l’auditeur. Générez-le (Admin) : 
POST /api/compliance/reports
{
  "framework": "soc2",
  "format": "pdf"
}
format est l’un de pdf, json ou csv. Chaque rapport est signé avec Ed25519 sur le hash de preuve canonique et porte un hash de contenu SHA-256, de sorte qu’il soit inviolable et vérifiable de manière indépendante — l’auditeur n’a pas à faire confiance à votre capture d’écran, il vérifie la signature.
La matrice de couverture de chaque framework installé : clause → contrôle → état (enforcing / observe / gap), plus la preuve « aurait bloqué » capturée pendant observe. Les clauses organisationnelles sont listées comme des lacunes divulguées, pas silencieusement abandonnées.
La signature lie le hash de preuve du rapport à la clé de signature d’OrcaRouter. Quiconque — y compris un auditeur sans compte OrcaRouter — peut confirmer que le rapport n’a pas été altéré après génération en le vérifiant contre la clé publique.

​
6. Partagez-le avec votre auditeur

Créez un lien de partage en lecture seule pour le rapport (Admin) : 
POST /api/compliance/reports/:id/share
L’auditeur ouvre l’endpoint de partage public — pas de connexion : 
GET /api/public/compliance/share/:token
Il vérifie ensuite la signature lui-même contre la clé publiée d’OrcaRouter :
EndpointObjectif
GET /api/public/compliance/pubkeyRécupérer la clé publique Ed25519.
POST /api/public/compliance/verifyConfirmer la signature + le hash d’un rapport.
Un lien de partage est révocable. Émettez-en un par engagement d’audit, et révoquez-le (DELETE /api/compliance/share/:shareId, Admin) quand l’engagement se termine — le rapport lui-même reste dans l’historique de votre espace de travail.

​
7. Épinglez où le rapport vit

Les auditeurs et régulateurs se soucient souvent de l’endroit où la preuve est stockée. Définissez la région à laquelle vos artefacts de rapport de conformité sont épinglés (us, eu, uk, ap, cn, global) via PUT /api/compliance/residency (Admin). Les lectures inter-régions d’un rapport sont refusées.
La résidence épingle uniquement la région de l’artefact de rapport — ce n’est pas un géo-épinglage des données d’inférence. Elle contrôle où vit votre preuve signée, pas où les requêtes sont routées.

​
8. Vérifiez avant l’audit

Prouvez que la piste est réelle avant que quiconque ne la relise :
1

Confirmer la couverture

Ouvrez Readiness et confirmez que les contrôles SOC 2 que vous attendez affichent enforcing, pas observe, sans lacunes surprises.
2

Aller-retour de la signature

Générez un rapport, puis POST /api/public/compliance/verify contre la clé publique — confirmez qu’il valide avant de partager.
3

Ouvrir le lien de partage déconnecté

Atteignez GET /api/public/compliance/share/:token dans une session de navigateur propre pour voir exactement ce que votre auditeur verra.

​
Connexe

Référence Guardrails

Le plan de politique de contenu que le pack SOC 2 matérialise.

Référence Firewall

Le plan action derrière les contrôles d’accès et de changement du pack.

Modes d'application

Comment observe, shadow et enforce diffèrent — et pourquoi observe d’abord.

Déploiement HIPAA

Le même flux pack-et-rapport pour un framework santé.

Journalisation sans PII

Gardez la PII brute hors des journaux dont votre preuve s’inspire.

Checklist go-live

Activez le zero trust avant de basculer les contrôles en application.