Sécurité de l'IA : protéger les modèles, les données et les agents en production

Le conseil en sécurité de l'IA de SEYA Group aide les entreprises canadiennes à déployer des applications LLM et des agents IA sans exposer leurs données ni leurs systèmes : nous évaluons les risques d'injection de prompts et de fuite de données, concevons les contrôles et surveillons les modèles en production. Les missions types durent de quatre à douze semaines et sont menées par des ingénieurs sécurité seniors depuis notre bureau de Vancouver.

À qui s'adresse ce service

Aux CISO et architectes sécurité dont les équipes s'apprêtent à mettre un grand modèle de langage, un système de recherche documentaire ou un agent devant des employés ou des clients. Aux CIO à qui l'on demande d'approuver une fonctionnalité d'IA et qui n'ont pas encore de vision écrite de ce que le modèle peut atteindre. Aux responsables d'ingénierie qui livrent déjà sur AWS, Microsoft Azure ou Google Cloud et veulent que le travail de sécurité soit fait par des gens qui lisent aussi le pipeline.

Il s'agit d'une mission de conseil. SEYA ne vend pas de modèle, n'exploite pas de centre d'opérations de sécurité et ne certifie pas qu'un système est sûr ou conforme. Les constats sont ce que la revue et les vérifications convenues rapportent.

Les menaces couvertes par la revue

La revue s'appuie sur deux références publiques comme liste de contrôle, pas comme label. Le OWASP Top 10 for LLM Applications nomme les modes de défaillance observés dans les assistants déployés : injection de prompts, divulgation d'informations sensibles, faiblesses de la chaîne d'approvisionnement des modèles et des plugins, et usage non sécurisé de plugins ou d'outils. Le NIST AI Risk Management Framework est la structure que nous utilisons pour consigner le risque de façon lisible par un comité de sécurité : govern, map, measure, manage.

• Injection de prompts. Des instructions dissimulées dans un document, une page web, un courriel ou un message utilisateur qui tentent de contourner le prompt système ou la politique d'outils.
• Fuite de données. Données d'entraînement, index de recherche, prompts et sorties d'outils susceptibles de renvoyer des données client, des secrets ou le contenu d'un autre locataire au mauvais appelant.
• Chaîne d'approvisionnement des modèles. Poids, conteneurs, plugins et jeux d'évaluation qui entrent dans l'environnement sans trace d'origine, de version ou des vérifications exécutées avant promotion.
• Abus d'outils par les agents. Un agent capable d'appeler des API internes, des tickets ou des comptes cloud avec un privilège plus large que celui de la personne qui a posé la question.

Ce que vous obtenez

• Une évaluation écrite. Les systèmes du périmètre, les données qu'ils peuvent atteindre, les identités sous lesquelles ils s'exécutent et une liste de constats classés par priorité. Chaque constat indique ce qui a été observé et le changement que nous recommandons. Il ne dit pas que le système est certifié.
• Une conception des contrôles. Filtrage des entrées, vérification des sorties, listes d'autorisation d'outils, gestion des secrets et journalisation, rattachés au pipeline et aux comptes cloud que vous utilisez déjà. Si vous souhaitez que les contrôles soient construits, cette construction est un périmètre distinct, convenu séparément, qui s'inscrit à côté du travail DevSecOps pour que les vérifications s'exécutent à chaque changement.
• Un plan de surveillance. Quoi journaliser (les prompts sont souvent sensibles ; le plan précise ce qui ne doit pas être stocké), quelles alertes méritent de réveiller quelqu'un, et qui les examine.
• Un dossier de passation. L'évaluation, la liste des contrôles et une session de travail avec vos responsables sécurité et ingénierie. Vous conservez les documents et les comptes.

Déroulement d'une mission

• Appel de cadrage. Vous nommez l'application, ses utilisateurs, les données qu'elle peut récupérer et les outils qu'elle peut appeler. Nous indiquons si la première étape est une évaluation, une conception des contrôles, ou les deux.
• Évaluation. Nous lisons l'architecture, le modèle d'identité et un échantillon de prompts et de traces d'outils avec vos ingénieurs. Nous n'avons pas besoin que des données client de production soient copiées chez SEYA.
• Contrôles. Nous rédigeons la conception des contrôles en réponse aux constats. Vos responsables décident de ce qui bloque une mise en production. SEYA recommande ; le processus d'exception reste le vôtre.
• Surveillance. La journalisation et la revue sont convenues avant qu'un agent ne reçoive un nouvel outil. Si l'application n'est pas encore en production, cette étape est une conception, pas un flux en direct.
• Passation. Votre équipe repart avec les documents et, si une construction était dans le périmètre, les vérifications de pipeline. Une revue ultérieure peut reprendre la même base de référence après évolution du système.

Ce dont vous avez besoin au départ

Un responsable sécurité et un responsable ingénierie, une description du modèle ou de l'agent, et l'accès à la conception et à l'environnement hors production. Si le modèle lui-même est encore en construction, cette construction relève d'une mission produit. SEYA examine la façon dont il est déployé et ce qu'il est autorisé à toucher. Si la question ouverte porte sur la politique et les preuves pour un comité, commencez par la gouvernance de l'IA. Si vous voulez que les prompts et les outils soient attaqués dans un délai fixé avant le lancement, commencez par une évaluation de sécurité LLM.

Hors périmètre : la garantie qu'un modèle ne peut pas être trompé, toute affirmation que SEYA ou votre système est certifié NIST, ISO ou autre norme, et un service de détection managé. La preuve publiée de la façon dont SEYA gère la revue de sécurité d'un client est la migration de Boeing GoldCare vers Azure, où l'infrastructure a été contrôlée par Boeing InfoSec avant la mise en service des charges de travail. Cette mission était une migration vers le cloud avec un point de contrôle sécurité, pas un déploiement LLM. Nous la citons parce que le schéma de revue est le même : l'équipe sécurité du client voit la conception avant la production.

Questions fréquentes

Certifiez-vous notre système d'IA ?

Non. SEYA rédige des constats, une conception des contrôles et les preuves que ces contrôles produisent. Une certification, si vous en voulez une, se joue entre vous et l'organisme qui la délivre. Nous n'apposerons pas de marque de certification sur le rapport.

Combien de temps dure une mission de sécurité de l'IA ?

Une première évaluation d'une application tient souvent en quatre à douze semaines, selon le nombre d'outils que l'agent peut appeler et la part de la conception déjà documentée. Un programme multi-produits est cadré en phases, pas comme une revue sans fin.

Allez-vous entraîner ou héberger le modèle ?

Non. La mission couvre la façon dont le modèle ou l'agent est atteint, les données qu'il peut voir et les actions qu'il peut effectuer. Construire le produit est une décision distincte et ne fait pas partie de ce service.

Quels clouds la revue suppose-t-elle ?

AWS, Microsoft Azure et Google Cloud, parce que c'est là que le travail de livraison de SEYA s'exécute déjà. La liste des menaces est la même si le modèle est appelé via une API. La conception des contrôles suit les outils d'identité et de journalisation dont votre plateforme dispose déjà.

Si une fonctionnalité LLM est proche du lancement et que la revue de sécurité n'est encore qu'une diapositive, réservez une évaluation de sécurité cloud et nous vous dirons ce que couvriraient les quatre premières semaines.