Pruebas de IA autorizadas: dónde está el límite
Qué significan las pruebas autorizadas para las aplicaciones LLM: alcance por escrito, por qué la investigación sobre inyección de prompts es legítima para los defensores, divulgación responsable y lo que nunca se debe hacer.
La investigación sobre inyección de prompts es de doble uso. El mismo payload que le demuestra al equipo de seguridad de un proveedor una vía de exfiltración de datos se convierte, lanzado contra un sistema que no es tuyo, en un ataque. La técnica no cambia: lo que cambia es la autorización. Esta entrada trata sobre ese límite, porque todo lo demás en este sitio da por sentado que te encuentras en el lado correcto.
Qué significan realmente las "pruebas autorizadas"
Las pruebas autorizadas significan que cuentas con un permiso explícito y documentado de la parte que posee u opera el sistema, que cubre las cosas concretas que pretendes hacer. Para una aplicación LLM esto es más amplio que un pentest web clásico, porque la superficie de ataque incluye:
- El modelo y su prompt de sistema.
- Las herramientas, funciones y agentes conectados que el modelo puede invocar.
- Las fuentes de recuperación (corpus RAG, archivos subidos, recuperación web).
- Los sistemas posteriores a los que el modelo puede llegar (correo, ticketing, bases de datos, ejecución de código).
- Los proveedores de modelos de terceros, cuyos términos de servicio también te obligan.
El permiso para "la aplicación" no es automáticamente permiso para hacer que el agente envíe correos, llame a APIs internas o extraiga datos de una unidad conectada. Déjalo por escrito con claridad.
Consíguelo por escrito, con alcance
Un "claro, adelante" verbal no es una autorización en la que puedas respaldarte. Antes de enviar un solo payload, conviene un acuerdo escrito que establezca:
- Quién autoriza (una entidad que realmente posee el sistema) y quién realiza las pruebas.
- Objetivos: nombres de host exactos, cuentas, tenants, endpoints de modelos y qué herramientas conectadas están dentro del alcance.
- Fuera de alcance, de forma explícita. Los datos de clientes en producción, los SaaS de terceros, la infraestructura del proveedor de modelos y otros tenants son exclusiones habituales.
- Acciones permitidas: ¿puedes activar llamadas a herramientas? ¿Exfiltrar hacia un endpoint de prueba de concepto que controles? ¿Usar datos reales o solo sintéticos?
- Reglas de enfrentamiento: ventana de pruebas, límites de velocidad, un contacto para detener y notificar, y qué hacer si te topas con datos sensibles reales.
Los programas de bug bounty codifican gran parte de esto en su política y en su cláusula de puerto seguro (safe harbor). Si existe un programa, léelo y mantente dentro de él; la política es tu autorización, y tiene límites.
Por qué la investigación sobre inyección de prompts es legítima
Los defensores no pueden defenderse de una clase de ataque que no se les permite estudiar. La inyección de prompts indirecta, las balizas mediante imágenes en markdown y el envenenamiento de RAG son técnicas reales que se observan en el mundo real. Construir detecciones, escribir controles de spotlighting y de salida de datos (egress), y hacer red team a tus propios agentes requieren reproducir los ataques en condiciones controladas. Es una práctica de seguridad estándar: la misma lógica que hace legítimo el desarrollo de exploits para quienes publican el parche.
La naturaleza de doble uso es precisamente la razón por la que la intención y la autorización son lo que pesa. Publicar una técnica bien conocida junto con sus defensas ayuda al campo. Ejecutar esa técnica contra un sistema que nunca te lo pidió, no.
Recordatorio sobre el uso autorizado: cada técnica de este sitio está destinada a sistemas que posees o que tienes un encargo explícito de probar. Reproduce los ataques en un laboratorio o en un entorno dentro del alcance, nunca contra terceros.
Divulgación responsable
Cuando encuentres algo —dentro del alcance o por accidente— trátalo con cuidado:
- Deja de escalar. Demuestra el impacto con lo mínimo necesario; no sigas pivotando una vez probado el hallazgo.
- Minimiza los datos. Usa secretos sintéticos como señuelos (canaries). Si tocas datos reales, captura solo lo que prueba el problema y registra lo que viste.
- Reporta primero en privado. Usa el contacto de seguridad del proveedor, el archivo security.txt o el canal de bug bounty. Aporta pasos de reproducción claros e impacto.
- Da tiempo para corregir. Acuerda un plazo de remediación (divulgación coordinada, a menudo 90 días). Publica solo tras una corrección o un plazo razonable y comunicado.
- Conserva registros. Tu documento de alcance, las marcas de tiempo y la correspondencia son lo que distingue la investigación de la intrusión si alguien pregunta.
Lo que NO se debe hacer
Algunas líneas son nítidas, y cruzarlas convierte la investigación en un delito en la mayoría de las jurisdicciones:
- No pruebes sistemas que no posees o para los que no tienes permiso por escrito, incluido "solo un payload" contra un chatbot de terceros en producción.
- No exfiltres datos de otras personas. Baliza un señuelo que tú mismo plantaste, no los registros de un cliente real ni los documentos de otro tenant.
- No excedas tu alcance para "ver hasta dónde llega". Los sistemas agénticos pueden ejecutar acciones destructivas en el mundo real; asume que las llamadas a herramientas tienen consecuencias.
- No retengas ni compartas datos capturados más allá de lo que exige la divulgación, y elimínalos después.
- No te quedes sentado sobre un hallazgo crítico mientras decides si convertirlo en arma. Divúlgalo.
En conclusión
El contenido técnico de aquí se corresponde directamente con LLM01: Prompt Injection de OWASP. La habilidad es transferible; la autorización no. Conserva el alcance por escrito, mantén los señuelos sintéticos, divulga de forma responsable y permanece dentro del límite: eso es lo que hace que este trabajo sea defendible y valga la pena.