Pruebas adversarias de aplicaciones con LLM, agentes e integraciones MCP: inyección de prompts, fuga de datos, abuso de herramientas y escape de la tarea prevista.
Una aplicación construida sobre un modelo de lenguaje recibe instrucciones de todo lo que lee: el usuario, un documento recuperado, el contenido de una página web, la salida de una herramienta. No puede distinguir de forma fiable una instrucción de un dato. En cuanto el modelo puede llamar a herramientas, enviar mensajes o escribir en una base de datos, una frase oculta en un documento se convierte en una acción en sus sistemas.
Probamos toda la aplicación y no solo el modelo: los prompts, el pipeline de recuperación, las herramientas y sus permisos, los agentes y los protocolos que los conectan. La pregunta es qué puede conseguir un atacante que el sistema haga, lea o revele, y si los controles que rodean al modelo resisten cuando el propio modelo no resiste.
01Alcance
Qué ponemos a prueba
Inyección de prompts directa e indirecta a través de cada entrada que lee el modelo
Revelación de prompts del sistema, secretos y datos de otros usuarios o inquilinos
Generación aumentada por recuperación: envenenamiento, control de acceso al almacén de documentos
Herramientas y llamadas a funciones: permisos excesivos, parámetros inseguros, confused deputy
Agentes: secuestro de objetivos, envenenamiento de la memoria, autonomía insegura, confianza entre agentes
Servidores de Model Context Protocol: autenticación, envenenamiento de herramientas, ejecución de comandos
Gestión de la salida: inyección en navegadores, shells, consultas y sistemas posteriores
Barreras de protección (guardrails) y filtros: elusión mediante codificación, idioma, juego de rol y ataques de varios turnos
Consumo de recursos y abuso de costes
02Enfoque
Cómo se realiza el trabajo
01
Revisión de la arquitectura
Trazamos qué lee el modelo, a qué puede llamar y con los permisos de quién. La mayoría de los hallazgos críticos son visibles en esta fase como un límite de confianza que falta.
02
Pruebas adversarias
Las entradas se elaboran a mano y se generan a escala contra cada canal que llega al modelo. Un ataque que tiene éxito se reduce a la entrada mínima que lo reproduce.
03
Abuso de herramientas y agentes
Usamos instrucciones inyectadas para dirigir herramientas y agentes: leer lo que no debería poder leerse, actuar en nombre de otro usuario, pasar de un sistema al siguiente.
04
Validación de los controles
Los filtros, las barreras de protección y los pasos de aprobación se prueban por separado. El informe indica qué control detuvo qué ataque y cuál no detuvo ninguno.
La aplicación. La seguridad del modelo base es responsabilidad de su proveedor. Lo que usted controla, y lo que explotan los atacantes, es cómo se conecta el modelo a sus datos y a sus herramientas.
La inyección de prompts no se puede corregir del todo. ¿Qué sentido tiene encontrarla?
El sentido es saber qué se deriva de ella. Si la inyección lleva a una respuesta equivocada, es un problema de calidad. Si lleva a un correo electrónico enviado en nombre del usuario, es una vulnerabilidad en los permisos que rodean al modelo, y se puede corregir.
¿Usan nuestros datos para entrenar servicios externos de IA o como prompts para ellos?
No. Los datos de los clientes, los prompts y los hallazgos no se envían a servicios públicos de IA ni se usan para entrenamiento. Las herramientas que se basan en modelos de lenguaje se ejecutan en entornos que controlamos.
¿Cubre esto los requisitos del Reglamento de IA de la UE?
Las pruebas adversarias son una de las medidas a las que se refiere el Reglamento para determinados sistemas y modelos. El informe documenta el método, el alcance y los resultados de una forma que sirve como evidencia. Si el Reglamento se aplica a su sistema, y cómo, es una cuestión jurídica a la que no respondemos.