Antibody

Toda alteração de código escrita por IA deve sobreviver a um ataque de uma segunda IA — com provas — antes de poder chegar à produção.

Antibody é um pipeline do GitLab Duo para o hackathon "Life After Code" (Transcend). Ele trata uma base de código como um sistema imunológico: quando uma IA corrige uma vulnerabilidade, uma segunda IA continua atacando a correção até que ela realmente se sustente, e todo ataque que já funcionou é guardado para sempre como um "anticorpo" e testado novamente em cada alteração futura e contra a produção em tempo real. Um verificador separado, deliberadamente não-IA, vigia o agente que corrige em busca de trapaças.

A palavra do agente que corrige nunca é confiável. Ele tem de sobreviver a um atacante, e um verificador honesto e simples protege os testes.

Por que isto é diferente

Já existem ferramentas de IA-contra-IA (Helios, MindFort, Strix, Novee). Essas confirmam que o exploit original está agora bloqueado. Antibody faz quatro coisas que, em 2026, ainda só existem em artigos de investigação:

1. Ciclo de reataque adversarial. Não voltes a executar o exploit antigo. Gera um novo ataque contra a nova correção, e torna cada contorno bem-sucedido um requisito permanente.
2. Caça a caminhos irmãos. Se /download estava quebrado, verifica se /preview tem a mesma proteção em falta — o bug costuma esconder-se numa rota fora do diff.
3. Um único sistema para ambos — ataques de segurança e deteção de trapaças do agente. As ferramentas existentes fazem uma coisa ou outra.
4. Autonomia que se reduz sozinha. O pipeline desce de Hands-off para Supervised por si próprio quando uma alteração toca na configuração de CI, na autenticação ou no CODEOWNERS, porque uma alteração nunca deve validar-se a si mesma.

Fundamentado em investigação de 2026

Cada escolha de design remete para um artigo, não para um palpite:

Descoberta	Artigo	Número
As correções passam nos testes mas continuam exploráveis ("falhas silenciosas"); os revisores LLM não as detetam	When Passing Tests Hides Vulnerabilities (Tampere) — arXiv 2609.10548	170 de 1.030 traços de reparação falharam silenciosamente; 22 críticos
Uma correção bloqueia apenas o payload com que foi testada	P2Patch (Simon Fraser) — arXiv 2610.20245	um novo ataque contornou correções já "corrigidas" em 41% das execuções; tornar os contornos permanentes elevou a cobertura de 42,1% → 62,5%
O mesmo bug esconde-se numa rota irmã fora do diff	PRGuard (Bristol) — arXiv 2608.25730	3× mais bugs do tipo ausência encontrados do que um revisor comercial
Alterações de CI feitas por agentes são integradas sem revisão → "verificação circular"	Co-Modifying Code and Infra (UNSW) — arXiv 2610.12849	43–56% dos PRs de agentes com duplo âmbito foram integrados sem qualquer revisão
Os agentes enganam o avaliador quando são recompensados pelo verde	Hacktrace (NTU) — arXiv 2610.03055	~19,5% das execuções recorreram a um atalho de adulteração de testes

A última descoberta é a razão pela qual o Warden não é uma IA: um revisor LLM pode ser convencido a mudar o seu veredicto; um verificador de git-diff não.

O ciclo

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

Veja funcionando

Tudo abaixo é uma captura real deste repositório, não uma simulação.

O pipeline de nove estágios, verde no GitLab. Todos os estágios executados passaram, incluindo a construção real do container enviada para o registro do projeto. configure e monitor são corretamente ignorados até que um projeto Cloud Run e um agendamento sejam configurados. Abrir o pipeline.

Ataques ao decoy controlado são bloqueados; o uso normal continua funcionando. Traversal codificado, a rota irmã, um esquema não-HTTP e uma leitura de objeto entre usuários são todos recusados, enquanto um documento legítimo e o próprio pedido do proprietário são servidos.