Antibody

Jede von einer KI geschriebene Codeänderung muss einen Angriff einer zweiten KI – mit Nachweis – überstehen, bevor sie die Produktion erreichen darf.

Antibody ist eine GitLab-Duo-Pipeline für den Hackathon „Life After Code" (Transcend). Sie behandelt eine Codebasis wie ein Immunsystem: Wenn eine KI eine Schwachstelle behebt, greift eine zweite KI den Fix so lange an, bis er tatsächlich hält, und jeder Angriff, der jemals erfolgreich war, wird für immer als „Antikörper" gespeichert und bei jeder zukünftigen Änderung sowie gegen die laufende Produktion erneut getestet. Ein separater, bewusst nicht-KI-basierter Prüfer überwacht den reparierenden Agenten auf Betrug.

Dem Fixer wird nie aufs Wort geglaubt. Er muss einen Angreifer überstehen, und ein simpler, ehrlicher Prüfer bewacht die Tests.

Warum das anders ist

Werkzeuge, bei denen KI gegen KI antritt, gibt es bereits (Helios, MindFort, Strix, Novee). Diese bestätigen, dass der ursprüngliche Exploit nun blockiert ist. Antibody tut vier Dinge, die Stand 2026 noch immer nur in Forschungsarbeiten zu finden sind:

1. Adversarialer Re-Angriffs-Loop. Führe nicht den alten Exploit erneut aus. Generiere einen neuen Angriff gegen den neuen Fix und mache jede erfolgreiche Umgehung zu einer dauerhaften Anforderung.
2. Suche nach Schwesterpfaden. Wenn /download fehlerhaft war, prüfe, ob /preview dieselbe fehlende Absicherung hat – der Bug versteckt sich meist auf einer Route außerhalb des Diffs.
3. Ein System für beides: Sicherheitsangriffe und Erkennung von Agenten-Betrug. Bestehende Werkzeuge leisten nur das eine oder das andere.
4. Selbstabsenkende Autonomie. Die Pipeline wechselt von Hands-off zu Supervised, sobald eine Änderung CI-Konfiguration, Auth oder CODEOWNERS berührt, denn eine Änderung darf sich niemals selbst validieren.

Fundiert in Forschung aus 2026

Jede Designentscheidung lässt sich auf eine Arbeit zurückführen, nicht auf ein Bauchgefühl:

Erkenntnis	Paper	Zahl
Patches bestehen Tests und bleiben dennoch ausnutzbar („silent failures"); LLM-Reviewer übersehen sie	When Passing Tests Hides Vulnerabilities (Tampere) — arXiv 2609.10548	170 von 1.030 Reparatur-Traces schlugen still fehl; 22 kritisch
Ein Fix blockiert nur die Payload, mit der er getestet wurde	P2Patch (Simon Fraser) — arXiv 2610.20245	ein frischer Angriff umging bereits „gefixte" Patches in 41 % der Läufe; das Festschreiben von Umgehungen hob die Abdeckung von 42,1 % auf 62,5 %
Derselbe Bug versteckt sich auf einer Schwesterroute außerhalb des Diffs	PRGuard (Bristol) — arXiv 2608.25730	3× mehr Bugs vom Typ „fehlende Prüfung" gefunden als ein kommerzieller Reviewer
CI-Änderungen von Agenten werden ungeprüft gemergt → „zirkuläre Verifikation"	Co-Modifying Code and Infra (UNSW) — arXiv 2610.12849	43–56 % der Agenten-PRs mit doppeltem Scope wurden ohne Review gemergt
Agenten betrügen den Bewerter, wenn Grün belohnt wird	Hacktrace (NTU) — arXiv 2610.03055	~19,5 % der Läufe nahmen eine Abkürzung durch Manipulation der Tests

Die letzte Erkenntnis ist der Grund, warum der Warden keine KI ist: Einem LLM-Reviewer kann man sein Urteil ausreden; einem Git-Diff-Prüfer nicht.

Der Loop

          ┌─────────────────────────── 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

So funktioniert es

Alles Folgende ist eine echte Aufzeichnung aus diesem Repository, kein Mock-up.

Die neunstufige Pipeline, grün auf GitLab. Jede ausgeführte Stufe war erfolgreich, einschließlich des echten Container-Builds, der in die Projekt-Registry gepusht wurde. configure und monitor werden korrekt übersprungen, bis ein Cloud-Run-Projekt und ein Zeitplan konfiguriert sind. Pipeline öffnen.