PCI SSC veut une validation humaine pour les agents IA

Le PCI Security Standards Council (PCI SSC), l'organisme du secteur à l'origine des normes de sécurité des cartes de paiement que commerçants et processeurs doivent respecter, publie de nouvelles recommandations sur l'exploitation de systèmes d'IA dans les environnements de paiement. L'une d'elles retient l'attention : les agents IA qui ont accès aux données de titulaires de carte en clair devraient obtenir une approbation humaine explicite avant toute action portant sur ces données.

Le document, intitulé Security Considerations for AI Systems, a été élaboré avec des acteurs du secteur. Il couvre la gouvernance, le déploiement, les contrôles d'accès, les tests et l'application des normes PCI à l'IA. Il aborde aussi la défense contre les attaques qui s'appuient sur l'IA. Les recommandations sont purement consultatives, et les exigences PCI existantes priment.

"Alors que l'IA est de plus en plus utilisée dans les environnements de paiement, toutes les parties ont l'obligation de veiller à ce que cette technologie soit utilisée de manière responsable", a déclaré Gina Gobeyn, directrice exécutive du PCI SSC. "Ces recommandations supplémentaires offrent un point de départ concret pour une mise en oeuvre sécurisée de l'IA."

Autonomie minimale et responsabilités claires

Le Council demande aux organisations de définir la finalité d'un système d'IA, ses autorisations et ses accès aux données avant de le choisir ou de le déployer. Il qualifie cette approche de "moindre autonomie" (least agency) : chaque système ne reçoit que les accès et les capacités dont ses tâches ont besoin.

Une personne compétente devrait assumer formellement la responsabilité des résultats produits par l'IA, et les organisations devraient déterminer quelles actions nécessitent une approbation humaine. Les limites d'accès devraient être imposées par des contrôles indépendants, comme des politiques de gestion des identités et l'isolement réseau, et non par l'IA elle-même.

Les recommandations mettent aussi en garde contre le fait de donner à un même système d'IA, simultanément, un accès à des données sensibles, la capacité de communiquer avec l'extérieur et des entrées sans restriction provenant de sources non fiables. Si un processus a besoin des trois, le travail devrait être réparti entre plusieurs agents dotés d'autorisations différentes.

Les organisations sont invitées à tenir un inventaire de leurs IA et une nomenclature recensant les modèles, les versions, l'hébergement, les intégrations, les politiques d'utilisation et de conservation des données, ainsi que les utilisateurs prévus. Une politique d'utilisation acceptable et des contrôles techniques devraient aider à repérer et à restreindre la shadow AI, c'est-à-dire les outils que le personnel utilise sans autorisation.

Tests, autonomie et secrets

Les garde-fous devraient être testés avant les tests fonctionnels et les tests d'acceptation utilisateur à grande échelle, y compris par des tests adverses visant à vérifier si les restrictions peuvent être contournées. La surveillance et la revalidation devraient se poursuivre après le déploiement, et les relecteurs devraient garder à l'esprit qu'une confiance excessive dans les résultats de l'IA peut leur faire manquer des erreurs.

Outre l'approbation tâche par tâche, les recommandations décrivent une "autonomie surveillée", dans laquelle l'IA exécute des actions autorisées sous surveillance. Dans ce modèle, les organisations devraient définir les actions permises, les exigences d'approbation, les déclencheurs d'arrêt et les procédures de retour arrière. Une personne reste malgré tout responsable en dernier ressort.

Les systèmes d'IA ne devraient pas manipuler, générer ni gérer de secrets critiques non protégés, comme les mots de passe et les clés cryptographiques. Les identifiants ont leur place dans des outils de gestion des secrets et ne devraient figurer ni dans le code source ni dans les prompts, ni dans le contexte de l'IA, ses sorties ou les journaux. Lorsque des valeurs aléatoires sont nécessaires, il faut recourir à un générateur de nombres aléatoires de confiance.

Les données de paiement chiffrées ou tokenisées sont à privilégier, la prévention des fuites de données devrait fonctionner indépendamment de l'IA, et les journaux ne devraient pas conserver d'informations de paiement sensibles. Pour la définition du périmètre PCI, un système d'IA qui a accès à des données chiffrées ou tokenisées ainsi qu'à des outils capables de les déchiffrer ou de les détokeniser est considéré comme ayant accès à des données lisibles. Les données d'entraînement entrent également dans le périmètre.

Attaques assistées par l'IA et tiers

Le Council souligne que l'IA peut accélérer la découverte de vulnérabilités, le développement d'exploits et l'ingénierie sociale. Il recommande une surveillance continue des vulnérabilités, des services et des autorisations limités, l'isolement des systèmes anciens, une authentification résistante à l'hameçonnage, le chiffrement et le confinement des intrusions.

Le code et les correctifs générés par l'IA devraient passer par des tests de sécurité et des tests fonctionnels, avec des vérifications portant sur les identifiants intégrés, les dépendances inadaptées, les nouvelles faiblesses et la question de savoir si le correctif règle le problème de fond. Un exemple répartit la gestion des vulnérabilités entre des agents qui détectent les problèmes, planifient les correctifs, testent les modifications et déploient les mises à jour approuvées, le retour arrière ayant été testé au préalable.

Les fournisseurs d'IA externes ayant accès à des données sensibles devraient être évalués comme des prestataires tiers. Les contrats devraient interdire explicitement l'utilisation des données de l'organisation pour entraîner des IA, offrir une visibilité sur les sous-traitants et fixer les conditions de notification en cas d'incident. Les plans de réponse aux incidents devraient couvrir l'injection de prompts, l'empoisonnement de modèles, les actions hors périmètre et les outils d'IA non autorisés.

Notre analyse

Ces recommandations ne sont pas contraignantes, mais les documents du PCI SSC ont tendance à influencer la façon de penser des auditeurs et des évaluateurs. Les organisations qui déploient des agents IA à proximité des systèmes de paiement pourraient donc bientôt devoir répondre à des questions sur leurs inventaires, leurs autorisations et leurs circuits d'approbation, avant même qu'une exigence formelle n'existe.

L'accent mis sur la répartition des tâches entre agents et sur l'exclusion des secrets des prompts fait écho à des problèmes observés ailleurs, à mesure que les outils agentiques obtiennent un accès plus large aux données et aux systèmes. La règle de périmètre sur les données tokenisées associées à des outils de détokenisation mérite aussi d'être relevée : elle pourrait faire entrer dans le périmètre PCI certains déploiements d'IA que les équipes pensaient en dehors.

Reste à voir si les futures versions de la norme PCI DSS transformeront une partie de ces conseils, en particulier l'approbation humaine des actions portant sur les données de titulaires de carte, en contrôles obligatoires.