¿Qué es la inyección de prompts? Entender la principal amenaza para los sistemas de IA

Lo que distingue la inyección de prompts de un simple error o un uso indebido accidental es la intención y el mecanismo. La IA no está malinterpretando una solicitud correctamente formulada. Está siguiendo instrucciones que nunca se autorizaron, introducidas por alguien que quiere modificar su comportamiento. Estas entradas pueden influir en un modelo incluso cuando son imperceptibles para un lector humano, ya que la inyección de prompts no depende de que el contenido sea visible o legible para una persona. Solo depende de que el contenido sea analizado por el modelo.

Por eso, la inyección de comandos se considera la amenaza más importante para los sistemas basados en IA, y ocupa el primer puesto del Top 10 de OWASP para aplicaciones de modelos de lenguaje a gran escala (LLM), con la referencia LLM01:2025. Aprovecha una característica fundamental del funcionamiento de los modelos de lenguaje: estos interpretan las instrucciones en lenguaje natural independientemente de dónde aparezcan, ya sea en un comando del sistema, en un mensaje del usuario, en un documento recuperado o en un archivo. Para obtener un análisis técnico más detallado, consulta cómo funcionan los ataques de inyección de comandos.

Por qué la inyección temprana es más importante que nunca

Durante la mayor parte de la era de la IA generativa, una indicación era una solicitud y la respuesta era un texto. Le hacías una pregunta a un chatbot y este te respondía. Si la respuesta era incorrecta, el coste solía ser, en la mayoría de los casos, solo una molestia. Esa ecuación ha cambiado con el auge de la IA agentiva.

Los sistemas de IA con capacidad de agencia no se limitan a responder. Actúan en sistemas reales para alcanzar un objetivo. En lugar de que la aplicación recurra a la IA como una función en segundo plano, la IA se convierte en un cliente que accede directamente a las aplicaciones, consulta bases de datos, inicia transacciones, modifica configuraciones y se comunica con terceros. La tecnología clave que hace posible este cambio es el Protocolo de Contexto de Modelos (MCP), que se generalizó en 2025 y proporciona a los sistemas de IA una forma estándar de conectarse con software externo. Con un conjunto de servidores MCP conectados, un asistente puede pasar de limitarse a responder a actuar.

Este cambio redefine el concepto de «prompt». Un «prompt» ya no es una línea de diálogo, sino una directiva, una command; en definitiva, un programa no determinista escrito en lenguaje natural. Y las organizaciones están avanzando rápidamente en esta dirección. La gran mayoría de ellas tiene previsto invertir más en IA agentiva, atraídas por las ganancias en productividad que los directivos comparan con la incorporación de personal nuevo.

Cuando una instrucción se convierte en un programa, la inyección de instrucciones deja de ser una simple respuesta errónea y pasa a ser una acción no autorizada con consecuencias importantes. Lo que está en juego ya no es si el resultado se lee bien, sino si un sistema autónomo acaba de hacer algo que nunca debería haberse permitido hacer.

software de inyección de comandos frente a software tradicionales

La comunidad de seguridad ya se ha enfrentado antes a una variante de este problema. En software tradicional, las organizaciones no permiten que se ejecute código arbitrario en su entorno. Se aseguran de que solo se ejecuten archivos ejecutables autorizados y firmados, utilizando mecanismos como el Control de cuentas de usuario de Windows, que verifica que un programa esté aprobado y no haya sido modificado antes de su ejecución. Al firmar el software y verificar la firma, se obtiene la seguridad de que lo que se está ejecutando es lo previsto.

La inyección de comandos es el equivalente en lenguaje natural a la inyección de instrucciones maliciosas en una aplicación autorizada. Cuando el «programa» es una directiva redactada en prosa, en lugar de código compilado, se aplica la misma preocupación fundamental: solo deben ejecutarse las instrucciones autorizadas, y dichas instrucciones no deben haber sido alteradas en ningún momento. En todo caso, la preocupación es aún mayor, ya que el lenguaje natural es más fluido y más difícil de restringir que los binarios compilados.

Este paralelismo apunta hacia un tipo de solución ya conocido. Del mismo modo que la firma de código garantiza que un ejecutable procede de una fuente de confianza y no ha sido alterado, los enfoques criptográficos pueden ayudar a garantizar que una directiva de IA sea auténtica y no haya sido modificada. Esa solución análoga se analiza en profundidad en nuestra página sobre la firma de prompts. La idea importante aquí es, sencillamente, que garantizar que solo se ejecuten instrucciones autorizadas es un reto que comparten ambos paradigmas.

Tipos de inyección inmediata

La inyección de comandos no es una técnica única. Los marcos de referencia del sector, como el OWASP LLM01:2025, describen dos categorías principales, definidas en función del punto en el que la instrucción maliciosa entra en el sistema.

Inyección directa por comando

La inyección directa de indicaciones se produce cuando la entrada de un usuario altera directamente el comportamiento del modelo de forma no deseada o inesperada. Esto puede ser intencionado, en el caso de que un actor malintencionado elabore deliberadamente una indicación para explotar el modelo, o involuntario, cuando un usuario proporciona sin darse cuenta una entrada que desencadena un comportamiento inesperado. Un ejemplo clásico es el de un atacante que ordena a un chatbot de atención al cliente que ignore sus directrices anteriores y revele datos privados.

Inyección indirecta de comandos

La inyección indirecta de indicaciones se produce cuando un modelo acepta datos de fuentes externas, como páginas web o archivos, y ese contenido externo contiene instrucciones que, al interpretarse, alteran el comportamiento del modelo. Por ejemplo, un documento recuperado para responder a una pregunta podría contener texto oculto que redirija al modelo. Dado que la instrucción se encuentra dentro de los datos que se le ha pedido al modelo que procese, es posible que el usuario nunca la vea. El auge de la IA multimodal, que gestiona varios tipos de datos a la vez, amplía aún más esta superficie de ataque: un atacante puede ocultar instrucciones dentro de una imagen que acompañe a un texto inofensivo, lo que da lugar a ataques multimodales difíciles de detectar con las técnicas actuales.

En ambos casos, el impacto de un ataque exitoso varía en función del contexto empresarial y del nivel de autonomía que se le haya otorgado al sistema. Entre los resultados más habituales se incluyen la divulgación de información sensible, la exposición de las indicaciones del sistema o de detalles de la infraestructura, la manipulación de los resultados, el acceso no autorizado a funciones disponibles para el modelo, la ejecución de comandos arbitrarios en sistemas conectados y la interferencia en la toma de decisiones críticas.

¿Por qué es peligrosa la inyección de indicaciones en la IA agentiva y el reto de los sistemas multiagente?

En un chatbot, una inyección de comandos exitosa podría generar un párrafo engañoso. En un sistema basado en agentes, el mismo ataque puede desencadenar consecuencias que se extienden al mundo real. Dado que los agentes pueden ejecutar consultas no autorizadas en bases de datos, iniciar transacciones financieras o modificar configuraciones de infraestructura, una sola inyección puede provocar interrupciones del servicio, pérdida de datos, fallos en las auditorías de cumplimiento normativo y una pérdida duradera de la confianza de los clientes. En entornos ciberfísicos, donde software los equipos, las posibles consecuencias se extienden a riesgos para la seguridad física.

Una característica definitoria de este peligro es que aumenta proporcionalmente a la autonomía. Cuanta más independencia en la toma de decisiones concede una organización a un agente, y cuanto más amplio es el conjunto de sistemas a los que puede acceder, mayor es el alcance de cualquier instrucción que se cuele. Un agente que solo puede redactar textos supone un riesgo bajo. Un agente que puede mover dinero o reconfigurar sistemas de producción, en cambio, no lo es.

El riesgo se agrava en las arquitecturas multiagente. En estos sistemas, un agente suele pasar datos o instrucciones a otro, que a su vez los transmite a un tercero, y así sucesivamente. En el proceso, puede perderse el contexto que permite distinguir qué partes de los datos han sido enviadas por el usuario y, por tanto, no son fiables, frente a las generadas por el sistema y que sí lo son. Esto se asemeja al juego del teléfono: para cuando una instrucción llega a un agente situado varios eslabones más abajo en la cadena, es posible que ya se haya perdido la información necesaria para distinguir una directiva legítima de una inyectada. Por lo tanto, un único punto de inyección puede propagar instrucciones no autorizadas a lo largo de toda la cadena, y cada agente tendrá menos capacidad que el anterior para detectar el problema.

Entre los ejemplos concretos de cómo se llevan a cabo estos ataques se incluyen el caso de un atacante que introduce instrucciones ocultas en una página web para que una IA que la resuma filtre una conversación privada, o el de la modificación de un documento en un repositorio de conocimientos para que una aplicación de búsqueda mejorada devuelva resultados manipulados. Estos escenarios, documentados por OWASP, muestran cómo el contenido habitual se convierte en un vector de ataque una vez que un agente tiene la capacidad de actuar sobre él.

Cómo encaja la inyección rápida en el panorama general de las amenazas de la IA

La inyección de comandos es la amenaza más destacada para la IA agentiva, pero no es la única. Comprender en qué consiste ayuda a aclarar por qué ningún control por sí solo resulta suficiente. Los sistemas agentivos se enfrentan a un conjunto de amenazas relacionadas, cada una de ellas de origen distinto al de la inyección de comandos, aunque el daño pueda parecer similar:

• Ataques de «hombre en medio» contra las directivas:interceptación y modificación de las instrucciones a medida que se transmiten a través de las redes entre los sistemas de origen y el entorno de ejecución del agente.
• Ataques de repetición:reenvío de una orden previamente autorizada para provocar la repetición no autorizada de una acción.
• Amenazas internas:usuarios autorizados que emiten instrucciones fuera de su ámbito de competencia.
• Sistemas de origen comprometidos:puntos de integración legítimos que han sido secuestrados y que ahora emiten instrucciones maliciosas.
• Ingeniería social:manipulación de los operadores humanos que aprueban o emiten directrices.

La inyección de comandos se diferencia de cada uno de ellos, no solo desde el punto de vista técnico, sino también en su naturaleza. Desde el punto de vista técnico, un ataque de inyección de comandos oculta instrucciones no autorizadas dentro de los datos que procesa el agente, en lugar de interceptar una directiva en tránsito, reproducir una antigua o manipular a una persona. En cuanto a su naturaleza, el ataque de inyección de comandos es el más fundamental, ya que puede encontrarse como parte de cualquiera de estos ataques o combinarse con ellos. Además, las categorías se solapan en la práctica, lo que explica precisamente por qué los defensores no pueden confiar en un único mecanismo. Abordar este panorama en su totalidad requiere un enfoque por capas dela seguridad de los comandos, en el que controles complementarios cubran cada uno las amenazas que otros dejan pasar.

Un ejemplo de la vida real

OpenClaw es un marco de trabajo open-source para agentes open-source . Fue creado por el desarrollador Peter Steinberger (que ahora trabaja en OpenAI), se lanzó a finales de 2025 con el nombre de Clawdbot y, tras un par de cambios de nombre, pasó de tener unas 9.000 estrellas en GitHub a 60.000 en tres días, convirtiéndose finalmente en uno de los proyectos con más estrellas de la plataforma. Su atractivo radica en que actúa en lugar de aconsejar: el usuario lo conecta a su bandeja de entrada, a sus archivos y a un navegador, describe una tarea en lenguaje sencillo y el agente la lleva a cabo en su nombre. Esa capacidad es lo que lo convirtió en un sujeto de prueba útil. Los investigadores de Varonis se propusieron responder a una pregunta sencilla: ¿las técnicas de phishing que han funcionado contra las personas durante décadas también funcionan contra los agentes que ahora actúan en su nombre?

Crearon un agente, le asignaron una cuenta de correo electrónico y acceso a los datos internos de una empresa ficticia, y le enviaron una serie de mensajes de phishing. El agente gestionó bien los señuelos técnicos. Un enlace sospechoso, una página de inicio de sesión falsa y una aplicación OAuth maliciosa camuflada como una herramienta de registro de horas fueron inspeccionados y rechazados. Sin embargo, su rendimiento fue muy diferente cuando el atacante se saltó el componente técnico y se limitó a redactar un correo electrónico convincente. Un mensaje de alguien que se hacía pasar por un jefe de equipo, en el que se mencionaba un problema de producción y se solicitaba acceso al entorno de pruebas, llevó al agente a localizar las credenciales y enviarlas a una dirección externa. Un segundo mensaje, de alguien que afirmaba estar trabajando a distancia y necesitar la lista de clientes para una presentación, provocó que se facilitara dicha lista. No se utilizó ningún malware ni exploit, solo un pretexto plausible y una sensación de urgencia. La conclusión más significativa para cualquiera que implemente estos sistemas es que una configuración «estricta», con instrucciones explícitas de verificar la identidad del remitente antes de realizar acciones sensibles, falló de la misma manera. El propio correo electrónico fue el ataque. El agente trató el mensaje entrante como si procediera de su operador, ya que no dispone de medios fiables para distinguir una instrucción de su propietario de un texto que simplemente se le parezca, y, una vez que la solicitud pareció urgente, se omitió el paso de verificación que se le había ordenado realizar.

Estrategias de prevención y mitigación

Dado que la inyección de comandos se deriva de la forma fundamental y probabilística en que los modelos generativos interpretan el lenguaje —que es precisamente cómo funcionan los modelos generativos actuales—, no puede eliminarse por completo con las arquitecturas actuales. OWASP señala que no existe ningún método de prevención infalible conocido. Lo que las organizaciones pueden hacer es reducir de forma significativa la superficie de ataque y limitar el daño de cualquier inyección que tenga éxito. OWASP LLM01:2025 recomienda varias medidas:

1. Limitar el comportamiento del modelo.
   Proporciona al modelo instrucciones claras sobre su función, sus capacidades y sus límites en la solicitud del sistema. Exige un estricto cumplimiento del contexto, mantén las respuestas limitadas a las tareas definidas y indica al modelo que ignore cualquier intento de alterar sus instrucciones fundamentales.
2. Definir y validar los formatos de salida esperados.
   Especificar los formatos de salida, solicitar el razonamiento y las citas de las fuentes, y utilizar código determinista para comprobar que las respuestas se ajustan a ellos.
3. Implementar filtros de entrada y salida.
   Definir categorías sensibles, crear reglas para identificarlas y gestionarlas, aplicar filtros semánticos y buscar contenido no permitido. Evaluar las respuestas en cuanto a la pertinencia del contexto, la fundamentación y la pertinencia de la respuesta ayuda a detectar resultados potencialmente maliciosos.
4. Aplica el control de privilegios y el principio del «privilegio mínimo».
   Asigna a la aplicación sus propios tokens de API para ampliar su funcionalidad, gestiona esas funciones en el código en lugar de exponerlas al modelo y limita los privilegios del modelo al mínimo necesario.
5. Exigir la aprobación humana para las acciones de alto riesgo.
   Establecer controles con intervención humana antes de las operaciones con privilegios, de modo que las acciones sensibles no puedan llevarse a cabo sin supervisión.
6. Separar e identificar el contenido externo.
   Separar y etiquetar claramente el contenido no fiable para que tenga menos influencia sobre el comportamiento del modelo.
7. Realizar pruebas adversarias y simulaciones de ataques.
   Realizar periódicamente pruebas de penetración y simulaciones de brechas de seguridad, tratando el modelo como un usuario no fiable para poner a prueba los límites de confianza y los controles de acceso.

En conjunto, estas medidas conforman una estrategia defensiva más que una solución aislada. El problema de la autorización de la directiva

La inyección de comandos se entiende mejor como un síntoma de una cuestión arquitectónica más amplia: ¿cómo sabe un sistema que las instrucciones que recibe un agente de IA son fiables? Cuando se le transmite una directiva a un agente, hay que responder a varias preguntas antes de que actúe:

• Autenticidad:¿Proviene esta directiva de una fuente legítima y autorizada?
• Integridad:¿Se ha modificado la directiva desde su publicación?
• Autorización:¿Está autorizada esta fuente a emitir este tipo de directiva?
• Actualidad: ¿Esta directiva está vigente o se trata de una repetición de una instrucción autorizada anteriormente?
• Seguridad semántica:¿El cumplimiento de esta directiva se ajustará a la política de la organización?

La dificultad principal radica en que no existe un único mecanismo que dé respuesta a las cinco cuestiones. La inclusión en listas blancas y el uso de plantillas son deterministas y auditables, pero se vuelven inmanejables a medida que se amplían los casos de uso, y bloquean por defecto las solicitudes legítimas novedosas. Los códigos de autorización de un solo uso ofrecen protección contra la repetición de ataques y un registro de auditoría claro, pero añaden una dependencia en tiempo de ejecución y simplemente trasladan el problema de la aprobación humana. Los filtros semánticos basados en IA comprenden la intención y se adaptan a nuevas situaciones, pero son no deterministas, aumentan los costes e introducen ellos mismos una nueva superficie de ataque.

Por eso, los diseños robustos incorporan controles complementarios, cada uno de los cuales aborda una parte del problema. Enmarcar la inyección de prompts de esta manera, como una cuestión de autorización directiva, allana el terreno para comprender por qué son necesarios los mecanismos de confianza fundamentales. Para conocer soluciones prácticas, véase«Prevención de ataques de inyección de prompts en la IA agentiva».

Cómo Keyfactor ayudarte Keyfactor

Keyfactor la inyección de comandos mediante la confianza criptográfica. El mismo modelo que protege software firmado software aplicarse a las directivas de IA: firmar la instrucción en su fuente autorizada y, a continuación, verificar esa firma antes de que el agente actúe. La infraestructura de firma empresarial Keyfactor, SignServer, junto con su plataforma PKI, EJBCA, permite a las organizaciones firmar las directivas de los agentes de IA, confirmar su autenticidad e integridad antes de su ejecución y garantizar la vigencia mediante marcas de tiempo, de modo que las directivas antiguas capturadas no puedan reproducirse posteriormente.

Un servicio de firma centralizado también elimina gran parte de la carga operativa. Los sistemas que necesitan firmar una directiva recurren a una API de firma y nunca gestionan las claves privadas directamente, mientras que la generación, el almacenamiento seguro, la rotación y la revocación de las claves se gestionan de forma centralizada según la política establecida. En el modelo de seguridad por capas, la firma criptográfica constituye la capa de confianza fundamental. Es lo que hace que las capas superiores, como el análisis semántico y la supervisión humana, sean fiables, ya que analizar una directiva de origen desconocido arroja conclusiones sobre las que no se puede actuar con seguridad, mientras que analizar una directiva verificada permite actuar con confianza.

Para ver cómo encajan todas estas piezas en la producción, descubre el enfoqueKeyfactorpara proteger los agentes de IA.

Principales conclusiones

• La inyección de comandos es contenido malicioso oculto en los datos que procesa una IA, diseñado para anular sus instrucciones y hacer que realice acciones no deseadas. Se considera el riesgo número uno en el Top 10 de OWASP para aplicaciones de modelos de lenguaje grande (LLM).
• Con la IA agentiva, lo que está en juego aumentó considerablemente.Cuando una indicación se convierte en una orden que un agente lleva a cabo, la inyección pasa de generar una respuesta errónea a desencadenar acciones no autorizadas en el mundo real.
• Existen varios tipos, entre ellos la inyección directa, la indirecta y la activada, y el peligro aumenta cuanto mayor es el nivel de autonomía que se concede a un agente.
• El riesgo se agrava en los sistemas multiagente, en los que la información sobre si los datos son fiables o no puede perderse a medida que las instrucciones pasan de un agente a otro.
• Ninguna medida de defensa por sí sola es suficiente.Una protección eficaz se basa en controles de entrada, el principio del privilegio mínimo, la supervisión humana, el análisis semántico y una capa fundamental de confianza criptográfica que verifica la autenticidad y la integridad de las directivas.