Évaluation de sécurité des LLM et red teaming

L'évaluation de sécurité des LLM de SEYA Group est un red teaming à périmètre fixe d'une fonctionnalité de modèle linguistique : nous testons les prompts, les outils que le modèle peut appeler et les chemins de données accessibles à ces outils, puis nous rédigeons un rapport sur lequel vos responsables de la sécurité et de l'ingénierie peuvent agir. Une évaluation type s'étend sur deux à quatre semaines et est pilotée depuis notre bureau de Vancouver. Il s'agit d'un test et d'un rapport, pas d'une certification.

À qui s'adresse cette offre

Responsables de la sécurité et du produit qui ont une date de lancement pour un chatbot, un assistant de retrieval ou un agent interne, et qui ont besoin d'un passage indépendant avant cette date. Équipes qui ont déjà rempli un questionnaire fournisseur et ne peuvent toujours pas dire ce qui se passe si un utilisateur ou un document lu par le modèle lui demande d'ignorer ses instructions.

Ce que vous obtenez

• Une note de périmètre. La fonctionnalité, les environnements, les identités, les outils en jeu et ce qui est hors périmètre. Les données clients de production ne sont pas copiées chez SEYA.
• Une méthode de test. Des cas issus du OWASP Top 10 for LLM Applications : injections de prompt directes et indirectes, tentatives d'extraction de secrets ou de contenu d'autres utilisateurs, appels d'outils en dehors de la liste autorisée, et contenu empoisonné ou inattendu dans l'index de retrieval. Nous enregistrons chaque cas, l'entrée et le comportement observé.
• Un rapport. Des constats classés selon ce que le modèle a pu faire, avec les preuves jointes, et une courte liste de changements de contrôles. Le rapport ne dit pas que la fonctionnalité est sûre en général. Il indique ce que ces tests ont et n'ont pas permis de constater.
• Une restitution. Une session de travail avec vos responsables de la sécurité et de l'ingénierie. Les correctifs que vous choisissez de mettre en œuvre peuvent se poursuivre comme conception de contrôles de sécurité de l'IA ou comme vérifications DevSecOps dans le pipeline.

Déroulement d'une mission

• Semaine 0, cadrage. Accès à une build non production, le prompt système ou la politique que vous acceptez de partager, et la liste des outils.
• Semaines 1 à 3, tests. Nous exécutons les cas, les ajustons lorsqu'un contrôle bloque la forme évidente de l'attaque, et nous nous arrêtons à la limite du périmètre. Nous n'attaquons pas les systèmes qui n'ont pas été nommés.
• Dernière semaine, rapport et restitution. Vous recevez le rapport écrit et la session. Deux à quatre semaines est la fourchette habituelle pour une fonctionnalité. Un second produit correspond à un second périmètre.

Ce dont vous avez besoin

Une build que nous pouvons appeler, un responsable qui peut expliquer la politique d'outils prévue, et l'accord pour que les constats soient rédigés clairement. Si vous n'avez pas encore de politique sur ce que l'assistant est autorisé à faire, les questions de gouvernance relèvent de la page gouvernance de l'IA et peuvent être menées avant ou en parallèle de ce test.

Hors périmètre : entraîner un modèle, la promesse qu'un prompt ultérieur ne réussira pas, et toute affirmation selon laquelle SEYA ou la fonctionnalité détient une certification de sécurité. Pour un exemple d'examen de la sécurité par un client sur un travail de SEYA, voir l'examen InfoSec de Boeing sur l'infrastructure Azure pour GoldCare. Cet examen portait sur une plateforme cloud, pas sur un LLM. Nous le citons uniquement comme schéma : l'équipe sécurité du client voit les preuves avant la mise en production.

Questions fréquentes

S'agit-il d'un test d'intrusion sur l'ensemble de notre entreprise ?

Non. Le périmètre est la fonctionnalité LLM que vous nommez : ses prompts, outils et chemins de données. Le test d'intrusion réseau sur le parc élargi est une autre mission et n'est pas regroupé dans ces deux à quatre semaines.

À quoi ressemble le rapport ?

Une déclaration de périmètre, les cas de test, ce que chaque cas a produit, et des changements de contrôles recommandés. Il est rédigé pour un responsable de la sécurité et un responsable de l'ingénierie. Ce n'est pas une lettre d'attestation et il n'a pas de marque de certification.

Pouvez-vous retester après correction des constats ?

Oui, sous la forme d'un court suivi sur les mêmes cas, avec un périmètre distinct. Le premier rapport reste la référence. Une réussite au retest signifie que ces cas n'ont plus abouti, pas que la fonctionnalité est sûre face à tout prompt futur.

Si une date de lancement figure déjà au calendrier, Réserver une évaluation de sécurité cloud et envoyez la description de la fonctionnalité. Nous vous dirons si deux à quatre semaines suffisent pour ce périmètre.