¿Es legal el pentesting automatizado con AI Agent? La respuesta corta es: depende de autorización, alcance, impacto, manejo de datos y divulgación. Que una herramienta use IA o sea open source no hace legal cualquier prueba.
Herramientas tipo Strix combinan agentes, ejecución dinámica, validación de vulnerabilidades, reportes y sugerencias de corrección. Son útiles para defensa, pero exigen límites claros.
Esto no es asesoría legal. En pentests reales, bug bounty, sistemas de clientes, producción o pruebas transfronterizas, sigue contratos, reglas de plataforma, leyes locales y asesoría legal.
Respuesta corta
| Escenario | Riesgo |
|---|---|
| Código propio, entorno de prueba o repositorio autorizado | menor, pero requiere controles |
| Sistema de cliente bajo contrato | requiere autorización escrita, alcance, ventana y reglas |
| Sitios públicos desconocidos, cloud assets o APIs de terceros | alto sin permiso explícito |
Antes de ejecutar:
- ¿Quién es dueño del objetivo?
- ¿La autorización está escrita y clara?
- ¿El scope incluye este dominio, API, cuenta y entorno?
- ¿El Agent podría acceder, copiar, modificar o dañar datos?
- ¿Cómo se reportan y protegen los hallazgos?
- ¿Hay logs, aprobaciones y revisión humana?
Si no puedes responder, no lo ejecutes.
Por qué los AI Agents hacen más sensible el cumplimiento
Un scanner tradicional suele ser más predecible. Un AI Agent puede explorar páginas, combinar pistas, invocar herramientas, generar ideas de prueba, usar navegador o proxy y guardar reportes.
En sistemas propios o autorizados es útil. En objetivos no autorizados aumenta el riesgo.
La autorización es la primera línea
Debe ser escrita y auditable. Debe definir:
- propietario del objetivo;
- dominios, IPs, repositorios, apps y APIs permitidos;
- sistemas excluidos;
- ventana de prueba;
- cuentas y permisos;
- si se permite automatización;
- si se permite validar vulnerabilidades;
- si se puede ver datos reales;
- contacto de parada urgente;
- reporte y confidencialidad.
Para AI Agent, añade:
- exploración dinámica permitida o no;
- generación de PoC;
- ejecución en CI/CD;
- envío de logs, código o requests a modelos externos;
- proveedor de modelo y retención de datos.
Público no significa autorizado
Que un sitio sea público no significa que puedas probarlo con automatización. Navegar no equivale a testear APIs, autenticación o lógica de negocio.
Cuidado especial con:
- gobierno, salud, educación, finanzas;
- infraestructura crítica;
- SaaS y cloud de terceros;
- competidores;
- plataformas con datos de usuarios;
- sistemas sin política de divulgación;
- sitios que prohíben automatización.
Bug bounty y VDP también tienen límites: scope, prohibiciones, rate limits y reglas de reporte.
La investigación de buena fe también tiene límites
La política CFAA del DOJ menciona investigación de seguridad de buena fe, pero eso no significa que decir “investigación” haga seguro cualquier acto. Importan propósito, evitar daño, uso de la información y jurisdicción.
Las reglas cambian por país. Las pruebas transfronterizas son especialmente delicadas.
Acciones que cruzan límites fácilmente
1. Escanear sin autorización
Ejecutar un Agent automático contra un objetivo desconocido es de alto riesgo.
2. Salirse del scope
Si solo se autorizó staging.example.com y el Agent llega a producción, pagos, proveedores o sistemas internos, puede estar fuera de alcance.
3. Acceder a datos reales
No leas, descargues, captures ni guardes grandes cantidades de datos reales para demostrar un bug.
4. Validación destructiva
Borrar datos, interrumpir servicios, generar costes, bloquear cuentas, enviar emails o cambiar pagos requiere autorización explícita y entorno aislado.
5. Divulgación prematura
Reporta por el canal acordado y da tiempo razonable para corregir.
6. Exigir dinero con presión
Fuera de un bounty acordado, usar una vulnerabilidad para exigir pago puede verse como coerción.
Cómo usar herramientas tipo Strix en empresa
Empieza por bajo riesgo:
- código local;
- entorno de prueba dedicado;
- staging;
- quick scan en PR;
- validación read-only en producción controlada;
- pentest formal.
No conectes el Agent a todo producción el primer día.
Checklist de autorización
| Ítem | Confirmar |
|---|---|
| Alcance | dominios, IPs, repos, APIs, cuentas |
| Exclusiones | terceros, pagos, SMS, email, datos de producción |
| Intensidad | concurrencia, rate, ventana, profundidad |
| Datos | qué se puede ver o guardar |
| Herramientas | red, comandos, modelos externos |
| Secretos | API keys, cuentas de prueba, cookies |
| Logs | requests, salidas, reportes, aprobaciones |
| Parada urgente | contacto y rollback |
| Divulgación | destinatario, tiempos, reglas públicas |
| Revisión humana | quién confirma hallazgos de IA |
Instrucciones de cumplimiento para el Agent
|
|
El prompt no basta. También limita red, cuentas y entorno.
CI/CD también necesita límites
- escanear solo cambios o entornos de prueba;
- no exponer secrets a PRs no confiables;
- no enviar logs sensibles a destinos no controlados;
- revisión humana para hallazgos de alto riesgo;
- definir si falla el merge o solo crea reporte.
Los reportes de vulnerabilidad son información sensible.
Consejos para investigadores individuales
- usa proyectos propios, labs, CTFs y entornos de práctica;
- lee el scope de bug bounty;
- usa solo métodos permitidos;
- evita validación destructiva;
- no descargues datos reales;
- reporta por el canal oficial;
- guarda evidencia mínima;
- no uses “lo hizo la IA” como defensa.
Si no hay permiso ni política de divulgación, evita pruebas activas automatizadas.
Legal no siempre significa recomendable
Aunque un contrato lo permita, considera:
- horas pico de producción;
- datos reales de clientes;
- ruido de alertas;
- falta de rollback;
- modelos externos procesando código o requests sensibles.
Cumplimiento no es solo “¿es ilegal?”, sino si la actividad se puede explicar, controlar y auditar.
Referencias
- U.S. Department of Justice: Computer Fraud and Abuse Act charging policy
- CISA: BOD 20-01 Develop and Publish a Vulnerability Disclosure Policy
- NIST: AI Risk Management Framework
Resumen
La legalidad del pentesting automatizado con AI Agent no depende de la etiqueta “IA”. Depende de autorización, scope, control de impacto, datos, divulgación y auditoría. Con límites claros puede ayudar a defensa; sin límites, se vuelve una fuente de riesgo.