Blindaje y seguridad en el diseño de Prompts
La seguridad en el diseño de prompts es crítica porque los LLM procesan tanto las instrucciones del sistema como las entradas del usuario como lenguaje natural, lo que los hace vulnerables a que un atacante "anule" las reglas originales.
Los LLM son vulnerables a ataques de inyección de prompts porque no distinguen de forma nativa entre instrucciones del sistema y datos del usuario: ambos llegan como texto plano. La inyección de prompts está rankeada por OWASP (2026) en el top 1 de vulnerabilidades de seguridad en LLM.
🎧 Podcast: Inyección de prompts - OWASP 2026
Inyección de prompts (OWASP LLM01:2026)
Una inyección de prompts (Prompt Injection) es una vulnerabilidad de seguridad que ocurre cuando la entrada de datos procesada por un LLM (ya sea un mensaje escrito directamente por un usuario, texto extraído de la web, respuestas de herramientas externas, imágenes, archivos de audio o datos almacenados en memoria) altera el comportamiento del modelo de formas no intencionadas ni previstas por el desarrollador.
Esta vulnerabilidad es intrínseca al funcionamiento de los LLM: los modelos de lenguaje no realizan una distinción arquitectónica entre "instrucciones" y "datos".
La arquitectura agrupa el prompt de sistema, los mensajes del usuario, los documentos recuperados y las salidas de las herramientas en un único flujo de tokens, sin un límite explícito de confianza (trust boundary) que obligue al modelo a ignorar las órdenes contenidas dentro de los datos.
El objetivo es tomar el control de la salida del modelo utilizando consignas ingeniosas que cambien su comportamiento.
Tipos principales de Inyección de Prompts
Inyección Directa (Direct Prompt Injection / 🔓 Jailbreaking)
Ocurre cuando un usuario (o atacante) escribe deliberadamente comandos maliciosos en la interfaz del chat diseñados para anular las restricciones del prompt de sistema, saltarse las barreras de seguridad (jailbreak) o forzar al modelo a realizar acciones fuera de su alcance permitido.
Inyección Indirecta (Indirect Prompt Injection)
Ocurre cuando el LLM procesa información enviada desde una fuente externa (como una página web resumida, un correo entrante, un documento PDF, un pasaje recuperado por un sistema RAG o la respuesta de un servidor MCP) que contiene instrucciones maliciosas ocultas.
El usuario no ve ni introduce esas instrucciones, pero la IA las ejecuta al procesar el contenido, operando con las credenciales y privilegios asignados a la aplicación
Consecuencias e impactos principales
Una inyección de prompts exitosa puede llevar a diversos fallos de seguridad:
- 🚫 Invocación no autorizada de herramientas:
- Ejecución arbitraria de comandos en el sistema de archivos.
- Modificación no autorizada de bases de datos.
- Envío de correos sin consentimiento.
- 🔓 Fuga y exfiltración de información:
- Revelación del prompt de sistema.
- Extracción de documentos privados.
- Envío oculto de datos hacia servidores externos mediante imágenes Markdown o caracteres Unicode.
- 🕵️ Compromiso persistente:
- Alteración duradera de la memoria del agente.
- Envenenamiento del corpus RAG para afectar sesiones futuras de otros usuarios.
- ⚖️ Manipulación de salidas:
- Generación de contenido sesgado o malicioso en el que confían sistemas posteriores.
Capas de defensa
No existe una solución única o filtro perfecto contra la inyección de prompts. Por ello, la defensa debe diseñarse a nivel de arquitectura y en profundidad (defense-in-depth) para limitar lo que el modelo puede hacer en caso de ser manipulado
El estándar OWASP Top 10 para Aplicaciones LLM (2026) establece las siguientes estrategias de mitigación clave:
- 🛡️ Fortalecimiento del Prompt
- 🧩 Mitigaciones arquitecturales
- 🧹 Higiene y monitoreo
- 🔧 Cadena de suministro y herramientas
Técnicas enfocadas en el diseño de las instrucciones y en la estructuración de la ventana de contexto para ayudar al modelo a diferenciar órdenes de datos y hacerlo más resistente a manipulaciones:
- Instrucciones de prohibición y repetición: incluir reglas explícitas (permitido/denegado) dentro del prompt de sistema para acotar la conducta del LLM y repetir estas instrucciones clave para dificultar que sean ignoradas.
- Separación de canales y etiquetado de procedencia: pasar el contenido externo a través de un canal estructurado y separado, marcando el origen de los datos para que el modelo identifique qué es una instrucción y qué es contenido de consulta.
- Delimitadores y etiquetas XML: utilizar caracteres únicos (como
###o""") o etiquetas como<instrucciones>para separar claramente las órdenes del sistema de los datos del usuario. - Autorrecordatorios: añadir frases que insten al modelo a comportarse de manera responsable y a mantenerse en su rol asignado.
Diseño de barreras y controles deterministas alrededor del LLM para contener el impacto si el límite de instrucciones es vulnerado:
- Gestión de credenciales fuera del LLM y mínimos privilegios: mantener claves y capacidades de cambio de estado en el código de la aplicación y canalizar acciones privilegiadas a través de un motor de políticas determinista.
- Validación de esquemas de salida: validar estructuralmente la respuesta del modelo (ej. esquemas JSON) mediante código de aplicación tradicional antes de que sistemas posteriores la ejecuten.
- Filtrado en fronteras multimodales: aplicar clasificadores específicos, OCR en imágenes y transcripción en audio para procesar y filtrar el texto extraído antes de enviarlo al modelo.
- Limpieza de caracteres invisibles: eliminar caracteres Unicode de ancho cero, selectores de variación y bloques de etiquetas en los puntos de entrada y renderizado, ya que se utilizan para ocultar o "contrabandear" instrucciones (ASCII smuggling).
- Aprobación humana explícita (Human-in-the-Loop): requerir la confirmación previa de un usuario antes de realizar cualquier acción privilegiada, irreversible o visible hacia el exterior, mostrando la acción exacta en pantalla.
- Presupuesto de capacidades (Regla de los Dos): tratar como de alto riesgo y restringir el control de cualquier agente que combine simultáneamente acceso a datos no confiables, datos sensibles y capacidad de cambiar el estado o comunicarse al exterior.
- Uso de clasificadores: implementar un segundo LLM (un "clasificador") que analice la entrada del usuario en busca de intentos de inyección antes de que esta llegue al modelo principal.
- Parametrización y consultas estructuradas: intentar separar comandos de datos mediante formatos especiales que el modelo ha sido entrenado para distinguir, reduciendo la ambigüedad del lenguaje natural.
- Principio de privilegio mínimo: limitar los permisos de las APIs y complementos a los que tiene acceso el modelo, asegurando que solo pueda realizar las acciones estrictamente necesarias.
Controles operativos y de mantenimiento continuo:
- Protección de la memoria persistente del agente: tratar las escrituras en memoria a largo plazo o en el corpus RAG como operaciones privilegiadas, registrando el prompt de origen y clasificando el contenido antes de permitir que persista entre sesiones.
- Evaluación con atacantes adaptativos: realizar pruebas de seguridad y red-teaming continuo asumiendo que el atacante conoce las defensas implementadas, evaluando contra marcos dinámicos (como AgentDojo o JailbreakBench)
- Monitoreo activo: utilizar herramientas de ciberseguridad para detectar comportamientos anómalos en las respuestas del modelo.
Controles enfocados en las extensiones, plugins y conectores de integración:
- Verificación y firmado de servidores MCP y herramientas: firmar, auditar y fijar las versiones de herramientas de terceros y servidores MCP, inspeccionando las descripciones de las herramientas para evitar que contengan instrucciones maliciosas ocultas.
Ninguna de estas técnicas es suficiente por sí sola. Un atacante experimentado puede saltarse un clasificador o reformular un prompt. La seguridad real surge de combinar las tres capas: prompt + arquitectura + monitoreo.
Buenas prácticas
- Empieza por el prompt: un system prompt bien delimitado (
###,<instrucciones>) ya filtra muchos ataques. - Aplica privilegio mínimo: si el LLM no necesita borrar archivos, no le des permiso para hacerlo.
- Pon un humano en el bucle antes de cualquier acción crítica (borrar, enviar, pagar).
- Loggea y monitorea las respuestas: los ataques suelen dejar rastros detectables.