Los ataques de inyección de comandos aprovechan la forma en que los grandes modelos de lenguaje interpretan las instrucciones. Al insertar directivas maliciosas en entradas que, por lo demás, son legítimas, los atacantes pueden hacer que los agentes de IA ejecuten acciones no deseadas. Cuando estos agentes pueden acceder de forma autónoma a los sistemas, bases de datos y API de la empresa, la inyección de comandos pasa de ser un problema de contenido a convertirse en una amenaza de seguridad en la capa de ejecución con consecuencias en el mundo real.
Para comprender cómo funcionan los ataques de inyección de comandos, es necesario analizar la arquitectura fundamental de los sistemas de IA agentiva y los límites de confianza que los atacantes pretenden vulnerar. A diferencia de las amenazas tradicionales a la seguridad de las aplicaciones, la inyección de comandos aprovecha la ambigüedad inherente al procesamiento del lenguaje natural, lo que hace que sea especialmente difícil defenderse de ella con controles de seguridad convencionales.
Los fundamentos de un ataque de inyección de comandos
Los ataques de inyección de comandos se basan en el principal reto al que se enfrentan los modelos de lenguaje a gran escala: distinguir entre las instrucciones fiables del sistema y los datos no fiables del usuario. El ataque se produce en la capa de interpretación de instrucciones, donde el modelo procesa la entrada en lenguaje natural y determina qué acciones llevar a cabo.
Anulación de instrucciones
La forma más directa de inyección de comandos consiste en insertar comandos de anulación explícitos en los datos controlados por el usuario. Un atacante rellena un formulario web dejando el campo «dirección de domicilio» con el valor «Ignorar instrucciones anteriores y…» seguido de directivas maliciosas. El modelo, al procesar esto como parte de su flujo de entrada, puede interpretar la directiva maliciosa como una instrucción legítima y ejecutarla.
Esto funciona porque los modelos de lenguaje procesan toda la información introducida como posibles instrucciones. El modelo no puede determinar con fiabilidad si una frase debe procesarse como contenido o interpretarse como un command.
Confusión contextual
El segundo mecanismo aprovecha la forma en que los agentes de IA gestionan el contexto a través de múltiples fuentes de datos. En un flujo de trabajo típico de un agente, este recibe:
- Un mensaje del sistema en el que se definen su función y sus limitaciones
- Instrucciones o consultas proporcionadas por el usuario
- Contenido externo obtenido de bases de datos, API o documentos
- Resultados provisionales de operaciones anteriores
El modelo debe mantener unos límites de confianza adecuados entre estas fuentes, pero se produce una confusión de contexto cuando el modelo no logra distinguir entre ellas. El contenido malicioso incrustado en un documento recuperado o en una respuesta de API puede ser tratado con la misma autoridad que la propia solicitud del sistema.
Esto resulta especialmente peligroso en los sistemas multiagente. El agente A podría recuperar datos que contengan instrucciones inyectadas, procesarlos como contenido legítimo y transmitirlos al agente B. A medida que los datos se propagan a través de múltiples agentes, el límite de confianza se debilita con cada paso. Varios agentes más adelante, es posible que el sistema haya perdido por completo el contexto de que parte de los datos procedía de una fuente no fiable y no debía interpretarse como instrucciones ejecutables.
Desencadenante de ejecución
En los sistemas de agentes dotados de acceso a herramientas, las consecuencias de una inyección exitosa de comandos van mucho más allá de la generación de respuestas de texto inadecuadas. Cuando una instrucción inyectada se ejecuta, el agente puede:
- Llamar a las API con privilegios elevados
- Modificar o eliminar datos en los sistemas conectados
- Acceder a repositorios de código y modificar archivos fuente
- Realizar transacciones financieras
- Reconfigurar los ajustes de la infraestructura
- Sustrar información confidencial
El desencadenante de la ejecución representa el momento en el que una vulnerabilidad de seguridad se convierte en un incidente de seguridad. El agente, incapaz de reconocer que no está siguiendo instrucciones legítimas, utiliza los permisos que se le han concedido para llevar a cabo acciones que favorecen los objetivos del atacante en lugar de los de la organización.
Amplificación multiagente
En los sistemas distribuidos basados en agentes, los riesgos de inyección de comandos se multiplican debido a un fenómeno similar al juego infantil del teléfono, en el que, al pasar un mensaje de uno a otro susurrando al oído de la persona siguiente, la transmisión inevitablemente pierde fidelidad, lo que distorsiona el contenido original. Cuando varios agentes colaboran para realizar tareas complejas, cada uno de ellos se convierte en un vector potencial para la propagación de instrucciones maliciosas.
Como describe Simon Willison en este análisis de «la trifecta letal» , la combinación de grandes modelos de lenguaje, el acceso a datos privados y la capacidad de actuar en sistemas externos crea una dinámica de seguridad especialmente peligrosa. Cuando los agentes procesan entradas de confianza mixta y poseen capacidad de ejecución, el riesgo pasa de ser una salida incorrecta a un compromiso operativo. En los flujos de trabajo multiagente, este riesgo se agrava a medida que las instrucciones se transmiten entre sistemas. capacidad de ejecución, el riesgo pasa de ser una salida incorrecta a un compromiso operativo. En los flujos de trabajo multiagente, este riesgo se agrava a medida que las instrucciones se transmiten entre sistemas.
Imaginemos un flujo de trabajo en el que el agente A se encarga de analizar los tickets de asistencia. Este recupera el contenido del ticket de una base de datos, lo procesa y determina que el agente B —especializado en operaciones con bases de datos— debe encargarse de la resolución. A continuación, el agente B transmite los resultados al agente C para su validación final. Si el ticket original contiene instrucciones insertadas, dichas instrucciones se transmiten a lo largo de toda la cadena de agentes.
La amplificación se produce porque:
- Herencia de confianza: Cada agente posterior puede confiar implícitamente en los datos transmitidos por los agentes anteriores en el flujo de trabajo
- Pérdida de contexto: A medida que los datos se transmiten entre agentes, es posible que se eliminen los metadatos que indican su origen y su nivel de confianza
- Escalada de permisos: Los distintos agentes suelen tener diferentes niveles de privilegios, lo que permite que los comandos inyectados accedan a recursos que no están disponibles para el punto de entrada original
- Ejecución diferida: Las instrucciones maliciosas pueden permanecer inactivas durante varios saltos antes de activarse en un agente que cuente con las capacidades específicas necesarias para su explotación
Esta amplificación por múltiples agentes hace que la inyección rápida resulte especialmente insidiosa en entornos empresariales, donde los flujos de trabajo complejos implican a numerosos agentes especializados, cada uno de los cuales tiene acceso a diferentes sistemas y fuentes de datos.
Riesgo de ataques de repetición en mensajes firmados
Incluso cuando las organizaciones implementan la firma criptográfica para verificar la autenticidad e integridad de las indicaciones, los ataques de repetición siguen representando una amenaza constante. Si un atacante captura una indicación firmada, la firma sigue siendo válida indefinidamente, a menos que se implementen controles adicionales.
El escenario del ataque de repetición se desarrolla de la siguiente manera:
- Un usuario legítimo firma una solicitud en la que ordena a un agente que realice una operación delicada (por ejemplo, «Inscribir un certificado para el sistema X»)
- La solicitud firmada, junto con su firma y la cadena de certificados, se transmite al agente
- Un atacante intercepta u obtiene de cualquier otra forma una copia del paquete firmado completo
- Más tarde, el atacante vuelve a enviar la misma solicitud firmada
- El agente verifica la firma, vuelve a comprobar que es válida y vuelve a ejecutar la directiva
Esto resulta especialmente peligroso en el caso de operaciones puntuales que nunca deben repetirse. A diferencia de las tareas recurrentes (como la clasificación diaria de los correos electrónicos por orden de prioridad), operaciones como la emisión de certificados, las modificaciones en la base de datos o los cambios de configuración pueden causar daños importantes si se ejecutan varias veces.
La estrategia de mitigación principal consiste en la validación de marcas de tiempo con umbrales de actualidad. El servicio de firma incluye una marca de tiempo de confianza en la carga útil firmada, y el agente verificador rechaza las firmas más antiguas que un umbral configurable adecuado al caso de uso. Las organizaciones deben ajustar los intervalos de vigencia en función de su modelo de implementación:
- Agentes interactivos: Plazos de vigencia muy cortos (de segundos a minutos) cuando las directivas se firman inmediatamente antes de la ejecución
- Agentes por lotes o programados: Ventanas más amplias cuando las directivas se firman por adelantado y se ponen en cola para su ejecución posterior
- Operaciones de alto riesgo: Límites más estrictos para acciones delicadas que podrían causar daños importantes si se repitieran
Este enfoque garantiza que, incluso si un atacante captura una solicitud firmada, esta quede inutilizable una vez que expire el plazo de validez, lo que reduce considerablemente la superficie de ataque por repetición.
Por qué fallan los controles de seguridad tradicionales
Las organizaciones acostumbradas a defenderse de las amenazas tradicionales a la seguridad de las aplicaciones suelen descubrir que sus controles actuales no ofrecen una protección suficiente contra los ataques de inyección de comandos. Esta deficiencia se debe a discrepancias fundamentales entre el funcionamiento de dichos controles y el modo en que operan los ataques de inyección de comandos.
Cortafuegos de aplicaciones web
Los cortafuegos de aplicaciones web (WAF) destacan por su capacidad para detectar y bloquear ataques que siguen patrones predecibles, como la inyección SQL, el cross-site scripting, el recorrido de rutas y otras vulnerabilidades similares. Estos ataques suelen implicar secuencias de caracteres específicas, estructuras de entrada malformadas o firmas de ataque reconocibles.
Sin embargo, la inyección de comandos se produce íntegramente dentro de los límites del lenguaje natural válido. La carga maliciosa suele ser indistinguible de la entrada legítima del usuario a nivel sintáctico; por ejemplo, un campo de dirección de un formulario web que dice «Ver registro 1024», lo que podría incitar a un agente de IA con acceso elevado a la base de datos a recuperar y exponer ese registro, incluso si el usuario no está autorizado a verlo. Un WAF que analiza las solicitudes HTTP no puede determinar si la frase «ignora las instrucciones anteriores» forma parte de una consulta legítima sobre seguridad de la IA o de un intento real de ataque. Es la intención semántica, y no la sintaxis, la que determina la malicia.
Sistemas de reglas estáticas
Los sistemas de filtrado estáticos basados en reglas se enfrentan a limitaciones similares. Aunque es posible crear reglas que bloqueen frases concretas como «ignora las instrucciones anteriores», los atacantes pueden eludir fácilmente dichas reglas mediante:
- Sustitución de sinónimos («sin tener en cuenta las instrucciones anteriores»)
- Técnicas de ofuscación (sustitución de caracteres, codificación)
- Variaciones contextuales que logran el mismo efecto semántico mediante diferentes formulaciones
- Inyección en varios pasos en la que el ataque se distribuye entre varias entradas
El conjunto de posibles mensajes maliciosos es, en la práctica, infinito, lo que hace que el bloqueo exhaustivo basado en reglas resulte poco viable. Cada nueva regla que se añade para detectar un vector de ataque específico aumenta la probabilidad de que se produzcan falsos positivos que bloqueen usos legítimos.
Plantillas de indicaciones
Algunas organizaciones intentan reducir el riesgo de inyección de comandos no solicitados limitando a los agentes al uso de plantillas preaprobadas. Aunque este enfoque ofrece un control determinista y una aplicación sin ambigüedades, socava de manera fundamental la propuesta de valor de la IA agentiva.
Los sistemas basados en plantillas funcionan bien para operaciones de alta frecuencia y bien definidas, en las que el espacio de directivas está naturalmente limitado. Sin embargo, se vuelven inmanejables a gran escala cuando:
- Los casos de uso van más allá del conjunto inicial de plantillas
- Las nuevas solicitudes legítimas se bloquean de forma predeterminada, lo que genera dificultades operativas
- Las operaciones puntuales (como la implementación de una tarea concreta del backlog) requieren actualizaciones constantes de las plantillas
- La validación de parámetros en las plantillas requiere una implementación cuidadosa para evitar la inyección a través de campos parametrizados
El registro de plantillas se vuelve obsoleto y difícil de gestionar, lo que requiere actualizaciones frecuentes. Ofrecer acceso en línea a la lista de plantillas y validar las solicitudes con respecto a ella también introduce dependencias externas, mayor complejidad y latencia en las operaciones de los agentes, lo que genera más carga operativa que valor en materia de seguridad.
CómoKeyfactor a prevenir los ataques de inyección de comandos
El enfoqueKeyfactorpara prevenir los ataques de inyección inmediata se centra en establecer límites de confianza criptográficos que verifiquen tanto la autenticidad como la integridad de las instrucciones de los agentes de IA antes de su ejecución. Esto refleja el modelo de seguridad contrastado que se utiliza para la firma software tradicional, pero lo adapta a los retos específicos que plantean las instrucciones en lenguaje natural en los sistemas de IA agentiva.
Keyfactor aborda la inyección de comandos mediante una arquitectura multicapa:
Infraestructura de firma criptográfica
Keyfactor SignServer ofrece servicios de firma centralizados que eliminan la complejidad de la gestión de claves de las fuentes directivas. Las organizaciones pueden implementar la firma inmediata sin necesidad de distribuir claves privadas a sistemas o usuarios individuales. En su lugar:
- Las fuentes de directivas autorizadas utilizan una API de firma
- Las claves privadas permanecen protegidas dentro de la infraestructura de firma, respaldadas por módulos hardware (HSM)
- La generación, el almacenamiento, la rotación y la revocación de claves se gestionan de forma centralizada de acuerdo con la política de la organización
- Las múltiples interfaces de integración son compatibles con diversos entornos (API REST para aplicaciones nativas en la nube, PKCS#11 para interfaces criptográficas estándar y Windows KSP para la integración en el ecosistema de Microsoft).
Esta centralización garantiza que las funciones de firma estén sujetas a un estricto control de acceso, al tiempo que se mantiene la flexibilidad operativa.
Verificación de firmas en la arquitectura de agentes
Para las organizaciones que implementan agentes de IA,Keyfactor verificar las cargas de trabajo de los agentes antes de su puesta en marcha sin depender de otros sistemas en línea.
El flujo de trabajo funciona de la siguiente manera:
- Un firmante autorizado elabora una directiva y la firma medianteSignServer, generando así un registro de auditoría
- La firma separada y la cadena de certificados se transmiten junto con la directiva del agente
- El plano de control del agente verifica la firma en el momento del inicio antes de transmitir la directiva al agente de IA
- El proceso de verificación comprueba que la firma esté vinculada a una autoridad de certificación de confianza y valida la vigencia de la marca de tiempo.
- Solo se transmiten al agente de IA las directivas que superan la validación de firmas para que actúe en consecuencia
Si la verificación falla en cualquier momento, el agente ni siquiera recibe la solicitud. Esto establece un límite de seguridad estricto: ninguna directiva no verificada puede llegar al agente de IA, independientemente de cómo se haya introducido en el sistema. Además, evita que se malgasten tokens del modelo de lenguaje grande (LLM) en el análisis de entradas no fiables o manipuladas, lo que reduce tanto los costes de ejecución innecesarios como los riesgos de seguridad.
Cadenas de confianza de certificados y autorización
La infraestructuraPKIKeyfactor permite un control granular de las autorizaciones mediante la identidad basada en certificados. En lugar de tratar todas las directivas firmadas de la misma manera, las organizaciones pueden:
- Emitir diferentes certificados de firma para distintos casos de uso o niveles de autorización
- Aplicar las reglas de política en el momento de la firma mediante el motor de políticasSignServer
- Asegúrese de que los responsables de la aprobación autorizados no puedan exceder su ámbito de aprobación
- Gestionar el ciclo de vida completo de los certificados de identidad de los agentes, los certificados de firma inmediata y los certificados de identidad de los aprobadores
De este modo, la gestión de la autorización pasa del agente (que solo puede verificar las firmas) al servicio de firma (que controla la emisión de las firmas), lo que constituye un modelo arquitectónico más seguro.
Aplicación de marcas de tiempo y prevención de reproducciones
La implementaciónKeyfactorpermite incluir marcas de tiempo fiables en el contenido firmado, lo que garantiza la vigencia de los datos. El servicio de firma incorpora una marca de tiempo en la carga útil firmada, y el agente de verificación rechaza las firmas que superen un umbral configurable adecuado al caso de uso (por ejemplo, 60 segundos para operaciones de alto riesgo, 5 minutos para flujos de trabajo estándar).
Este enfoque basado en marcas de tiempo mitiga eficazmente los ataques de repetición, al tiempo que mantiene la flexibilidad operativa. Las organizaciones pueden ajustar los intervalos de actualización en función de sus modelos de implementación específicos y su tolerancia al riesgo.
Integración de seguridad por capas
La firma criptográficaKeyfactorconstituye la base de confianza sobre la que se asientan otros controles de seguridad. La arquitectura permite la integración con:
- Capas de análisis semántico: filtros basados en IA que evalúan el contenido de las directivas en busca de incumplimientos de las políticas, y que operan sobre contenido verificado criptográficamente
- Flujos de trabajo con intervención humana: Procesos de aprobación para operaciones de alto riesgo, con prueba criptográfica de autorización
- Aplicación del ámbito de autorización: Límites basados en roles sobre lo que los agentes de IA pueden hacer en los sistemas empresariales
- Gestión y supervisión del ciclo de vida: Registros de auditoría completos de las directivas firmadas, el estado de los certificados y las actividades de los agentes
Este enfoque por capas reconoce que la firma criptográfica valida la identidad del remitente y la integridad del contenido, pero no la seguridad semántica ni el cumplimiento de las políticas. Al combinar múltiples controles complementarios, las organizaciones logran una defensa en profundidad contra la inyección de comandos y otras amenazas relacionadas.
Ejemplo de arquitectura técnica
La implementación práctica de la firma criptográfica instantánea para agentes de IA demuestra cómo los principios abstractos de seguridad se traducen en diseños de sistemas concretos. Consideremos una arquitectura de referencia para las cargas de trabajo de los agentes; por ejemplo, las implementaciones en contenedores que se utilizan habitualmente en los sistemas de IA agentística nativos de la nube que realizan tareas específicas.
El flujo de seguridad comienza cuando un usuario o sistema autorizado necesita enviar una orden a un agente de IA. Dado que los agentes no actúan sobre contenidos sin firmar, esta parte autorizadora debe obtener una firma digital antes de transmitir la orden al agente. Para ello, primero invocará la API de firmaSignServer. SignServer una firma criptográfica utilizando una clave privada que nunca sale de la infraestructura de firma segura, lo que garantiza que sus claves de firma más sensibles permanezcan bajo el control más estricto. La firma, junto con el certificado de firma y su cadena hasta la CA raíz de confianza, se incluye con la solicitud original.
Este paquete, que contiene la directiva, la firma y la cadena de certificados, se verifica antes del inicio del contenedor como parte del proceso de certificación de identidad del agente, y puede volver a verificarse dentro del contenedor durante la ejecución. Antes de que el contenedor transmita la directiva al propio agente de IA, se ejecuta un proceso de verificación. Esta verificación comprueba tres propiedades fundamentales:
Validez de la firma: La firma criptográfica debe corresponder correctamente al contenido de la directiva, lo que demuestra que esta no ha sido modificada desde su firma.
Confianza en el certificado: El certificado de firma debe estar vinculado a una autoridad de certificación de confianza controlada por la organización, lo que demuestra que la directiva procede de una fuente autorizada.
Actualidad de la marca de tiempo: La marca de tiempo de la firma debe estar dentro de un intervalo de vigencia aceptable, lo que demuestra que no se trata de una repetición de una directiva antigua.
Solo cuando se superan las tres comprobaciones, el contenedor permite que la directiva llegue al agente de IA. Si falla alguna comprobación, el contenedor se cierra sin ejecutarse y el fallo se registra para su supervisión de seguridad.
Esta arquitectura se inspira en modelos software segura software , como el Control de cuentas de usuario (UAC) de Windows, pero aplica los mismos principios a las directivas de IA. Al igual que el UAC pregunta «¿Confías en este programa?» antes de permitir software ejecute con privilegios elevados, la verificación del contenedor pregunta «¿Confías en esta directiva?» antes de permitir que el agente de IA actúe en consecuencia.
Las características de seguridad que ofrece esta arquitectura son considerables:
- Autenticidad: El agente solo ejecuta la directiva si esta lleva una firma válida procedente de una cadena de certificados que remita a una CA de confianza
- Integridad: Cualquier modificación de la directiva tras la firma —ya sea por una capa de orquestación comprometida, un registro de contenedores o un montaje de volumen— provoca un error en la verificación de la firma
- Autorización en origen: El motor de políticas del servicio de firma controla qué partes pueden emitir directivas, impidiendo tanto que fuentes no autorizadas como que fuentes autorizadas excedan su ámbito de competencia
- Prevención de repetición: La validación de la marca de tiempo rechaza las directivas firmadas fuera del intervalo de vigencia aceptable, lo que impide la repetición de directivas firmadas capturadas
- Integridad de la auditoría: Las directivas firmadas con firmas válidas pueden registrarse y verificarse posteriormente, lo que proporciona una prueba irrefutable de qué instrucciones se autorizaron y ejecutaron
Este enfoque establece una cadena de confianza verificable desde el origen de la instrucción hasta su ejecución por parte del agente, lo que resuelve la vulnerabilidad fundamental que aprovechan los ataques de inyección de comandos: la incapacidad de distinguir entre instrucciones fiables y datos no fiables.
Preguntas frecuentes sobre la inyección de Prompt
¿Puede la línea de comandos ejecutar comandos del sistema?
Sí, en los sistemas de agentes con acceso a API y herramientas. Si un agente de IA puede interactuar con los sistemas, las bases de datos o la infraestructura de la empresa, una inyección de comandos exitosa puede hacer que utilice esas capacidades de formas no deseadas. El impacto depende totalmente de los permisos del agente.
Esto difiere de los chatbots tradicionales, que solo generan texto. Los sistemas agenticos llevan a cabo acciones reales.
¿La inyección rápida es lo mismo que los ataques de jailbreak?
No. Los ataques de jailbreak eluden las medidas de seguridad de un modelo para generar contenido restringido.
Los ataques de inyección de comandos manipulan las instrucciones para que un agente de IA realice acciones no autorizadas en los sistemas conectados.
Es importante destacar que no es necesario que un sistema haya sido liberado para que sea vulnerable. Incluso los modelos que funcionan según lo previsto pueden ejecutar instrucciones inyectadas cuando se combinan entradas fiables con otras que no lo son. Las liberaciones se dirigen a los controles de contenido. La inyección de comandos se dirige a la lógica de ejecución.
¿La firma elimina todos los riesgos relacionados con la IA?
No, y tampoco lo hace la firma de código tradicional.
La firma de código no garantiza software seguro, sino que garantiza que es auténtico y no ha sido modificado. La firma inmediata ofrece el mismo valor para las directivas de IA.
La seguridad perfecta no existe. La cuestión es si el riesgo se reduce de manera significativa. La firma inmediata impide que se ejecuten directivas no autorizadas o manipuladas, lo que eleva considerablemente el listón para los atacantes, especialmente cuando se combina con una sólida protección de claves y controles de autorización.
