Prompt injection: la nueva vulnerabilidad que amenaza a las aplicaciones con inteligencia artificial

Introduccion

Integrar inteligencia artificial en una aplicacion web no consiste solamente en conectar una API y enviar un texto. Cuando un usuario escribe en un chat, adjunta un documento o envia un correo que el modelo procesa, esa entrada puede influir directamente en la respuesta que genera el sistema. Si la aplicacion no establece controles claros entre lo que el modelo debe obedecer como instruccion y lo que debe tratar simplemente como datos, existe la posibilidad de que un atacante intente alterar su comportamiento. Esto se conoce como prompt injection, y es una de las vulnerabilidades mas relevantes para las aplicaciones que incorporan modelos de lenguaje.

La buena noticia es que herramientas de analisis de codigo estan comenzando a detectar este tipo de patrones. GitHub acaba de anunciar que su plataforma CodeQL ahora incluye una consulta especifica para identificar ciertos flujos de datos controlados por usuarios que pueden alcanzar el prompt de sistema de una aplicacion de IA. Esto es relevante en un contexto donde la ejecucion de modelos de IA en el navegador, como vimos en nuestro articulo sobre LiteRT.js, esta haciendo que mas aplicaciones incorporen modelos de lenguaje.

Que anuncio GitHub?

El 10 de julio de 2026, GitHub publico en su changelog que la version CodeQL 2.26.0 incorpora una nueva consulta para JavaScript y TypeScript llamada js/system-prompt-injection. Esta consulta detecta ciertos flujos de datos controlados por usuarios que pueden llegar al prompt de sistema de una aplicacion de IA.

Segun el comunicado oficial, la actualizacion incluye:

• Soporte para Kotlin 2.4.0.
• Nuevos modelos para APIs de OpenAI, Anthropic y Google GenAI.

La consulta de prompt injection esta disenada para ayudar a los equipos a identificar patrones en el codigo fuente donde datos provenientes de un usuario pueden terminar being incorporados al prompt de sistema sin el tratamiento adecuado. Esto significa que CodeQL no bloquea un ataque en produccion, sino que alerta a los desarrolladores sobre un patron potencialmente peligroso en el codigo antes de que se ejecute.

Es importante ser preciso: CodeQL no detecta todos los casos posibles de prompt injection. El analisis estatico tiene limitaciones inherentes: no puede evaluar configuraciones externas, contenido que llega en tiempo real, ni todos los escenarios de manipulacion indirecta. Sin embargo, representa un avance significativo en la incorporacion de seguridad de IA dentro de los flujos de desarrollo existentes.

Que es CodeQL?

CodeQL es el motor de analisis estatico que alimenta GitHub code scanning. Su enfoque consiste en tratar el codigo fuente como datos consultables: CodeQL crea una base de datos relacional a partir del codigo y permite escribir consultas en un lenguaje especializado (QL) para buscar patrones especificos.

Funciona extrayendo representaciones del codigo, creando una base de datos estructural, ejecutando consultas de patrones de vulnerabilidades, e indicando donde se detectaron. El analisis estatico es valioso para revisar codigo de forma automatizada, pero no reemplaza pruebas en produccion ni evaluacion humana.

Que es un prompt de sistema?

El prompt de sistema (tambien llamado system prompt) es un conjunto de instrucciones que define el comportamiento de un modelo de lenguaje. Establece que debe hacer, que debe evitar, como debe responder y que rol debe asumir. Es la guia interna que orienta todas las respuestas del modelo.

En una aplicacion bien disenada, existe una separacion clara entre dos componentes:

• Las instrucciones del sistema: definen el comportamiento, las reglas y los limites del modelo.
• Los datos del usuario: es la informacion que ingresa para ser procesada.

La seguridad depende de que estas capas no se mezclen incontroladamente. El prompt de sistema no es un mecanismo unico de seguridad; las instrucciones pueden ser influenciadas si no existen controles adicionales.

Que es un prompt injection?

Segun el OWASP Top 10 para LLM Applications (2025), el prompt injection ocurre cuando un atacante manipula la entrada del modelo para alterar su comportamiento o ejecutar acciones no autorizadas. Es la primera vulnerabilidad en la lista OWASP para LLM. A diferencia de SQL injection, que explota bases de datos, el prompt injection explota como el modelo interpreta el lenguaje natural: una entrada no confiable termina siendo interpretada como instruccion.

Prompt injection directo e indirecto

OWASP distingue dos formas principales de prompt injection:

Prompt injection directo

Ocurre cuando el atacante escribe instrucciones maliciosas directamente en el chat o formulario. El modelo puede interpretar esas instrucciones como parte de su tarea.

Prompt injection indirecto

Es mas sutil y peligroso. Ocurre cuando la aplicacion procesa contenido externo con instrucciones ocultas. El atacante no interactua con el modelo directamente, sino que coloca instrucciones en fuentes que el sistema procesara.

Ejemplos de fuentes que pueden contener inyecciones indirectas:

• Documentos adjuntos en correos electronicos.
• Paginas web que el modelo consulta.
• Archivos que la aplicacion carga y procesa.
• Bases de conocimiento o repositorios de informacion.
• Comentarios de usuarios en bases de datos.
• Resultados de busquedas web.
• Datos obtenidos mediante APIs externas.

El riesgo indirecto es especialmente relevante porque el contenido puede parecer texto legitimo mientras oculta instrucciones disenadas para manipular al modelo.

Es lo mismo que hacer jailbreak?

Prompt injection y jailbreaking estan relacionados pero no son exactamente lo mismo. El jailbreak se refiere a tecnicas para evadir las restricciones de seguridad de un modelo, generalmente para que genere contenido que normalmente rechazaria. El prompt injection se refiere mas ampliamente a la manipulacion de instrucciones del modelo, que puede incluir obtener informacion interna, alterar comportamientos o ejecutar acciones a traves de herramientas conectadas.

Ambos conceptos pueden superponerse, pero no son equivalentes. Para fines de seguridad empresarial, lo importante es que ambos representan riesgos que requieren controles.

Por que puede ser peligroso?

El impacto depende de que puede hacer la aplicacion. Si solo genera texto, el riesgo se limita a respuestas inapropiadas. Pero si tiene permisos para ejecutar acciones, el impacto puede ser significativamente mayor.

Algunos posibles efectos incluyen:

• Generacion de respuestas alteradas o manipuladas.
• Omision de reglas del negocio.
• Revelacion involuntaria de informacion interna.
• Uso incorrecto de herramientas o APIs.
• Ejecucion de acciones no autorizadas.
• Exposicion de datos confidenciales.

Es fundamental entender que no todos los ataques llegan a ejecutar acciones externas. Algunos se limitan a alterar respuestas de texto. El nivel de riesgo aumenta cuando la aplicacion conecta el modelo con herramientas, bases de datos, correos, APIs o acciones empresariales concretas. En el contexto mas amplio de ciberseguridad web, el prompt injection es una amenaza que se suma a las vulnerabilidades tradicionales que ya conocemos.

El riesgo aumenta cuando la IA puede ejecutar acciones

No todas las aplicaciones con inteligencia artificial tienen el mismo nivel de exposicion. Es util distinguir tres niveles:

• Chatbot solo de texto: el riesgo se limita a la calidad de las respuestas.
• Asistente que consulta informacion: puede acceder a bases de conocimiento. El riesgo incluye extraer informacion no disponible.
• Agente que ejecuta acciones: puede crear registros, enviar correos o interactuar con sistemas. Nivel con mayor riesgo.

OWASP senala especificamente en su cheat sheet de AI Agent Security que los agentes con acceso a herramientas requieren controles adicionales: validacion de llamadas a herramientas contra permisos del usuario, monitoreo de patrones de razonamiento, y restriccion del acceso segun el principio de minimo privilegio.

Un modelo nunca deberia recibir mas permisos de los estrictamente necesarios para cumplir su funcion. Si un asistente de clasificacion de correos no necesita enviar correos, no deberia tener esa capacidad disponible.

Ejemplo empresarial sencillo

Ejemplo ficticio: Una empresa incorpora una IA que revisa solicitudes de cotizacion por correo y las clasifica automaticamente.

Si un documento adjunto contiene texto manipulado, el modelo podria omitir la clasificacion o revelar informacion del sistema. Los controles adecuados incluyen: validacion del contenido, limitacion de acciones y revision humana.

La decision final nunca deberia depender unicamente de la respuesta del modelo. Siempre debe existir una capa de validacion o aprobacion para acciones con consecuencias reales.

Por que validar solamente el formulario no es suficiente?

La validacion en el frontend no es suficiente porque el contenido que llega al modelo puede provenir de multiples fuentes:

• Archivos adjuntos que el sistema carga automaticamente.
• Paginas web que el modelo consulta durante su ejecucion.
• Datos de APIs externas que se integran al contexto.
• Contenido de bases de conocimiento.
• Correos electronicos procesados por asistentes automatizados.

Ademas, el lenguaje natural es dificil de separar completamente entre datos e instrucciones. Un texto que parece completamente legitimo puede contener patrones que el modelo interprete como instrucciones. Los filtros simples basados en palabras clave pueden ser evadidos mediante tecnicas como codificacion, errores ortograficos intencionales o variaciones sutiles.

La aplicacion debe controlar las acciones del modelo, no solo las palabras.

Como reducir el riesgo de prompt injection?

No existe una solucion unica que elimine completamente el riesgo. La recomendacion de OWASP es implementar una defensa por capas que combine multiples controles. Basandose en la documentacion oficial de OWASP GenAI Security Project y el LLM Prompt Injection Prevention Cheat Sheet, las principales medidas incluyen:

Controles de arquitectura y ejecucion

• Separar instrucciones del sistema y datos del usuario.
• Tratar todas las entradas como contenido no confiable.
• Aplicar minimo privilegio en herramientas y permisos.
• Validar parametros antes de ejecutar acciones.
• Solicitar confirmacion humana para operaciones sensibles.
• Registrar actividad y monitorear patrones anomalous.
• Probar escenarios adversariales.
• Actualizar dependencias y SDK.

Ninguna medida aislada elimina completamente el riesgo. La efectividad depende de la combinacion de multiples capas de proteccion y de la revision continua.

Que puede detectar CodeQL y que no?

La consulta js/system-prompt-injection de CodeQL identifica en el codigo fuente donde datos de usuarios terminan en el prompt de sistema sin tratamiento adecuado. Pero el analisis estatico no detecta: ataques contextuales, contenido malicioso en produccion, configuraciones externas, permisos excesivos, ni comportamientos emergentes del modelo.

Preguntas que una empresa deberia hacer antes de incorporar IA

Antes de conectar un modelo de lenguaje a un sistema empresarial, es recomendable responder preguntas como estas:

• Que informacion recibira el modelo?
• Que informacion podra consultar o acceder?
• Que acciones podra ejecutar?
• Que permisos tiene en la infraestructura?
• Donde se guardan los datos procesados?
• Existe revision humana para decisiones criticas?
• Se registran las acciones del modelo?
• Que ocurre si entrega una respuesta incorrecta o manipulada?
• Puede acceder a informacion confidencial de clientes?
• Existen limites de uso o consumo de recursos?
• Como se prueban las entradas maliciosas o adversariales?
• Que dependencias y proveedores se utilizan y cual es su historial de seguridad?

La IA debe integrarse como parte de un sistema seguro

La IA no puede tratarse como un componente aislado. Su seguridad depende del sistema completo: arquitectura, permisos, validaciones, monitoreo y procesos de revision.

No tiene sentido configurar instrucciones detalladas en el prompt si la aplicacion permite que el modelo acceda a herramientas sin restricciones. Tampoco tiene sentido confiar unicamente en filtros de entrada si el contenido puede llegar desde multiples fuentes externas. Este principio aplica a todas las integraciones de APIs.

La seguridad no puede delegarse al modelo ni a su prompt. Debe existir una arquitectura con controles externos que funcionen de forma independiente a las capacidades del modelo de lenguaje.

Conclusion

El anuncio de GitHub sobre CodeQL 2.26.0 es un paso relevante: la deteccion de prompt injection esta entrando en las herramientas de analisis que los equipos ya utilizan, facilitando la identificacion de problemas antes de produccion.

Sin embargo, la seguridad de aplicaciones con IA requiere mas que una herramienta de analisis. Necesita una estrategia que incluya:

• Diseno seguro desde el inicio del proyecto.
• Principio de minimo privilegio en los permisos del modelo.
• Validacion y monitoreo continuo.
• Revision humana para acciones con impacto real.
• Actualizacion de dependencias y practicas de seguridad.

Integrar IA de forma responsable significa pensar en seguridad tanto como en funcionalidad. Los modelos de lenguaje son herramientas poderosas, pero como cualquier otra componente de un sistema empresarial, requieren controles adecuados.

Fuentes consultadas

• GitHub. "CodeQL 2.26.0 adds Kotlin 2.4.0 support and AI prompt injection detection." GitHub Changelog, 10 julio 2026. Disponible en: github.blog/changelog (fecha de consulta: 22 julio 2026).
• GitHub. "About CodeQL." CodeQL Documentation. Disponible en: codeql.github.com/docs (fecha de consulta: 22 julio 2026).
• OWASP GenAI Security Project. "OWASP Top 10 for LLM Applications 2025." Disponible en: genai.owasp.org (fecha de consulta: 22 julio 2026).
• OWASP. "LLM Prompt Injection Prevention Cheat Sheet." OWASP Cheat Sheet Series. Disponible en: cheatsheetseries.owasp.org (fecha de consulta: 22 julio 2026).