Inyección de prompts: cómo se puede atacar a un agente de IA
La inyección de prompts consiste en presentar una instrucción maliciosa como una orden que el modelo debe seguir, por ejemplo, dentro de un documento, un correo electrónico o una página web que consulta. Un agente de IA puede entonces desviarse de su objetivo, alterar su respuesta o utilizar sus herramientas en beneficio de un atacante. Las consecuencias dependen de los datos a los que tiene acceso y de las acciones que permite la aplicación.
El punto de ruptura: un dato se convierte en una orden
Usted pide a un asistente que resuma un documento. Ese documento contiene información útil, pero también un pasaje que le indica que cambie de tarea. Si el modelo obedece ese pasaje, el contenido que debía analizar ha sustituido a las instrucciones de trabajo.
El modelo recibe mensajes con distintos roles y con prioridades definidas por la aplicación. Esta organización ayuda a distinguir las instrucciones de los datos, pero no constituye una barrera de seguridad infalible. El significado de un texto externo puede influir en las decisiones del modelo, incluso cuando ese texto llega como resultado de una herramienta.
El trabajo de Kai Greshake y sus coautores, presentado el 23 de febrero de 2023, mostró cómo las instrucciones insertadas en datos recuperados pueden desviar el comportamiento de aplicaciones que incorporan un modelo de lenguaje. Su publicación sobre la inyección indirecta describe, entre otros efectos, la manipulación de respuestas y de las interacciones con herramientas.
Por tanto, el atacante no necesita necesariamente su contraseña ni acceso al servidor. Puede intentar controlar un contenido que el agente encontrará durante una tarea legítima. Aquí resulta decisiva la diferencia entre un agente de IA y un chatbot: una respuesta manipulada puede convertirse en una acción cuando hay herramientas disponibles.
Inyección directa e indirecta: dos vías de entrada
La diferencia está en el recorrido que sigue la instrucción. En una inyección directa, llega a través de la interfaz de conversación. En una indirecta, procede de una fuente que el asistente consulta para atender su solicitud.
| Criterio | Inyección directa | Inyección indirecta |
|---|---|---|
| Punto de entrada | Mensaje enviado al asistente | Documento, página, correo o resultado de una herramienta |
| Qué controla el atacante | El texto de su solicitud | Una parte del contenido consultado |
| Situación del usuario legítimo | Puede ser una persona distinta del atacante | Suele iniciar una tarea habitual |
| Límite que se intenta vulnerar | Las reglas de la aplicación frente a una solicitud | Las instrucciones de trabajo frente a los datos externos |
OWASP distingue estas formas de inyección y recuerda que sus efectos dependen de las capacidades concedidas al sistema. Un intento no tiene éxito de forma automática: el modelo puede ignorarlo, un control puede bloquear la acción o la herramienta solicitada puede no estar disponible.
El término jailbreak se refiere, de forma más específica, a eludir las restricciones de comportamiento o de seguridad del modelo. Puede coincidir con una inyección de prompts, pero no abarca todos sus objetivos: alterar discretamente un resumen comercial no exige necesariamente que el modelo genere contenido prohibido.
Una alucinación, por su parte, puede producirse sin intervención de un atacante. Por eso, una respuesta errónea no demuestra que haya habido un ataque. Para identificar una inyección, hay que buscar el contenido que intentó desviar el comportamiento y examinar su influencia en los pasos posteriores.
Un correo manipulado puede desviar una tarea legítima
Veamos un escenario ficticio: usted pide a un agente que lea las solicitudes recibidas y prepare las respuestas. Un remitente malicioso añade a su mensaje una instrucción que presenta como una comprobación interna y que pide transmitir información ajena a la solicitud.
La cadena de riesgo es la siguiente:
- El agente recupera el correo como parte de la tarea que usted le ha encargado.
- El modelo recibe el cuerpo del mensaje como contenido que debe analizar.
- Interpreta el pasaje malicioso como una instrucción que debe cumplir.
- Propone una llamada a una herramienta para buscar o transmitir datos.
- La aplicación ejecuta esa llamada si sus controles lo permiten.
El paso crítico se encuentra entre leer el mensaje y obtener autorización para actuar. Un correo puede solicitar una cita; no debería poder ampliar los permisos del asistente que lo procesa.
En una publicación del 24 de noviembre de 2025 sobre agentes de navegación, Anthropic presenta un escenario similar: un correo contiene instrucciones ocultas destinadas a provocar una filtración. La empresa subraya que mejorar la resistencia de los modelos no hace que estos agentes sean inmunes.
La manipulación también puede ser discreta: omitir una salvedad, favorecer a un proveedor o añadir una afirmación a un informe. Una inyección exitosa no necesita abrir una terminal. Alterar la información en la que usted basa sus decisiones puede bastar para beneficiar al atacante.
El contenido consultado amplía la superficie de ataque
Una instrucción maliciosa puede aparecer en un texto visible, una imagen interpretada por el modelo, un comentario de código o el texto extraído de un documento. No necesita estar oculta: una nota técnica falsa puede parecer lo bastante creíble como para influir en el asistente.
Un sistema de RAG recupera fragmentos de documentos para elaborar la respuesta. Esa recuperación no certifica que los fragmentos tengan autoridad para dar instrucciones. Un pasaje pertinente para su pregunta también puede contener una orden ajena a su objetivo; estar en una base de datos interna no lo convierte automáticamente en contenido confiable.
Las herramientas añaden otra vía de entrada. Un buscador, un lector de archivos o un conector de una aplicación empresarial devuelve contenido al modelo. Hay que distinguir entre la confianza depositada en el software que transporta ese contenido y la que merece el propio contenido: un conector legítimo puede devolver un mensaje hostil.
La especificación de herramientas de MCP describe cómo un modelo puede descubrir herramientas y llamarlas, y recomienda una intervención humana que permita rechazar su ejecución. El protocolo no exime a la aplicación de definir sus permisos y sus mecanismos de confirmación.
La memoria persistente también requiere atención. Si una instrucción externa se guarda como preferencia o regla de trabajo, puede influir en tareas posteriores. El artículo sobre la memoria de los agentes de IA explica por qué la procedencia de la información almacenada importa tanto como su contenido.
Las medidas útiles separan lectura, decisión y ejecución
La primera medida consiste en reducir las consecuencias que podría tener una decisión manipulada. Un agente encargado de preparar un resumen normalmente no necesita enviar mensajes, modificar una base de datos ni consultar todas las carpetas de la empresa.
Aplique el principio de mínimo privilegio a las cuentas, los archivos y las herramientas. Dé prioridad al acceso de solo lectura cuando la tarea lo permita. Mantenga las credenciales y otros secretos en un gestor que utilice el software, en lugar de incluirlos en los mensajes enviados al modelo.
Después, la autorización debe comprobarse en el momento de la ejecución, mediante código independiente de la respuesta del modelo. La guía de OWASP sobre seguridad de agentes recomienda, entre otras medidas, limitar las capacidades y controlar las operaciones sensibles. Pedir al modelo que respete los permisos no sustituye esa comprobación.
Antes de un envío externo, la confirmación debería mostrar el destinatario, el contenido exacto y los archivos adjuntos. Antes de una modificación, debería indicar qué recursos se verán afectados. Una aprobación general al principio de una tarea larga difícilmente permite revisar una acción que surge después de leer contenido hostil.
Por último, limite los destinos de red y aísle la ejecución de código. Un entorno aislado solo protege lo que queda fuera de su alcance: si contiene documentos confidenciales y puede comunicarse libremente, sigue existiendo una vía de filtración. La guía Cómo proteger un agente de IA detalla estas decisiones y sus implicaciones.
Por qué no basta con pedir prudencia al modelo
Indicar claramente que los documentos externos son datos sigue siendo útil. Conservar su procedencia, separar los fragmentos recuperados de las instrucciones de la aplicación y limitar el contexto enviado puede ayudar al modelo a respetar su objetivo.
Sin embargo, estas medidas no garantizan que resista todas las formulaciones posibles. Un ataque puede afirmar que corrige un error, alegar una urgencia o presentar una acción indeseada como un requisito previo necesario. Buscar únicamente una frase que pida ignorar las instrucciones deja pasar muchas variantes.
La guía de prevención de OWASP señala que el filtrado de entradas no constituye una barrera de seguridad. Los filtros pueden pasar por alto un ataque reformulado o bloquear un documento legítimo que explique precisamente este tipo de amenaza.
Un segundo modelo encargado de revisar el contenido puede aportar una señal adicional. Debe complementar las restricciones técnicas: su dictamen sigue siendo una salida de un modelo, con sus propias limitaciones.
Ni siquiera un formato estructurado demuestra que una acción esté autorizada. Una solicitud que respeta perfectamente el esquema previsto puede indicar un destinatario incorrecto. El software debe comprobar la relación entre la acción propuesta, los permisos del usuario y la tarea encomendada.
Comprobar los efectos reales y preparar la interrupción
La evaluación debe reproducir sus usos habituales con datos ficticios y herramientas sin efectos reales. Introduzca instrucciones que intenten desviar la tarea en los tipos de contenido que el sistema consulta: documentos, mensajes o respuestas de conectores. Después, compruebe qué intenta hacer.
Observar solo la respuesta final no sería suficiente. Un agente puede generar un informe satisfactorio después de haber intentado una operación indeseada. Examine las llamadas a herramientas, las autorizaciones denegadas, los destinos contactados y los datos que puedan haberse guardado en la memoria.
Registre también los falsos positivos: una protección que bloquea documentos corrientes dificulta el uso del servicio. Los resultados deben indicar el alcance de las pruebas y las acciones que se han impedido, sin convertir la ausencia de fallos observados en una garantía general.
Si detecta una actividad sospechosa, interrumpa la tarea y suspenda los accesos afectados. Conserve los registros útiles procurando no multiplicar las copias de credenciales u otros secretos. Antes de reanudar el trabajo, revise las acciones que se ejecutaron realmente, los datos transmitidos y la información guardada en la memoria.
El diagnóstico de seguridad de agentes de IA permite repasar estos puntos. La pregunta práctica sigue siendo la misma: si el modelo obedece una instrucción maliciosa, ¿qué controles impiden que ese error cause un daño?
Puntos clave
- La inyección de prompts explota el paso de un contenido que debe analizarse a una instrucción que el modelo obedece.
- Una fuente útil o un conector legítimo puede transportar una instrucción hostil.
- Las consecuencias dependen del acceso a los datos, las herramientas disponibles y las comunicaciones autorizadas.
- Las instrucciones y los filtros complementan los permisos, las validaciones humanas y los controles de ejecución.
- Evalúe las acciones reales del agente, incluidas las que preceden a su respuesta final.
Preguntas frecuentes
¿Puede una inyección de prompts robar una contraseña?
Puede provocar una filtración si el sistema tiene acceso a la contraseña y dispone de un medio para transmitirla. Una contraseña que no figura entre los datos accesibles no pasa a estar disponible por la mera redacción de un mensaje. Entre las medidas de protección están mantener las credenciales fuera del contexto del modelo y limitar el acceso de las herramientas.
¿Un antivirus detecta las inyecciones de prompts?
Una instrucción maliciosa puede ser texto corriente dentro de un documento, sin ningún programa ejecutable. Por eso, un análisis antivirus no basta para determinar que un agente puede procesar ese documento sin riesgo. También hay que controlar las acciones que podría desencadenar su contenido.
¿Un modelo que se ejecuta en local está protegido?
La ejecución local no elimina la posible confusión entre datos e instrucciones. Un agente local que lee documentos externos sigue expuesto, sobre todo si dispone de una terminal o de conexiones a sus cuentas. La ausencia de red puede limitar algunas filtraciones, pero no impide las modificaciones de archivos que tenga autorizadas.
¿Cómo reconocer un documento que contiene una inyección de prompts?
Desconfíe de los pasajes que se dirigen al asistente, alegan una autoridad técnica o piden una acción ajena a su objetivo. Que no vea ninguno no ofrece garantías: el agente puede recibir una extracción distinta de lo que usted ve. La revisión debe abarcar el contenido que llega al modelo y las llamadas a herramientas.