AI red-teaming : attaquer ses propres LLMs avant les autres

MITRE ATLAS (Adversarial Threat Landscape for AI Systems) = équivalent MITRE ATT&CK mais pour l'IA. Référence mondiale, mise à jour 2x/an, utilisée par DoD, NSA, Microsoft, Google.

Phase 1 : Reconnaissance

TA0043 — Collecte d'infos : identifier le modèle utilisé (GPT-5 ? Claude ? local ?), les sources de training, les APIs exposées, les guardrails connus.

Phase 2 : Resource Development

TA0042 — Préparation des outils : créer datasets adversariaux, training de proxies, infrastructure d'attaque.

Phase 3 : Initial Access

TA0001 — Pénétration initiale : compte légitime, modèle public, API exposée, prompt injection via document.

Phase 4 : ML Model Access

AML.T0040 — Accès au modèle : interface de chat, API, bibliothèque cliente, modèle téléchargé.

Phase 5 : Execution

AML.T0050 — Exécution malveillante : runtime du modèle, sandbox escape, code execution via tool calls.

Phase 6 : Persistence

AML.T0010 — Persistance : poisoning de données d'entraînement, backdoor dans modèle, RAG poisoning.

Phase 7 : Privilege Escalation

AML.T0011 — Élévation de privilèges : exploitation de bugs runtime, escape de sandbox.

Phase 8 : Defense Evasion

AML.T0015 — Contourner défenses : evasion d'input classifier, encoding tricks, multi-turn attacks.

Phase 9 : Credential Access

AML.T0024 — Vol de credentials : exfiltration de clés API via prompts, contournement secrets management.

Phase 10 : Discovery

AML.T0025 — Reconnaissance interne : enumerate des outils dispo, des datasets accessibles, des comptes liés.

Phase 11 : Collection

AML.T0035 — Collecte de données : exfiltration de PII, secrets business, training data leak.

Phase 12 : ML Attack Staging

AML.T0017 — Préparation de l'attaque finale : génération d'adversarial inputs, model inversion.

Phase 13 : Exfiltration

AML.T0024 — Exfiltration de données ou du modèle (model stealing).

Phase 14 : Impact

AML.T0029 — Impact business : déni de service IA, dégradation de qualité, manipulation de décisions.

Outils utilisés à chaque phase

| Phase | Outil 2026 | Statut | |-------|------------|--------| | Reconnaissance | LLM Probe, ModelScan | Open-source | | Attack development | Garak (NVIDIA), PyRIT (MS) | Open-source | | Execution | Lakera Red, Robust Intelligence | Commercial | | Detection | LangSmith, Helicone, Weights & Biases | Commercial | | Reporting | Markdown + JSON ATLAS schema | Standards |

1. Tester en prod sans isolation

❌ Risquer de leak vraies données utilisateur ou casser le service. ✅ Toujours un environnement de test isolé avec données synthétiques.

2. Se concentrer uniquement sur les jailbreaks (focus visible)

❌ Les jailbreaks (DAN, etc.) sont visibles mais pas les plus dangereux. ✅ Couvrir aussi : data exfil silencieuse, model inversion, prompt injection indirecte. 80% des vraies attaques sont silencieuses.

3. Ne pas re-tester après les fixes

❌ Le dev ferme le ticket "fixed" et personne ne valide. ✅ Re-test obligatoire par red-team. Souvent la fix bouge le problème ailleurs.

4. Pas de suivi temporel (one-shot annuel)

❌ Red-team 1x/an = inutile. Le modèle change, les attaques évoluent. ✅ Cadence mensuelle minimum + tests CI/CD à chaque release.

5. Confondre red-team et bug bounty

❌ Bug bounty = attaques externes ad-hoc. Pas méthodologique, pas exhaustif. ✅ Red-team = méthode structurée + bug bounty en complément (deux choses différentes).