Skip to content
injentik

AI red team · offensive security

On ne teste pas votre modèle.
On teste ce que votre modèle peut faire faire à vos systèmes.

Chaîne d'attaque· exemple
  1. 01UNTRUSTEDsupport-ticket.md → ingested by RAG
  2. 02LLMfollows embedded instruction
  3. 03TOOL CALLGET 169.254.169.254/latest/meta-data/SSRF
  4. 04INTERNALiam/security-credentials/ exfiltrated
  5. 05PIVOTvalid creds → internal APIOWN
Un document empoisonné, suivi jusqu'à l'accès au SI.

Sécurité offensive des systèmes d'IA, ancrée dans le red teaming — pas dans le ML. Le jailbreak n'est pas la faille. La SSRF, le token trop large et le pivot derrière, si.

Indépendant · Cabinet de sécurité offensive · Certifié HTB COAE

[01]Le problème

Un LLM dans votre stack n'est pas un chatbot. C'est un nouvel appelant à l'intérieur de votre périmètre — qui lit du contenu non fiable, détient des identifiants et déclenche des outils.

LLM01

Injection de prompt indirecte

Les instructions ne viennent pas forcément de votre utilisateur. Un ticket de support, une page scrapée, un PDF dans votre index RAG — n'importe lequel peut porter une charge que votre modèle exécutera.

Un document empoisonné dans la base de connaissances demande à l'assistant d'appeler une URL interne, et sa réponse revient avec votre endpoint de métadonnées en pièce jointe.

LLM06

Abus des agents et des appels d'outils

Donnez des outils à un modèle et vous lui donnez de la portée. Si l'agent tourne avec des permissions plus larges que l'utilisateur en face, le modèle devient un adjoint dupé muni d'une clé d'API.

Un agent censé « lire les commandes de l'utilisateur » est détourné pour appeler un endpoint d'administration interne auquel l'utilisateur n'a jamais eu droit.

LLM02

Fuite de données d'entraînement et de contexte

Ce sur quoi le modèle a été entraîné, affiné ou ce qu'on lui passe à l'inférence peut ressortir — y compris des données appartenant à un autre client.

Un prompt soigneusement construit reconstitue un enregistrement de fine-tuning, et un locataire lit les données d'un autre.

[02]Services

Quatre missions. Choisissez celle qui colle à l'endroit où se trouve réellement votre IA.

013 jours

AI Readiness Review

Ce qui est testé

Revue d'architecture, cartographie de la surface d'attaque IA sur vos modèles, flux de données et intégrations d'outils, analyse d'écart face à un référentiel reconnu.

Ce que vous obtenez

Une cartographie de surface, une liste priorisée des points d'exposition, et une note courte sur l'endroit où un audit rapporterait le plus vite.

026–8 jours

AI Application Security Assessment

Ce qui est testé

Une application LLM/RAG en fonctionnement, de bout en bout — injection directe et indirecte, fuite de contexte et de system prompt, RBAC sur les sources, et abus de la chaîne applicative dans laquelle le modèle s'insère.

Ce que vous obtenez

Des findings reproductibles avec requêtes de preuve, l'impact métier par problème, et une remédiation concrète à passer à vos équipes.

034–5 jours

AI Data & Privacy Assessment

Ce qui est testé

Membership inference, extraction de modèle et de données d'entraînement, fuite inter-locataires, et l'exposition en matière de protection des données qui en découle — rattachée aux obligations RGPD.

Ce que vous obtenez

Un rapport d'exposition des données, les chemins d'extraction démontrés quand ils existent, et une vue du risque privacy exploitable par votre DPO.

0410–12 jours

Agentic Red Team

Ce qui est testé

Des agents avec de vrais outils et des intégrations MCP — abus d'appels d'outils, escalade de privilèges via les permissions d'agent, et chaînes multi-étapes qui transforment un maillon faible en accès au SI.

Ce que vous obtenez

Le récit complet de l'attaque, de l'entrée à l'impact, la chaîne reproduite étape par étape, et les mesures de confinement qui la brisent.

[03]Méthodologie

Les findings se rattachent aux référentiels que votre COMEX vous demande déjà.

Chaque problème est relié à une référence publique pour tenir face à l'examen — de vos ingénieurs, de vos auditeurs et de vos clients qui vous soumettent à un vendor security review.

OWASP
OWASP LLM Top 10Classification de chaque finding face à la liste des risques des applications LLM.
MITRE
MITRE ATLASTactiques et techniques adverses pour les systèmes de machine learning.
GOOGLE
Google SAIFAlignement au niveau des contrôles avec le Secure AI Framework.
NIST
NIST AI RMFRattachement gouvernance et fonctions de risque pour les parties prenantes.

[04]À propos

On vient de la sécurité offensive, pas du ML.

Injentik est un cabinet indépendant de sécurité offensive. Les personnes qui cadrent votre mission sont celles qui écrivent l'exploit et présentent les résultats — pas de chargé de compte, pas de passage de relais à un junior.

Le parcours, c'est du red teaming offensif classique. Et ça compte : la plupart des offres de red teaming IA viennent du ML et s'arrêtent au jailbreak. Injentik vient du côté attaquant et suit la chaîne derrière — jusque dans l'appli, les tokens et le réseau.

Les tests sont menés au standard HTB COAE — Certified Offensive AI Engineer, un examen pratique de sept jours conçu avec Google. Chaque finding est rattaché à un référentiel public, pour tenir face à l'examen.

certificationverified
HTB COAECertified Offensive AI Engineer

[05]Obtenir le rapport type

Voyez à quoi ressemble vraiment un finding.

Le rapport type est le compte rendu anonymisé d'une mission — une vraie chaîne, de l'injection indirecte à l'accès interne, avec les étapes de reproduction et le correctif. Laissez un email professionnel et il arrive directement dans votre boîte.

Vous préférez échanger d'abord ? Utilisez le même formulaire et dites-le dans le message.

injentik-sample-report.pdfredacted
  1. 01Synthèse
  2. 02La chaîne
  3. 03Preuve de concept
  4. 04Impact
  5. 05Remédiation
  6. 06Rattachement aux référentiels