- Agent IAM traite chaque agent comme une identité gouvernée
- Modèles / actions / environnements autorisés par identité
- Tout accès expiré ou hors liste d'autorisation est refusé par défaut (403)
- Le RBAC délimite qui peut modifier les contrôles et les politiques
Faites entrer vos agents IA dans votre périmètre SOC 2.
SOC 2 est l'attestation de l'AICPA selon laquelle les contrôles d'une organisation de services satisfont aux Trust Services Criteria — sécurité, disponibilité, intégrité du traitement, confidentialité et vie privée. Lorsque des agents mènent des actions réelles sur les données clients, ils étendent votre périmètre de contrôle. Cortex rend ce périmètre applicable : identités à portée limitée, gestion des changements, contrôles d'accès à refus par défaut et une piste d'audit à altération détectable que l'auditeur peut tester.
Aligné sur les Trust Services Criteria de l'AICPA · CC + A + PI + C + P
SOC 2 (Trust Services Criteria de l'AICPA), en langage clair.
Un rapport SOC 2 est une attestation d'un cabinet de CPA indépendant selon laquelle vos contrôles sont correctement conçus (Type I) et opèrent efficacement sur une période (Type II). Il s'organise autour des Trust Services Criteria : les Common Criteria (sécurité, CC1-CC9), plus la disponibilité, l'intégrité du traitement, la confidentialité et la vie privée selon les cas. SOC 2 n'est pas une liste de contrôle que l'on valide une fois — c'est un programme de contrôle continu qu'un auditeur échantillonne. Les agents qui lisent et écrivent des données clients se situent pleinement à l'intérieur de ce programme. Cortex apporte les contrôles d'accès, de gestion des changements, de surveillance et de journalisation pour la couche agent et — c'est unique — rend le journal d'audit lui-même à altération détectable, de sorte que l'intégrité de vos preuves est démontrable.
s'applique à ▸ États-Unis · organisations de services · Trust Services Criteria
Chaque exigence devient un contrôle appliqué et enregistré.
Les Common Criteria reposent sur le contrôle d'accès, la gestion des changements, la surveillance et la journalisation d'audit. Cortex applique chacun d'eux au niveau de la couche agent et scelle les preuves obtenues, pour qu'un échantillon de Type II trouve des contrôles en fonctionnement.
- Le Trust Ledger chaîné par hachage consigne chaque verdict de point de contrôle
- verifyChain prouve que le journal d'audit n'a pas été modifié
- Control Tower fait remonter en direct les anomalies et les refus
- Reçus signés comme preuves vérifiables hors ligne
- Les changements de Policy-as-Code sont simulés avant leur mise en production
- Les tests golden de politiques verrouillent les changements contre les régressions
- Ontologie versionnée avec brouillon / publication / retour arrière
- Le score de fiabilité conditionne la publication des versions d'agent
- Le DLP filtre les données à l'entrée et à la sortie de chaque appel d'outil
- Les permissions d'ontologie au niveau des propriétés restreignent les champs
- Isolation par tenant indexée sur (tenantId, id) partout
- Des durées de conservation que vous fixez, avec preuve de suppression
- Action Fabric : simulation → proposition → approbation → exécution
- Compensation / retour arrière des actions exécutées
- Les suites d'évaluation mesurent la qualité des sorties
- La provenance des points de données prouve que les sorties remontent aux sources
D'une obligation écrite à une preuve démontrable.
Toute obligation se réduit à une porte d'exécution à fermeture sécurisée dont le verdict est consigné dans un registre inviolable que vous pouvez remettre à un examinateur. C'est le tableau qu'un Compliance Pack exporte pour ce cadre.
| Obligation | Contrôle Cortex appliqué | Preuve dans le registre |
|---|---|---|
| CC6 — contrôles d'accès logiques et physiques | Agent IAM + RBAC | 403 sur lecture restreinte |
| CC7 — surveillance du système et détection d'incidents | Trust Ledger + Control Tower | verifyChain ▸ ok:true |
| CC8 — gestion des changements | Simulation de politique + tests golden | réussis/total avant mise en production |
| Disponibilité — résilience et reprise | Plafonds de coûts + coupe-circuit + SLA | 402 en dépassement de budget |
| Intégrité du traitement — complet, exact, autorisé | Cycle de vie Action Fabric | exécuté · compensé |
| Enregistrements complets et à altération détectable | Reçus signés, chaîne scellée | hashOk:false signale les modifications |
Export de preuves en un clic, directement depuis le Trust Ledger.
Un auditeur SOC 2 Type II échantillonne les preuves sur toute la période pour vérifier que les contrôles ont fonctionné. Un Compliance Pack fait correspondre les Trust Services Criteria à leurs contrôles Cortex et exporte les enregistrements d'exécution scellés — et parce que le registre est chaîné par hachage, l'intégrité des preuves elles-mêmes est démontrable.
- La cartographie des contrôles SOC 2, générée — pas assemblée à la main
- Des enregistrements d'exécution scellés que vous pouvez vérifier hors ligne avec verifyChain
- Provenance des données : chaque fait remonte à sa source
- Honnête par construction — la preuve est générée, jamais affirmée
Les verdicts SOC 2 que vous verrez dans la démo.
Ce ne sont pas des promesses de présentation — ce sont les codes et les reçus littéraux que le runtime renvoie lorsque vous le mettez à l'épreuve des contrôles de ce cadre.
Trois étapes pour passer de SOC 2 sur le papier au démontrable.
- 01
Cartographier
Choisissez SOC 2. Cortex aligne chaque obligation sur la porte d'exécution qui l'applique — sans archéologie de tableurs.
- 02
Appliquer
Chaque exécution d'agent franchit les mêmes portes à fermeture sécurisée. Un contrôle refusé renvoie un code réel (402 / 403 / 409) — jamais un passage silencieux.
- 03
Prouver
Exportez un Compliance Pack : le tableau de correspondance et les enregistrements scellés du registre montrant que chaque contrôle s'est déclenché, vérifiables hors ligne.
Aligné sur — jamais présenté comme certifié
SOC 2 est une attestation délivrée par un cabinet de CPA indépendant au sujet d'une organisation et d'une période données. Cortex est aligné sur les Trust Services Criteria et fournit les contrôles et les preuves à altération détectable pour la couche agent ; le rapport est délivré à votre organisation, pas à Cortex.
Les capacités Cortex qui satisfont ce cadre.
Chaque obligation ci-dessus est appliquée par une capacité réelle du runtime. Explorez celles qui font le travail pour ce cadre.
Agent IAM
Des agents traités comme des identités gouvernées, avec listes d'autorisation et expiration, assurent les contrôles d'accès logique CC6.
Trust Ledger
La journalisation à altération détectable rend la preuve de surveillance CC7 démontrable, et pas seulement présente.
Policy-as-Code
La simulation avant mise en production et les tests golden constituent le contrôle de gestion des changements CC8.
Cartographiez le reste de votre surface réglementaire.
Les mêmes contrôles appliqués et le même export de preuves en un clic couvrent les autres cadres cités par vos auditeurs.
ISO/IEC 42001
Aligné sur ISO/IEC 42001 — les obligations, les portes d'exécution qui les appliquent et la preuve que chacune laisse dans le registre.
HIPAA
Aligné sur HIPAA — les obligations, les portes d'exécution qui les appliquent et la preuve que chacune laisse dans le registre.
NIST AI RMF
Aligné sur NIST AI RMF — les obligations, les portes d'exécution qui les appliquent et la preuve que chacune laisse dans le registre.
Tous les cadres
Le hub conformité complet — tous les cadres auxquels Cortex se rattache, avec le modèle contrôle-vers-preuve partagé.
Conçu pour les cadres que vos auditeurs citent déjà.
Le registre scellé, les reçus signés et le graphe de traçabilité correspondent aux obligations de chaque régime auquel vous rendez compte — aligné sur, sans jamais revendiquer une certification que vous n'avez pas.
Transformez SOC 2 d'une contrainte en un bouton.
Découvrez comment Cortex met SOC 2 en correspondance avec des contrôles appliqués et exporte à la demande des preuves de niveau audit.