Prevención de la inyección de prompts: las 4 capas de defensa de la IA

TL;DR

La prevención de la inyección de prompts es defensa en profundidad, no un parche. La causa raíz es arquitectónica: un modelo de lenguaje no puede separar las instrucciones del desarrollador de los datos del usuario cuando ambos viven en el mismo flujo de tokens. La estrategia que funciona apila cuatro capas, guardarraíles de entrada, endurecimiento del prompt del sistema, entrenamiento de alineación y guardarraíles de salida, y luego limita el radio de impacto con mínimo privilegio, registro y aprobación humana para las acciones de riesgo. Cada capa tiene un bypass documentado, así que ninguna se puede saltar.

Esta es la Parte 3 de una serie de tres entregas, y se sostiene por sí sola. No necesitas haber leído la Parte 1: Los cimientos ni la Parte 2: El manual de ataque para seguirla, aunque ambas afilarán todo lo de aquí. Si construyes, este es tu plano. Si cazas bug bounty, entender las defensas hace tus ataques más afilados.

Toda empresa de IA afirma que su chatbot es seguro. Cada una de ellas se equivoca, al menos un poco. He visto a empresas atornillar un filtro de palabras clave a su IA, anunciar que son "a prueba de inyección de prompts" y perder ese filtro en menos de veinte minutos de pruebas. Este artículo es la mitad del defensor de la historia, y es honesto sobre qué funciona, qué no y por qué.

Por qué la prevención es defensa en profundidad, no un parche

Para entender por qué la inyección de prompts no se puede parchear sin más, tienes que recordar qué es un gran modelo de lenguaje. Quita el marketing y un LLM es un motor de predicción estadística, el mismo tipo de adivino del siguiente token que el autocompletado de tu teléfono, escalado para predecir párrafos a partir de patrones aprendidos en casi todo internet.

En el software tradicional, el código y los datos se mantienen separados. SQL tiene un lenguaje de consulta y parámetros de entrada aparte, y los datos no pueden ejecutarse como código cuando el sistema está bien construido. Los grandes modelos de lenguaje no tienen ese muro. El prompt del sistema del desarrollador, el mensaje del usuario y cualquier contenido externo que el modelo lea se aplanan todos en una única secuencia continua de tokens. Si una pieza de entrada del usuario parece una instrucción, el modelo puede seguirla. No porque lo hayan engañado. Porque no tiene ningún mecanismo para notar la diferencia.

Ese único hecho es la razón de que la inyección de prompts esté en el número uno del OWASP Top 10 para Aplicaciones de LLM, de que las tasas de éxito reportadas vayan del 50 al 84 por ciento y de que los modelos de frontera sigan siendo vulnerables tras sus mejores defensas. No es un bug a la espera de un parche. Es la arquitectura. Así que los defensores dejan de intentar eliminar el fallo y empiezan a construir capas a su alrededor.

Las 4 capas de defensa de la IA

La mayoría de las aplicaciones de IA tienen cuatro capas defensivas, cada una protegiendo contra tipos de ataque distintos. Piensa en la seguridad de un aeropuerto. La Capa 1 es el detector de metales de la entrada, el guardarraíl de entrada. La Capa 2 es la tarjeta de embarque que define a dónde tienes permitido ir, el prompt del sistema. La Capa 3 es el entrenamiento del piloto que evita maniobras peligrosas, la alineación horneada en el modelo. La Capa 4 es el agente de seguridad aérea que vigila los problemas una vez que ya estás en el avión, el guardarraíl de salida.

Capa 1: guardarraíles de entrada

Los guardarraíles de entrada inspeccionan el prompt del usuario antes de que llegue siquiera al modelo. La validación basada en caracteres usa una regex para incluir en lista blanca los caracteres permitidos, lo que funciona para una calculadora pero es inútil para un chatbot de propósito general. La validación basada en contenido filtra por significado en lugar de por caracteres, a menudo usando un modelo clasificador más pequeño para juzgar si la intención detrás de un mensaje es maliciosa. Eso captura mucho más, pero cuesta latencia y dinero en cada petición.

El compromiso de fondo es inevitable: los filtros estrictos de palabras clave son triviales de saltar con codificación o paráfrasis, mientras que los filtros semánticos son más difíciles de engañar pero más lentos y propensos a los falsos positivos. Por esto tantos sistemas en producción salen con filtros débiles, y por esto un atacante que pruebe Base64, inserción de Unicode o un idioma distinto suele encontrar un hueco. Un guardarraíl de entrada es un resalto reductor de velocidad, no un muro.

Capa 2: endurecimiento del prompt del sistema

El prompt del sistema es la palanca más directa del desarrollador, y tres técnicas lo endurecen frente a los datos no confiables que fluyen por el mismo flujo. La delimitación marca la frontera entre las instrucciones de confianza y la entrada no confiable con símbolos especiales, indicando al modelo que nunca obedezca instrucciones encontradas entre ellos. El marcado de datos va más allá, intercalando un carácter especial entre cada palabra de la entrada no confiable para que sea sintácticamente distinta de las instrucciones. La codificación toma la entrada no confiable y la codifica, normalmente en Base64, instruyendo al modelo a decodificar y resumir pero nunca a tratar el texto decodificado como nuevas instrucciones.

Ninguna de estas es infalible. Un payload suficientemente creativo todavía puede funcionar dentro de los delimitadores, y a un modelo se le puede convencer de ignorar el marcado de datos. Pero cada una eleva el coste de un ataque con éxito, y elevar el coste es el objetivo entero. La investigación de Microsoft sobre estas técnicas de spotlighting es el artículo más claro sobre hasta dónde puede y no puede llevarte el endurecimiento del prompt del sistema.

Capa 3: entrenamiento de alineación y afinado

Esta es la defensa horneada en los pesos del modelo, no en el código de la aplicación que lo rodea. El afinado entrena un modelo de propósito general aún más con datos específicos de un dominio, de modo que un modelo de soporte afinado solo con tickets de soporte resiste de forma natural ser reutilizado, sencillamente porque su distribución de entrenamiento no cubre el mal uso. Cuanto más estrecho el afinado, menor la superficie.

El entrenamiento con prompts adversariales es una de las mitigaciones más efectivas disponibles hoy. El modelo se entrena con payloads conocidos de inyección de prompts y jailbreak como ejemplos negativos, igual que una vacuna entrena un sistema inmune con un patógeno debilitado. La limitación es obvia una vez dicha: el entrenamiento adversarial solo protege contra patrones que el modelo ya ha visto, así que los payloads novedosos se cuelan. Por eso el equipo rojo regular no es opcional, es la única forma de mantener al día las defensas del modelo. La ingeniería de prompts como defensa, simplemente decirle al modelo "nunca reveles secretos", es la mitigación más común y también la más débil, trivialmente saltada por el juego de rol o la codificación. Pertenece al stack, nunca como única capa.

Capa 4: guardarraíles de salida

Los guardarraíles de salida escanean la respuesta del modelo antes de que llegue al usuario. Si la respuesta contiene un prompt del sistema, una clave de API, datos personales o contenido dañino, se bloquea. El bypass es elegante en su simplicidad: pide al modelo que codifique su propia salida, y un guardarraíl que busca secretos en texto plano ve una cadena de Base64 y la deja pasar, mientras el atacante decodifica el resultado por su lado.

Los guardarraíles más sofisticados usan clasificación basada en IA, el patrón del "LLM como juez", donde un segundo modelo evalúa si la entrada o la salida del modelo principal es maliciosa. Esto añade protección real, pero duplica el coste computacional e introduce una nueva superficie de ataque. Si el modelo juez es él mismo vulnerable a la inyección de prompts, un atacante puede convencerlo de aprobar contenido malicioso. La defensa contra los ataques de IA es otra IA que también puede ser atacada. Ese es el estado actual del campo, y merece la pena detenerse en él un momento.

Una lista de comprobación de defensa para quienes construyen

Si estás construyendo cualquier cosa con un LLM en el bucle, aquí va el stack mínimo, escrito como prosa porque cada elemento depende de los demás. Empieza con un filtrado de entrada que combine un clasificador semántico con una lista de bloqueo de palabras clave, sabiendo que la codificación todavía puede saltárselo. Añade endurecimiento del prompt del sistema mediante delimitación o marcado de datos, sabiendo que el marco creativo todavía puede colarse. Aplica el mínimo privilegio para que el modelo solo pueda tocar las herramientas y los datos que necesita estrictamente, lo que no detiene un ataque pero limita el radio de impacto cuando uno tiene éxito, el mismo principio detrás de zero trust.

Luego añade filtrado de salida con un escáner basado en IA más detección de datos personales, sabiendo que la salida codificada puede colarse. Aplica limitación de tasa por usuario y por ventana, sabiendo que los ataques lentos y distribuidos la rodean. Registra cada prompt y cada respuesta, porque el registro es la diferencia entre atrapar un ataque en minutos frente a meses. Exige un humano en el bucle para las acciones de alto riesgo como los reembolsos, sabiendo que un atacante también puede intentar hacer ingeniería social al revisor. Y haz equipo rojo de forma recurrente, porque surgen técnicas nuevas constantemente. Ningún elemento por sí solo basta. Impleméntalos todos, y presupuesta el hecho de que ni siquiera todos juntos serán perfectos.

La superficie de ataque más allá de la caja de chat

La mayoría de la gente imagina la inyección de prompts como algo que pasa dentro de una ventana de chat. La superficie de ataque real es mucho más grande, y la mayor parte no tiene nada que ver con una caja de chat. Yo lo pienso como siete capas, y la caja de chat es una pequeña pieza de una de ellas.

La capa de interfaz son los entornos de ejecución de LLM locales como Ollama, Llama.cpp y LM Studio, a menudo expuestos sobre HTTP sin autenticación y localizables mediante simples dorks de búsqueda. La capa de agente y orquestación son los motores de flujos de trabajo y las interfaces de chat como n8n, Flowise, Open WebUI y LibreChat, que pueden filtrar el historial de chat o ser engañados para hacer falsificación de peticiones del lado del servidor. La capa de datos y memoria son los almacenes vectoriales como Chroma, Weaviate y Qdrant, donde una colección abierta puede ser envenenada para influir en lo que una IA recupera y en lo que confía. La capa de ingeniería de ML son los paneles como Ray, MLflow y ClearML, desplegados con frecuencia sin autenticación. La capa de pasarela y telemetría son las pasarelas de LLM como LiteLLM y Langfuse que se sitúan delante de todo el tráfico de modelos. La capa de artefactos y plugins son los hubs de modelos y los servidores MCP, donde un solo plugin comprometido puede envenenar cada agente que se conecte a él. Y la capa de identidad son las claves de API expuestas de los grandes proveedores, cada una con un patrón distinto y fácil de buscar. Siete capas, y la caja de chat es solo la punta visible.

OWASP Top 10: el marco que importa

Tres listas OWASP Top 10 separadas cubren ahora la seguridad de la IA, y entender las tres te da un modelo de amenazas completo. El LLM Top 10 es el original: la inyección de prompts en el número uno, seguida de la divulgación de información sensible, los ataques a la cadena de suministro, el envenenamiento de datos y modelos, el manejo inadecuado de la salida, el exceso de agencia, la fuga del prompt del sistema, las debilidades de vectores y embeddings, la desinformación y el consumo sin límites.

El MCP Top 10 cubre el ecosistema del Model Context Protocol: la mala gestión de tokens, la escalada de privilegios por expansión de alcance, el envenenamiento de herramientas, los ataques a la cadena de suministro, la inyección de comandos, la inyección de prompts contextual, la autenticación insuficiente, la falta de registro de auditoría, los servidores MCP en la sombra y el sobrecompartir contexto. El Agéntico Top 10 cubre los agentes autónomos: el secuestro de objetivos, el mal uso de herramientas, el abuso de identidad y privilegios, el compromiso de la cadena de suministro, la ejecución inesperada de código, el envenenamiento de memoria y contexto, la comunicación insegura entre agentes, los fallos en cascada, la explotación de la confianza humana y los agentes rebeldes. También hay un ML Top 10 dedicado por debajo para los riesgos clásicos del aprendizaje automático como el envenenamiento de datos, la inversión de modelos, la inferencia de pertenencia y el robo de modelos. Si eres quien prueba, mapea cada hallazgo a una de estas categorías. Si construyes, trata las cuatro listas como tu modelo de amenazas, no solo la primera.

La defensa más fuerte no es un filtro ingenioso. Es una decisión arquitectónica: nunca dar a un solo sistema datos privados, contenido no confiable y un canal externo al mismo tiempo.

IA agéntica: la próxima frontera

Todo lo de arriba aplica a un chatbot simple que responde preguntas. La industria se mueve rápido hacia la IA agéntica, y lo que está en juego sube en un orden de magnitud. Los sistemas agénticos no son solo chatbots. Navegan por la web, envían correos, ejecutan código, modifican archivos, hacen llamadas a la API y hablan con otros agentes. Combina ese alcance con una inyección de prompts y el impacto pasa de "el modelo dijo algo vergonzoso" a "el modelo borró datos de producción" o "el modelo envió por correo secretos de la empresa a una dirección externa".

Aquí es donde la trifecta letal se vuelve esencial para los defensores, no solo para los atacantes. Cualquier sistema agéntico que tenga a la vez acceso a datos privados, esté expuesto a contenido no confiable y pueda comunicarse externamente es trivialmente explotable. La solución no es un filtro ingenioso, es eliminar una pata del triángulo.

Los ataques indirectos de varios saltos, donde un payload pasa por varios agentes antes de dispararse, están subiendo rápido, y los gusanos de IA que se autopropagan por sistemas conectados ya se han demostrado en investigación controlada. El ejemplo público más claro de riesgo agéntico hasta ahora es la operación GTG-1002, que desglosé en cómo usan la IA los hackers: los atacantes conectaron un agente a una máquina Kali Linux, expusieron herramientas ofensivas a través de MCP y lo dejaron ejecutar reconocimiento, explotación y movimiento lateral en gran parte por su cuenta. El peligro escaló con la autonomía, no con la potencia bruta del modelo. Para los cazadores de bug bounty, aquí es donde están los pagos de verdad. Una inyección de prompts que filtra un prompt del sistema es informativa. Una que hace que un agente emita un reembolso no autorizado o borre una base de datos es crítica. La misma habilidad de fondo, lo que está en juego drásticamente más alto.

Una lista de comprobación de pruebas para cazadores

Si estás probando una aplicación de IA en busca de inyección de prompts, recorre este orden y documéntalo todo, recordando que el mismo payload puede no funcionar dos veces, así que reintenta cada técnica tres veces y ajusta la redacción. Empieza con el reconocimiento: identifica el modelo y su arquitectura, para qué está afinado, qué herramientas puede llamar y cada canal de entrada, incluidos texto, archivos, imágenes y URL. Pasa a la inyección directa: extrae el prompt del sistema con técnicas directas e indirectas, prueba bypasses por codificación con Base64, ROT13, hex y l33t speak, prueba el cambio de idioma, prueba el juego de rol y el secuestro de personas, y prueba la escalada multiturno a lo largo de cinco o más turnos.

Luego prueba la inyección indirecta mediante texto oculto en PDF, comentarios HTML y texto blanco sobre blanco, y prueba bypasses de codificación de salida pidiendo al modelo que codifique sus respuestas. Por último, escala: prueba el abuso de herramientas y acciones, incluidas las acciones rebeldes y la falsificación de peticiones del lado del servidor, prueba la inyección de markdown mediante etiquetas de imagen para la exfiltración de datos, y encadena tres o más técnicas en un solo payload para máximo impacto. El detalle ofensivo completo de cada una de estas vive en la Parte 2: El manual de ataque. Documéntalo todo, captura todo y reporta con pasos de reproducción claros e impacto demostrado.

Aquí va la verdad que nadie te cuenta

Estamos corriendo para desplegar agentes autónomos que toman acciones en el mundo real sobre unos cimientos que todo el mundo en el campo sabe que están rotos. El fallo arquitectónico que hace posible la inyección de prompts no se ha resuelto, y ni siquiera se ha resuelto parcialmente. Toda defensa de este artículo es una tirita sobre esa herida, y la superficie de ataque crece más rápido de lo que se pueden aplicar las tiritas.

Eso no significa que la defensa sea inútil. La defensa en profundidad funciona de verdad: hace los ataques más lentos, más difíciles y mucho más detectables, y contra la mayoría de los atacantes eso basta para ganar. Este campo no se está apagando, se está expandiendo. El número de aplicaciones integradas con IA crece de forma exponencial, y el número de personas que saben probarlas o defenderlas no sigue el ritmo. Ese hueco es la oportunidad, sin importar a qué lado de la mesa te sientes.

Conclusión

La inyección de prompts es la vulnerabilidad que define la era de la IA, de la misma forma en que la inyección SQL definió la era de las aplicaciones web. A diferencia de la inyección SQL, no hay equivalente a la sentencia preparada, porque la causa raíz es la ausencia de una frontera entre las instrucciones y los datos dentro del propio modelo. Lo mejor que se puede hacer es apilar capas, monitorizar de forma agresiva, restringir lo que los agentes pueden tocar y mantenerse por delante de unos atacantes que solo necesitan un hueco.

Si eso suena desalentador, dale la vuelta. Todo sistema que hoy se mete a empujones en producción es un futuro objetivo de pruebas, un futuro bug bounty, un futuro artículo de investigación. Los equipos que entienden el andamiaje, y deciden de forma deliberada dónde debe quedarse un humano en el bucle, son los que mantienen el control a medida que los agentes asumen más del trabajo. Esa es exactamente la mentalidad que construimos en el bootcamp de ciberseguridad de Unihackers. Ve a probar. Ve a construir. Ve a hacer los sistemas de IA más seguros que los que encontraste.

Sigue cazando. Mantente curioso.