Red teaming de LLM frente a prueba de penetración de apps web: qué cubre cada uno, costo y cuándo necesita ambos

Estos son los rangos orientativos publicados en nuestra página de servicios de ciberseguridad. El precio final depende del alcance, y todo proyecto comienza acordando qué queda dentro y fuera de los límites.

Qué cubre una prueba de penetración de una aplicación web

Una prueba de penetración de una aplicación web es un intento autorizado de irrumpir en su aplicación en funcionamiento, mediante enfoques de caja negra, caja gris o caja blanca, según el nivel de acceso que se conceda a los evaluadores. La cobertura habitual se corresponde con el OWASP Top 10: control de acceso defectuoso, inyección, fallos de autenticación, configuración insegura, componentes vulnerables y problemas similares.

Responde a preguntas como estas: ¿puede un cliente leer los datos de otro?, ¿puede un usuario normal acceder a funciones de administración?, ¿puede una entrada salirse del uso previsto?, ¿están expuestos secretos o interfaces de depuración? El resultado es un informe escrito con hallazgos comprobados, su gravedad y recomendaciones de corrección, y debe incluir una nueva prueba después de que usted corrija lo detectado.

Si se encuentra en una fase más temprana y quiere saber qué revisión le conviene, consulte nuestra comparación de auditorías técnicas, pruebas de penetración y revisiones de código.

Qué cubre el red teaming de LLM

El red teaming de LLM considera como objetivo el modelo y todo lo que está conectado a él. Los principales tipos de ataque son:

• Inyección directa de prompts: un usuario escribe instrucciones que intentan anular su prompt de sistema («ignora tus instrucciones anteriores»).
• Inyección indirecta de prompts: instrucciones hostiles ocultas en una página web, un documento, un correo electrónico o el resultado de una herramienta que el modelo lee en nombre de un usuario.
• Jailbreaks: lograr que el modelo supere sus límites de seguridad y de políticas.
• Extracción de datos: hacer que el modelo revele su prompt, datos de otros usuarios o contenido con el que fue entrenado o que recupera.
• Denegación de servicio del modelo: prompts diseñados para consumir cómputo o costes excesivos.
• Envenenamiento de la recuperación: colocar contenido en los documentos en los que busca su sistema de recuperación (RAG) para que el modelo lo repita o actúe en consecuencia.
• Uso indebido de herramientas por parte de agentes: persuadir a un agente para que llame a una herramienta potente, como enviar correos, emitir reembolsos o eliminar registros, con entradas controladas por el atacante.
• Escalada de alcance a través de servidores MCP y plugins: usar una herramienta conectada para acceder a datos o acciones a los que el usuario no debería tener acceso.
• Riesgos de la cadena de suministro: prompts, modelos o herramientas de terceros maliciosos.

El informe muestra cuáles de estos ataques funcionan contra su producto, cómo los encadenaría un atacante y qué hay que cambiar. Muchos productos de IA en producción exponen varios de ellos a la vez, a menudo porque cada funcionalidad era razonable por sí sola.

Dónde se solapan ambas

El solapamiento es mayor de lo que parece. Cuando un agente de IA puede llamar a herramientas, una inyección de prompts se convierte en un problema de control de acceso: el modelo es un nuevo usuario, fácil de persuadir, dentro de su sistema. Si puede leer los registros de un cliente o activar un pago, todo lo que una prueba de penetración web comprueba sobre permisos se aplica ahora también a lo que el modelo tiene permitido hacer.

También funciona al revés. La salida del modelo es texto no confiable. Si su interfaz la muestra sin cuidado, una vulnerabilidad web clásica como el cross-site scripting puede llegar a través del modelo. Un buen red team incluirá comprobaciones convencionales a lo largo de estas rutas.

¿Necesita una o ambas?

• Una aplicación web normal sin funciones de IA: una prueba de penetración web, una vez corregidos los aspectos básicos.
• Un chatbot que solo responde con contenido público: menor riesgo, pero pruebe la fuga de prompts, el abuso y los límites de coste, y revise también la capa web.
• Un asistente con acceso a datos privados o de clientes: ambas. La exposición de datos a través del modelo es el fallo más caro de explicar.
• Un agente que realiza acciones mediante herramientas o servidores MCP: ambas, con los permisos de las herramientas como eje central.
• Un producto de recuperación (RAG) sobre muchas fuentes: ambas, además de prestar atención a quién puede añadir documentos al índice.

Cuando el presupuesto es ajustado, empiece enumerando tres cosas: qué datos puede ver el modelo, qué acciones puede realizar y quién puede hablar con él. Cuanto más haya de cada una, más urgente será la prueba.

Reduzca el riesgo antes de las pruebas

Hoy en día la inyección de prompts no se puede eliminar por completo, así que un buen diseño asume que el modelo será engañado en ocasiones y limita el daño:

1. Otorgue a las herramientas el mínimo privilegio posible y limítelas por usuario, nunca con una única clave compartida y potente.
2. Exija confirmación humana para las acciones destructivas o de alto valor.
3. Trate la salida del modelo como no confiable y valídela o codifíquela antes de que llegue a una interfaz, una base de datos u otro sistema.
4. Mantenga separados las instrucciones y el contenido no confiable siempre que su arquitectura lo permita, y evite incluir secretos en los prompts.
5. Registre las llamadas a herramientas y establezca límites de frecuencia y de gasto para que el abuso sea visible y esté acotado.

Incorporar estas medidas desde el principio es mucho más barato que añadirlas después de un hallazgo. Es el enfoque que seguimos al crear agentes de IA y servidores MCP.

Qué esperar de un proyecto

Un proveedor serio acordará de antemano el alcance y las reglas del proyecto, probará solo lo que usted autorice y entregará un informe escrito pensado tanto para ingenieros como para quienes toman decisiones. Tras las correcciones debe realizarse una nueva prueba para que pueda demostrar que funcionan. Desconfíe de quien le prometa que su producto de IA será «totalmente seguro»; el resultado honesto es una imagen más clara, menos vías explotables y evidencias que puede compartir con sus clientes.

Para las aplicaciones creadas con IA que se acercan a su lanzamiento, el orden que solemos sugerir es una auditoría técnica, después las correcciones y, por último, las pruebas formales. Nuestra lista de verificación de preparación para producción es un buen punto de partida.