Passer au contenu principal
Si vous exploitez un agent de support paiements, un bot de triage de chargebacks, ou tout workflow LLM qui se trouve où que ce soit près d’un Primary Account Number, la question n’est pas « mon modèle est-il certifié PCI » — aucun modèle ne l’est. La question est de savoir si le plan de données entre votre application et le modèle peut empêcher un PAN, un secret de carte, ou un appel d’outil destructeur d’atteindre le modèle ou de s’exécuter contre votre cardholder data environment. C’est ce que le pack PCI DSS vous donne : un ensemble de contrôles de passerelle mis en correspondance avec PCI DSS 4.0, installés en un seul appel, produisant des preuves signées — avec la frontière organisationnelle énoncée clairement d’emblée.
Votre cardholder data environment (CDE) — segmentation, accès physique, et votre politique de sécurité de l’information — est la responsabilité de votre organisation, pas un contrôle que la passerelle peut appliquer. OrcaRouter peut masquer les PAN, bloquer les secrets de carte, refuser les outils dangereux, et signer les preuves — mais le programme CDE est le vôtre. Le pack divulgue ces clauses comme des contrôles organisationnels que vous attestez, jamais comme une couverture automatisée. Voir la frontière ci-dessous.

​
1. Ce que la gouvernance « PCI DSS IA » signifie sur la passerelle

Le pack PCI DSS (pci_dss, PCI DSS 4.0) fait correspondre les exigences du standard à des contrôles de passerelle vivants. Comme chaque pack de conformité, l’installer matérialise des politiques Guardrail et Firewall réelles et éditables dans votre espace de travail — il n’ajoute pas un nouveau moteur d’exécution. Trois contrôles applicables font le travail sur les données de titulaires de carte :
pci.pan_block (PCI DSS Req 3.4, rendre le PAN illisible) bloque les numéros de carte validés par Luhn dans les prompts avant qu’ils n’atteignent le modèle, et les associe aux instruments de routage bancaire — IBAN et codes SWIFT/BIC — gardés par leur mot de contexte littéral de sorte qu’un ID de facture ou de suivi en majuscules qui partage simplement la forme structurelle ne soit pas faussement rejeté. La détection de PAN s’appuie sur l’entité PII credit_card, donc la vérification Luhn est intégrée.
pci.secret_hygiene (PCI DSS Req 8.3, cryptographie forte pour les références d’identification) bloque les clés API et les clés privées de transiter par la passerelle, de sorte qu’une référence d’identification ne puisse pas fuir dans un prompt ou une réponse. C’est le guardrail Secrets Blocker — le même contrôle qui attrape les secrets sur chaque requête.
pci.dangerous_tools (PCI DSS Req 2.2, configurations sécurisées) est une règle firewall qui refuse les appels d’outils de classe shell et exec à travers chaque convention de nommage — sur les surfaces inbound et MCP — de sorte qu’un agent ne puisse pas exécuter une commande destructrice qui touche les données de titulaires de carte. Tout le reste reste au défaut audit de la politique.
Les deux premiers contrôles vivent sur le plan de contenu (Guardrails) ; le troisième vit sur le plan d’appels d’outils (Firewall). L’installation les fusionne en un guardrail et une politique firewall que vous possédez et pouvez ajuster.
Deux autres clauses sont livrées avec le framework mais sont marquées organisationnelles : maintenir une politique de sécurité de l’information (Req 12.1) et restreindre l’accès physique aux données de titulaires de carte (Req 9). Ce sont des contrôles de personnes-et-processus qu’un proxy ne peut jamais appliquer — le rapport les divulgue comme attestés ou comme lacunes, pas comme une couverture automatisée. L’honnêteté est l’objectif.

​
2. Installer le pack PCI DSS — un exemple concret

La configuration de conformité utilise votre session console, jamais une clé de relais sk-orca-…. Parcourir le catalogue et vérifier la readiness sont gratuits pour tout Member de l’espace de travail ; installer est une action d’Admin de l’espace de travail sur un plan payant, gardée côté serveur dans les deux sens.
1

Ouvrez le pack PCI DSS

Dans la console de l’espace de travail, allez dans Compliance → Catalog et ouvrez PCI DSS 4.0 (il vit sous la catégorie financial). Chaque contrôle liste son plan, son exigence, et un lien profond vers la bibliothèque de documents officielle du PCI SSC.
2

Installez en mode observe

En tant qu’Admin de l’espace de travail sur un plan payant, cliquez sur Install. Le pack se matérialise immédiatement en mode observe — le guardrail signale au lieu de bloquer, le firewall tourne en shadow — de sorte que vous collectez d’abord des preuves « aurait bloqué » contre le trafic réel.
3

Observez, puis passez en production

Laissez les contrôles en shadow accumuler les correspondances, passez-les en revue, puis passez le pack en production pour activer les actions block / deny déclarées. Voir Observer vs appliquer.
La console pilote un seul endpoint sous votre token de session Admin — montré ici pour que vous puissiez l’auditer ou le scripter, pas comme quelque chose que vous appelez avec une clé de relais : 
POST /api/compliance/packs/pci_dss/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ }
Un corps vide installe chaque contrôle du pack. La réponse est l’enregistrement d’installation — la version épinglée, mode: observe, et le guardrail_id et firewall_policy_id des deux politiques matérialisées de sorte que vous puissiez les ouvrir immédiatement.
Parce que l’installation produit des objets guardrail et firewall standard, vous pouvez attacher la politique firewall matérialisée à une clé d’agent par firewall_policy_id, attacher le guardrail à une clé par guardrail_id (ou le définir comme défaut de l’espace de travail), et ajuster la règle PAN entité par entité — exactement comme une politique que vous avez rédigée à la main.

​
3. La frontière honnête — le CDE est le vôtre

Un programme PCI est bien plus qu’un filtre de rédaction. La passerelle couvre les contrôles qu’un plan de données peut réellement appliquer ; tout le reste reste avec votre organisation. Voici la séparation, tracée de la même façon que la carte de responsabilité partagée :
Domaine de contrôleLa passerelle appliqueVotre organisation possède
PAN dans le traficBloquer les PAN vérifiés par Luhn, IBAN, SWIFT/BIC dans les promptsCadrer quels champs sont des données de titulaires de carte
Secrets de carteBloquer les clés API / privées transitant par la passerelleLa garde des clés en dehors du chemin de la passerelle
Outils dangereuxRefuser les appels shell / exec près du CDESécuriser les outils qui contournent la passerelle
CDE & politique— (divulgué comme attesté / lacune)Segmentation ; accès physique ; la politique InfoSec
La passerelle est le chemin audité, pas un intercepteur au niveau du noyau. Un outil que votre agent exécute entièrement en-processus — qui ne franchit jamais https://api.orcarouter.ai et ne rapporte jamais une destination d’egress — est hors de la vue du firewall. Routez les outils et appels MCP touchant des données de titulaires de carte à travers la passerelle (via la passerelle MCP du Firewall) de sorte que le contrôle d’outils dangereux puisse les voir, ou sécurisez-les vous-même à l’intérieur de votre CDE.

​
4. Prouvez-le — des preuves signées et estampillées par région

Une fois le pack en production, générez un rapport PCI DSS. Les rapports sont signés Ed25519 et estampillés SHA-256, exportables en CSV / JSON / PDF, et publiquement vérifiables — un évaluateur peut confirmer l’authenticité d’un rapport sans connexion. Chaque ligne remonte une exigence jusqu’à la politique guardrail ou firewall exacte qui l’applique et les correspondances qu’elle a produites sur la période ; les deux clauses organisationnelles s’affichent comme des lacunes divulguées ou des attestations de propriétaire. Vous déclarez aussi une région de résidence des données pour l’artefact de rapport (us / eu / uk / ap / cn / global) — les rapports signés sont stockés et servis uniquement sous votre région déclarée, et une lecture inter-régions est retenue. Cela estampille l’artefact de preuves, pas la géographie de l’inférence.
Installer un pack et passer en production requièrent le rôle Admin de l’espace de travail sur un plan payant, appliqué côté serveur. La génération de rapport est réservée à l’Admin (plan gratuit : un PDF ; CSV/JSON et rapports supplémentaires sont payants) ; définir la résidence est réservé à l’Admin. Parcourir le catalogue et vérifier la readiness restent gratuits. Voir Plan gating.

​
5. Où aller ensuite

Installer un pack

Le flux d’installation complet — sélection des contrôles, mode observe, et passage en production.

Rapport signé

Ce que contient le rapport de preuves PCI DSS signé Ed25519.

Vérifier un rapport

Comment un évaluateur confirme qu’un rapport est authentique sans connexion.

Référence Guardrails

Le plan de contenu que le pack matérialise — entités PII, Secrets Blocker, actions.

Appels d'outils dangereux

La menace contre laquelle le contrôle firewall défend.

Résidence des données

Déclarer la région sous laquelle vos preuves signées sont stockées et servies.
Le pack PCI DSS transforme les exigences 4.0 que vous pouvez placer sur un plan de données en masquage de PAN, blocage de secrets, refus d’outils dangereux, et preuves signées que vous pouvez remettre à un évaluateur — tout en disant clairement que le CDE, la segmentation, et votre politique de sécurité de l’information restent les vôtres. Pour le reste du catalogue, voir Frameworks.