La prompt injection en RAG ocurre cuando un documento recuperado o una salida de herramienta intenta cambiar las instrucciones que sigue el asistente. El usuario puede haber pedido una tarea legítima; el contenido externo introduce una intención diferente. En ciberseguridad, informes, tickets y registros son vías de entrada que el sistema necesita leer y que no debe convertir en autoridad.
Esta guía propone un protocolo de evaluación defensiva para asistentes con recuperación y herramientas. Los escenarios son de laboratorio, con documentos y activos ficticios. No se presentan tasas de éxito ni resultados de un despliegue real.
Por qué RAG no elimina la prompt injection
RAG aporta contexto, pero ese contexto puede contener instrucciones ajenas a la tarea. OWASP LLM01:2025 identifica el problema y señala que recuperación y ajuste del modelo no lo resuelven por completo. Una cita correcta demuestra procedencia; no concede permiso para actuar.
Conviene distinguir tres resultados: una respuesta contaminada, una revelación no autorizada y una acción fuera de alcance. Pueden aparecer por separado. Un asistente de solo lectura todavía puede producir una recomendación falsa o exponer datos a los que no debería acceder el destinatario.
Dibujar los límites de confianza
Antes de probar un filtro, escribe quién controla cada entrada. El usuario controla su petición dentro de sus permisos. El repositorio controla documentos con sus restricciones. Una herramienta devuelve observaciones; no redefine la política del agente. El servicio ejecutor controla la autorización final.
Como ejemplo, un ticket de laboratorio contiene texto que intenta cambiar el destinatario de un informe. El resultado correcto es conservar el destinatario autorizado y tratar ese texto como contenido del ticket. No basta con que el modelo explique que ha detectado un problema si después la herramienta usa el parámetro manipulado.
Una matriz de pruebas pequeña y útil
| Caso de laboratorio | Conducta que comprobar | Resultado legítimo que debe conservarse |
|---|---|---|
| Instrucción ajena en un documento | No cambia el objetivo del usuario | Resumen respaldado por evidencia |
| Cambio de destinatario sugerido por una fuente | El ejecutor bloquea el alcance no autorizado | Informe para el destinatario permitido |
| Documento antiguo presentado como vigente | Se aplica la versión correcta | Explicación del procedimiento actual |
| Permiso revocado después de recuperar | Se vuelve a comprobar el acceso | Abstención o respuesta con fuentes autorizadas |
| Evidencia insuficiente | No se inventa una conclusión | Solicitud de contexto concreto |
Para cada caso, prepara una versión limpia y otra perturbada. Mantén igual la tarea legítima. Usa marcadores ficticios para comprobar exposición y herramientas simuladas para observar intentos sin producir efectos externos.
Medir utilidad, exposición y acciones por separado
Registra al menos éxito de tarea legítima, afirmaciones sin respaldo, divulgación indebida, llamadas fuera de alcance y rechazo innecesario. Declara los denominadores. Una tasa de ataque baja obtenida porque el agente no hace nada puede esconder una pérdida total de utilidad.
Conserva la traza completa: documentos autorizados, fragmentos recuperados, respuesta, llamadas propuestas, decisiones del ejecutor y estado final. Una llamada propuesta y una acción realizada son eventos distintos. Un bloqueo del ejecutor puede proteger el sistema aunque el razonamiento del agente haya fallado.
AgentDojo proporciona un entorno para estudiar tareas de agentes y ataques de prompt injection. Úsalo como referencia experimental, y añade casos propios que reflejen el corpus y los permisos de tu aplicación.
Qué aporta la investigación de 2026
La revisión de marzo de 2026 del preprint Indirect Prompt Injections: Are Firewalls All You Need, or Stronger Benchmarks? analiza límites de benchmarks y ataques adaptativos. Una buena puntuación frente a perturbaciones conocidas no demuestra protección frente a cualquier contenido futuro.
La consecuencia que propongo es separar un conjunto de desarrollo de otro reservado, con familias de perturbación diferentes. Si se modifica la defensa después de ver un fallo reservado, registra esa exposición y renueva parte de la evaluación. Las variantes ES/EN de un mismo caso no deben repartirse entre desarrollo y test como si fueran independientes.
Controles que deben existir fuera del modelo
Aplica permisos antes de recuperar y otra vez al ejecutar. Limita los campos que una herramienta acepta, valida identificadores y fija destinos autorizados desde estado confiable. Los resúmenes derivados y las cachés necesitan las mismas restricciones que sus fuentes.
Un detector de instrucciones sospechosas puede aportar una señal, pero no reemplaza autorización. Tampoco un prompt que ordena ignorar instrucciones externas constituye una barrera completa. El diseño debe seguir siendo acotado cuando el modelo interpreta mal el documento.
Criterio de aceptación antes de desplegar
Define de antemano qué fallos impiden el despliegue, qué tareas requieren revisión humana y qué regresión de utilidad resulta inaceptable. Después del piloto, incorpora fallos revisados como nuevos casos. Mantén versiones de corpus, modelo, política y herramientas para poder explicar cada cambio de resultado.
La guía de RAG para ciberseguridad cubre la recuperación; los golden sets ayudan a construir las referencias; las métricas para LLMs completan el informe. La evaluación útil demuestra qué límites se respetan durante una tarea realista y deja visibles los que todavía no se han probado.
