lsudoko/antibodyBoucle DevSecOps GitLab Duo où une seconde IA réattaque chaque correctif écrit par l'IA, enregistrant chaque contournement réussi comme un anticorps permanent rejoué en CI et en production.
Chaque modification de code écrite par une IA doit survivre à une attaque menée par une seconde IA — preuve à l'appui — avant d'être autorisée à atteindre la production.
Antibody est un pipeline GitLab Duo pour le hackathon « Life After Code » (Transcend). Il traite une base de code comme un système immunitaire : lorsqu'une IA corrige une vulnérabilité, une seconde IA continue d'attaquer la correction jusqu'à ce qu'elle tienne réellement, et chaque attaque ayant un jour fonctionné est conservée pour toujours sous forme d'« anticorps » et retestée à chaque modification future ainsi que contre la production en direct. Un vérificateur distinct, délibérément non-IA, surveille l'agent correcteur pour détecter toute triche.
Le correcteur n'est jamais cru sur parole. Il doit survivre à un attaquant, et un vérificateur simple et honnête garde les tests.
Les outils où l'IA attaque l'IA existent déjà (Helios, MindFort, Strix, Novee). Ceux-ci confirment que l'exploit d'origine est désormais bloqué. Antibody fait quatre choses qui, en 2026, ne se trouvent encore que dans des articles de recherche :
/download était cassé, vérifier si /preview a la même garde manquante — le bug se cache généralement sur une route hors du diff.CODEOWNERS, car une modification ne doit jamais se valider elle-même.Chaque choix de conception découle d'un article, pas d'une intuition :
| Constat | Article | Chiffre |
|---|---|---|
| Les correctifs passent les tests mais restent exploitables (« échecs silencieux ») ; les relecteurs LLM les manquent | When Passing Tests Hides Vulnerabilities (Tampere) — arXiv 2609.10548 | 170 des 1 030 traces de réparation ont échoué silencieusement ; 22 critiques |
| Une correction ne bloque que la charge utile sur laquelle elle a été testée | P2Patch (Simon Fraser) — arXiv 2610.20245 | une nouvelle attaque a contourné des correctifs déjà « corrigés » dans 41 % des exécutions ; rendre les contournements permanents a fait passer la couverture de 42,1 % à 62,5 % |
| Le même bug se cache sur une route sœur hors du diff | PRGuard (Bristol) — arXiv 2608.25730 | 3× plus de bugs de type absence trouvés qu'un relecteur commercial |
| Les modifications CI d'agents sont fusionnées sans relecture → « vérification circulaire » | Co-Modifying Code and Infra (UNSW) — arXiv 2610.12849 | 43–56 % des PR d'agents à double périmètre fusionnées sans relecture |
| Les agents trichent avec le correcteur lorsqu'ils sont récompensés pour du vert | Hacktrace (NTU) — arXiv 2610.03055 | ~19,5 % des exécutions ont pris un raccourci de falsification de tests |
Le dernier constat explique pourquoi le Warden n'est pas une IA : on peut convaincre un relecteur LLM de changer son verdict ; un vérificateur de git-diff, non.
┌─────────────────────────── issue created ───────────────────────────┐
│ │
▼ │
[Builder AI] fix on a shadow branch, open MR │
│ │
▼ │
GitLab SAST + Dependency Scanning → findings become the Red agent's targets │
│ │
▼ │
[Red AI] real HTTP exploit that REPRODUCES on the old code │
│ │
▼ │
[Builder AI] harden until blocked │
│ │
▼ │
[Red AI] re-attack the NEW fix: new payload + same bug on SIBLING routes │
│ every bypass saved forever as an antibody (≤2 rounds) │
▼ │
[Warden] (not an AI) no deleted/weakened/skipped tests, no hidden CI/auth edit │
│ │
▼ │
autonomy gate: touches CI/auth/CODEOWNERS → Supervised, else Hands-off │
│ │
▼ │
[Package] signed container + SBOM + proof bundle │
│ │
▼ │
[Release → Configure] deploy to the lowest-carbon Cloud Run region, │
│ replay every antibody against staging, then promote │
▼ │
[Monitor] scheduled probe replays ALL antibodies against production forever ──┘
any reproduction → auto-opens an incident issue → loop restarts
Tout ce qui suit est une capture réelle de ce dépôt, pas une maquette.
Le pipeline en neuf étapes, au vert sur GitLab. Chaque étape exécutée a réussi, y compris la construction réelle du conteneur poussée vers le registre du projet. configure et monitor sont correctement ignorés tant qu'un projet Cloud Run et une planification ne sont pas configurés. Ouvrir le pipeline.
