Cómo hacer una revisión de seguridad del código que escribe tu agente de codificación con IA

Los agentes de codificación con IA son rápidos, y esa velocidad es un arma de doble filo. Con gusto generarán una funcionalidad operativa en minutos — y con la misma soltura montarán una consulta SQL por concatenación de cadenas, registrarán un secreto en los logs u omitirán una comprobación de autorización. El código funciona, las pruebas pasan y la vulnerabilidad se despliega. La revisión de seguridad no es opcional cuando quien teclea es un agente; es la parte de la que tú sigues siendo responsable.

Aquí tienes un flujo de trabajo práctico e independiente de herramientas para revisar el código generado por IA antes de que llegue a producción.

Saber qué buscar

La mayoría de las vulnerabilidades del mundo real se agrupan en un puñado de patrones. Cuando tú (o una herramienta) revisas la salida del agente, busca primero estos:

• Inyección — entradas de SQL, shell o plantillas construidas concatenando cadenas en lugar de usar consultas parametrizadas.
• Cross-site scripting (XSS) — entrada del usuario renderizada en HTML sin escapado.
• Autenticación/autorización rotas — endpoints que comprueban quién eres pero no si tienes permiso; falta de comprobaciones de propiedad sobre los registros.
• Manejo inseguro de datos — secretos en el código, credenciales en los logs, datos sensibles en los mensajes de error.
• Dependencias vulnerables — un paquete que el agente añadió y que tiene CVEs conocidos.

Estos se corresponden estrechamente con el OWASP Top 10, y son exactamente las categorías que, según Anthropic, busca su revisión de seguridad automatizada. Mantener esta breve lista en mente hace que la revisión manual sea mucho más eficaz.

Usa el agente para revisarse a sí mismo — en un contexto nuevo

El mismo modelo que escribió el código puede revisarlo, pero no de un tirón. Un agente que acaba de pasar 20 turnos haciendo funcionar una funcionalidad está predispuesto a defenderla. Inicia una sesión nueva y dale una única tarea: encontrar los fallos.

Un prompt que funciona bien:

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

La cláusula "concrete exploit scenario" es la parte importante. Obliga al modelo a demostrar que el problema es real en lugar de enumerar vagos tópicos de "considera validar la entrada".

Recurre a las herramientas integradas

Si usas Claude Code, existe un comando dedicado /security-review que analiza tus cambios en busca de patrones de vulnerabilidad comunes y, cuando lo apruebas, aplica las correcciones directamente. Está disponible en los planes de pago Pro y Max y en las cuentas de API de pago por uso.

Para una cobertura continua, Anthropic también publica una GitHub Action de código abierto que se ejecuta en cada pull request y publica comentarios en línea en las líneas exactas que le preocupan. Incorporarla a un repositorio se ve más o menos así:

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

Ahora cada PR — lo haya abierto una persona o un agente — recibe una pasada de seguridad antes de que alguien pulse merge. Cursor, Copilot y otros asistentes ofrecen integraciones de revisión comparables; el principio es el mismo con independencia de la herramienta.

No te saltes las comprobaciones deterministas

La revisión con IA es una potente adición, no un sustituto del aburrido instrumental que nunca se cansa:

• Escaneo de dependencias — npm audit, pip-audit o Dependabot detectan paquetes con vulnerabilidades conocidas que un LLM no reconocerá por su nombre.
• Escaneo de secretos — herramientas como gitleaks o la protección de push de GitHub impiden que una clave filtrada llegue siquiera al historial.
• Análisis estático (SAST) — los linters y herramientas como Semgrep aplican reglas de forma coherente en toda la base de código.

Usa la IA para razonar sobre la lógica y el contexto — "¿puede un usuario autenticado leer aquí los registros de otro usuario?" — y usa los escáneres deterministas para lo mecánico y detectable por patrones. Se cubren mutuamente los puntos ciegos.

Un ejemplo concreto

Supón que tu agente genera este endpoint:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

Una pasada de seguridad debería señalar dos problemas: la consulta es una inyección SQL a punto de suceder (invoice_id interpolado), y no hay comprobación de que la factura pertenezca realmente a user — cualquier cuenta con sesión iniciada puede leer cualquier factura adivinando IDs. La corrección es una consulta parametrizada más un filtro de propiedad:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

La inyección es el tipo de cosa que un escáner detecta. La comprobación de autorización que falta es el tipo de cosa que necesita a alguien — o a un revisor de IA con el prompt adecuado — que entienda para qué sirve el código. Esa es la división que conviene tener presente.

La conclusión

Trata cada diff que produzca tu agente como no confiable hasta que se haya revisado — el mismo estándar que aplicarías al primer pull request de un nuevo compañero de equipo. Combina una revisión de IA en contexto nuevo, una comprobación automatizada de PR y escáneres deterministas, y obtendrás casi toda la velocidad del desarrollo asistido por IA sin heredar sus peores hábitos.