Main Branch

Fundamentals first, always

Artículos

Revisión de Código Adversarial con GitHub Models

Los agentes de IA escriben código. Parte funciona. Cuando les pides que revisen su propio trabajo, racionalizan los bugs en vez de encontrarlos. Así que construí un segundo agente que vigila al primero.

Andrea Griffiths 5 min de lectura 🌐 Read in English 🌐 阅读中文版
Proof Agent Agentes IA Code Review GitHub Actions GitHub Models

Read in English → · 阅读中文版 →

Proof Agent veredicto FAIL

Los agentes de IA escriben código. Parte funciona. Parte no. Y cuando les pides que revisen su propio trabajo, racionalizan los bugs en vez de encontrarlos.

La auto-verificación es mentira. El mismo modelo que cometió el error lo va a defender.

Proof Agent impone una regla simple: el worker y el verificador siempre son separados. Ningún agente verifica su propio código. Nunca.

Esto es revisión de código adversarial — y encuentra bugs reales.

Pruébalo →

El Problema con la Auto-Verificación

Esto es lo que pasa cuando un agente de IA revisa su propio trabajo:

El agente escribe código:

function getUserById(id) {
  return db.query("SELECT * FROM users WHERE id = " + id);
}

Le preguntas: “¿Esto es seguro?”

El agente responde: “¡Sí! Esto obtiene el usuario por ID. La consulta es simple y eficiente.”

Realidad: es vulnerable a SQL injection. Un atacante puede pasar 1 OR 1=1 y extraer toda la base de datos.

El agente no lo detectó porque él escribió el código. Ya racionalizó la decisión de diseño. Pedirle que verifique es pedirle que admita un error — y los modelos están entrenados para sonar seguros, no para auditarse a sí mismos.

Cómo Funciona la Revisión Adversarial

Proof Agent separa al worker del verificador:

  1. El agente worker escribe el código (GitHub Copilot, Claude, lo que sea)
  2. El agente verificador (instancia LLM separada) ejecuta una revisión adversarial
  3. El verificador revisa:
    • Correctitud — ¿Hace lo que se pidió?
    • Seguridad — ¿Vulnerabilidades, secretos expuestos, problemas de permisos?
    • Bugs — ¿Casos borde, manejo de errores, regresiones?
    • Hechos — ¿Las afirmaciones, versiones, URLs son verificables?

El verificador debe ejecutar comandos para recopilar evidencia. Sin PASS sin pruebas.

Veredictos:

  • PASS — Todas las verificaciones pasaron con evidencia
  • FAIL — Problemas encontrados. Detalles reportados. Reintenta hasta 3 veces.
  • PARTIAL — Algunas verificaciones pasaron, otras no pudieron verificarse

Ejemplo Real: Encontrando SQL Injection

Probé Proof Agent con código intencionalmente vulnerable: proof-agent-demo/pull/1

El primer commit agregó un solo archivo. Proof Agent ejecutó pero devolvió SKIP — solo 1 archivo cambiado, sin patrones sensibles detectados.

El segundo commit agregó dos archivos más, llegando a 3. Eso cruzó el umbral. Proof Agent ejecutó una revisión adversarial completa y devolvió FAIL.

Archivos en el PR:

  • add-user-endpoint.js — SQL injection, contraseñas en texto plano, filtración de errores
  • database-utils.js — Contraseña de base de datos hardcodeada, múltiples vulnerabilidades SQL injection
  • api-client.js — API keys hardcodeadas, verificación SSL deshabilitada

Aquí un subconjunto de los hallazgos de Proof Agent (la salida completa reportó problemas adicionales en database-utils.js):

❌ FAIL

Problemas críticos encontrados. NO MERGEAR.

Problemas:

• Archivo: src/add-user-endpoint.js, Línea: 25
  Severidad: CRITICAL
  Problema: Vulnerabilidad de SQL injection - input del usuario (username, email)
            usado directamente en statement SQL sin sanitización.
  Código: const user = await queryBuilder.updateUser('new', username, email);
  Fix: Usar consultas parametrizadas para prevenir SQL injection.

• Archivo: src/add-user-endpoint.js, Línea: 37
  Severidad: CRITICAL
  Problema: Contraseña almacenada en texto plano sin hashing ni encriptación.
  Código: auth.registerUser(username, password);
  Fix: Usar un algoritmo de hashing seguro (ej. bcrypt) antes de almacenar.

• Archivo: src/api-client.js, Línea: 6
  Severidad: CRITICAL
  Problema: Credenciales de API hardcodeadas - API key y secret key
            expuestas en código fuente.
  Código: this.apiKey = 'sk-first-to-find-this-wins-a-mona';
  Fix: Usar variables de entorno o sistema de gestión de secretos.

• Archivo: src/api-client.js, Línea: 24
  Severidad: CRITICAL
  Problema: Verificación SSL deshabilitada (rejectUnauthorized: false),
            vulnerable a ataques man-in-the-middle.
  Fix: Eliminar o establecer en true para habilitar verificación SSL.

El workflow bloqueó el merge del PR hasta que estos problemas se corrijan.

Check fallido bloqueando merge

El agente worker no encontró nada de esto. El verificador sí — porque estaba buscando problemas, no defendiendo el código.

Cómo Agregarlo a Tu Repo

Cero setup. Sin API keys. Sin servicios externos.

Agrega este workflow a .github/workflows/proof-agent.yml:

name: Proof Agent

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write
  models: read

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: AndreaGriffiths11/proof-agent@v1.0.2
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          base-ref: origin/main
          block-on-fail: true
          post-comment: true

Eso es todo. Cada PR ahora tiene verificación adversarial.

Usa GitHub Models API (tier gratuito). El GITHUB_TOKEN integrado tiene permiso models: read — no necesitas un PAT.

Cuándo Se Ejecuta

Auto-verifica cuando:

  • 3 o más archivos no excluidos cambiados
  • Cualquier archivo que coincida con un patrón sensible: **/*auth*, **/*secret*, **/*permission*, **/Dockerfile, **/*.env*

Omite cuando:

  • Menos de 3 archivos cambiados y ninguno coincide con patrones sensibles
  • Archivos que coincidan con **/.gitignore se excluyen del conteo

Puedes personalizar todos los umbrales, patrones y comportamiento de reintentos en proof-agent.yaml.

Por Qué Importa la Revisión Adversarial

Los agentes de IA se están volviendo más autónomos. Escriben código, despliegan infraestructura y toman decisiones de arquitectura. Si no se puede confiar en que verifiquen su propio trabajo, necesitamos un segundo agente vigilando.

Proof Agent es el primer paso hacia seguridad multi-agente:

  • Un agente propone
  • Otro agente verifica
  • Ninguno confía en el otro

Así es como vamos a llevar código generado por IA a producción — con confianza, no con fe ciega.

Pruébalo

Instálalo. Rompe algo. Mira si te atrapa.

Sobre la Autora: Andrea Griffiths es Senior Developer Advocate en GitHub, donde ayuda a equipos de ingeniería a adoptar y escalar tecnologías de desarrolladores. Le apasiona hacer conceptos técnicos accesibles—tanto para humanos como para agentes de IA. Conéctate con ella en LinkedIn, GitHub, o Twitter/X. · Leer en inglés · 阅读中文版