Sécurité de l'IA

Conseil en sécurité IA

L'injection de prompt, l'exfiltration de données par la sortie du modèle, l'abus d'outils et l'empoisonnement de la recherche ne sont pas des variantes de vulnérabilités web connues. Nous modélisons spécifiquement les menaces des systèmes d'IA et concevons l'architecture et les contrôles qui contiennent ce que nous trouvons.

Le problème métier

La frontière de confiance a bougé et personne ne l'a redessinée

Dans les applications classiques, données et instructions sont séparées. Dans les systèmes bâtis autour de modèles de langage, elles arrivent par le même canal : tout contenu lu par le modèle est potentiellement une instruction. Cette seule propriété brise des hypothèses dans tout le modèle de sécurité : un document, une page web, un courriel ou un ticket de support peut porter une instruction que le modèle suivra. Ajoutez des outils et un accès aux systèmes, et la conséquence n'est plus une mauvaise réponse mais une action.

Ce que nous faisons

Modéliser la menace, puis contraindre par conception

Nous établissons ce qu'un attaquant viserait et ce qu'il y gagnerait, puis nous concevons de sorte que le dommage atteignable reste borné, que le modèle se comporte bien ou non. Cela signifie des portées d'outils au moindre privilège, des appels d'outils validés, un traitement du contenu récupéré comme non fiable, des points d'approbation sur les actions conséquentes, et des contrôles de sortie là où le texte du modèle atteint un autre système. Nous précisons aussi quoi journaliser, car contenir sans détecter n'est qu'un demi-contrôle.

Conseil en sécurité IA

Compétences

  • AI Threat Modeling

  • LLM Security Architecture

  • Agent Security Architecture

  • AI Risk Assessment

  • Prompt Injection Risk

  • Data Leakage Assessment

  • AI Supply Chain Risk

  • Secure AI Architecture

Cas d'usage courants

Cas d'usage courants

  • Modéliser les menaces d'une application d'IA avant sa mise en production.
  • Établir une architecture de référence sécurisée sur laquelle les autres équipes s'appuient.
  • Auditer un assistant existant disposant d'accès système que personne n'a revus.
  • Définir ce qu'un fournisseur doit prouver avant que sa fonctionnalité IA soit approuvée.

Notre méthode

Notre méthode

  1. Modélisation des menaces

    Établir ce qu'un attaquant viserait et ce qu'il y gagnerait.

  2. Tester

    Tests adverses face à des abus réalistes, pas une liste de chaînes connues.

  3. Restituer

    Constats avec étapes de reproduction, gravité et correctif, classés par exploitabilité.

  4. Retester

    Vérifier que les correctifs tiennent et laisser les tests pour détecter les régressions.

Technologies

Technologies

  • OWASP LLM Top 10
  • MITRE ATLAS
  • Garak
  • Burp Suite
  • ISO/IEC 27001

Sécurité et gouvernance

Sécurité et gouvernance

Les tests sont autorisés par écrit, limités à des cibles convenues et menés sur un environnement hors production sauf décision contraire de votre part. Les constats sont traités comme confidentiels et vous sont communiqués avant quiconque. Rien n'est conservé au-delà de la mission, hormis le rapport et les tests de non-régression que vous nous avez demandé de laisser.

Modèles de collaboration

Modèles de collaboration

Conseil IA

Des consultants experts apportent stratégie, architecture, évaluation et accompagnement de la transformation.

Projet IA

Nous prenons la responsabilité de concevoir et livrer une solution IA définie.

IA managée

Nous exploitons, surveillons et améliorons en continu les systèmes IA en production.

Pourquoi TeamExtension.ai

L'architecture est le seul contrôle durable

Les filtres et les garde-fous sont utiles et finiront par être contournés. Les contrôles qui tiennent sont architecturaux : ce que le système a le droit d'atteindre, ce qu'il peut y faire, et ce qui exige une personne. Nous concevons à partir de cette prémisse, d'où des recommandations qui portent sur les permissions et les frontières plutôt que sur des règles de détection.

Clients sélectionnés

Questions fréquentes

Questions fréquentes

L'injection de prompt peut-elle être résolue ?
Pas éliminée. Elle se réduit par l'architecture : traiter tout contenu récupéré comme non fiable, restreindre étroitement les outils, soumettre les actions conséquentes à approbation, et concevoir pour qu'une injection réussie n'atteigne que du borné. Quiconque promet une prévention totale vend un filtre.
Nos tests d'intrusion actuels couvrent-ils cela ?
Seulement en partie. Les tests classiques couvrent la surface applicative autour du modèle. Ils ne couvrent généralement pas l'injection via le contenu récupéré, l'exfiltration par la sortie du modèle ou l'abus d'outils, car ce ne sont pas des classes de vulnérabilités classiques.
Quel est le constat le plus fréquent ?
Des permissions d'outils trop larges. On accorde un accès étendu pendant le développement parce que c'est commode, et la portée n'est jamais réduite avant la production. C'est aussi, en général, le constat le moins coûteux à corriger.
Comment cela s'articule-t-il avec notre fonction sécurité ?
Elle l'étend. Nous travaillons avec votre équipe sécurité plutôt qu'à côté d'elle, et le livrable est destiné à devenir leur standard plutôt qu'à rester notre rapport. Là où la profondeur propre à l'IA leur manque, nous la construisons avec eux.

Discuter de votre initiative IA

Modéliser les menaces des systèmes IA et concevoir l'architecture, les contrôles et les frontières qui limitent le risque.