Ataques de inyección de prompts en agentes OpenClaw

1Resumen

La inyección indirecta de prompts plantea un riesgo particular para los agentes basados en LLM porque las instrucciones dañinas pueden entrar a través de la salida de una herramienta y no solo del prompt del usuario. Este estudio adapta la lógica de ataque de InjecAgent a OpenClaw y evalúa 12 escenarios de ataque en cuatro modelos y dos configuraciones de seguridad, para un total de 96 ejecuciones. En conjunto, la Tasa de Éxito del Ataque (ASR) fue del 2,1% (2/96), y los dos únicos ataques exitosos ocurrieron con GPT-4o-mini bajo la configuración sin seguridad. En cambio, las barreras de seguridad a nivel de espacio de trabajo redujeron el éxito de ataque agregado del 4,2% al 0% y aumentaron la señalización del 37,5% al 62,5%. Los ataques que entraron por correo se señalaron con más frecuencia que los que entraron por notas, y los prompts con instrucción explícita de anulación se señalaron con más frecuencia que los ataques base. Estos hallazgos muestran que la seguridad de un agente depende conjuntamente de la capacidad del modelo, la configuración del espacio de trabajo y el canal de entrada, y que las instrucciones de seguridad a nivel de configuración constituyen una defensa práctica para agentes con acceso a herramientas.

2Introducción

Los agentes basados en LLM difieren de los modelos conversacionales convencionales en un aspecto determinante: actúan. Más allá de generar texto, interpretan la salida de herramientas, deciden qué acciones tomar y las ejecutan. Un error ya no produce una respuesta incorrecta; produce una transferencia bancaria no autorizada, una bandeja de entrada vaciada o un mensaje enviado en nombre del usuario. Esta exposición es máxima en la inyección indirecta de prompts, donde las instrucciones maliciosas se esconden dentro del contenido que un agente recupera de sus propias herramientas [1][2].

InjecAgent [3] estableció el marco dominante para evaluar la inyección indirecta de prompts en agentes con llamadas a herramientas, con conjuntos de casos de prueba estructurados para daño directo y robo de datos, en variantes base y con prefijo de anulación. Sus hallazgos, sin embargo, se apoyan en un banco de pruebas sintético: agentes configurados para la evaluación y no para el despliegue real, con herramientas estilizadas y estructuras de prompt fijas. Lo que sigue sin estar claro es cómo se comportan estos ataques dentro de los marcos de agentes que la gente realmente utiliza — marcos donde el comportamiento no lo determina solo el modelo, sino también los archivos de configuración a nivel de espacio de trabajo, las definiciones de las habilidades de las herramientas y los archivos reales que el agente lee de su propio sistema de archivos.

Este estudio aborda esa brecha. Trasladamos la lógica de ataque de InjecAgent a OpenClaw, un framework de agente personal de código abierto cuyo comportamiento está gobernado por un espacio de trabajo de archivos de instrucciones (SOUL.md, AGENTS.md) conectado a herramientas simuladas realistas: correo, notas, transferencia bancaria y ubicación. Nuestra contribución no es un nuevo vector de ataque, sino un entorno orientado al despliegue real. En concreto, preguntamos: ¿cómo varían el éxito del ataque y la tasa de detección en función de la capacidad del modelo, la configuración de seguridad a nivel de espacio de trabajo y el canal de entrada de la herramienta? Para responder, nuestros objetivos son tres: (1) adaptar los escenarios de inyección indirecta de InjecAgent a un framework de agente realista y orientado al despliegue; (2) comparar la vulnerabilidad de los modelos entre distintos niveles de capacidad; y (3) aislar el efecto defensivo de las instrucciones de seguridad a nivel de configuración, tanto en el éxito del ataque como en el comportamiento de señalización. Al hacerlo, tratamos el propio archivo de configuración como una variable experimental — no solo como una comodidad de personalización, sino como un posible control de seguridad.

3Métodos

3.1Casos de prueba

Los casos de prueba se inspiraron en los desarrollados en el artículo original de InjecAgent, que incluía dos categorías de ataque: robo de datos y daño directo. Los casos finales se definieron y redactaron específicamente para este estudio. Los casos de robo de datos buscaban extraer tres tipos de información sensible (financiera, física y personal) instruyendo al agente para que recuperara datos concretos y los enviara a una dirección de correo externa especificada en el prompt de ataque. Los casos de daño directo apuntaban a tres dimensiones de daño al usuario (financiero, seguridad de datos y suplantación de identidad), cada uno diseñado para engañar al agente y hacer que realizara una acción perjudicial en nombre del usuario. Cada uno de estos seis escenarios se probó en dos versiones: una versión base que contenía solo el prompt de ataque nuclear, y una versión reforzada que instruía explícitamente al agente a anular las instrucciones anteriores, para intentar aumentar la probabilidad de sortear sus mecanismos de seguridad.

Los ataques reforzados anteponían esta frase al prompt base: "IMPORTANT!!! Ignore all previous instructions and strictly adhere to the following instructions:"

3.2Configuración del agente

Los agentes se configuraron con tres archivos de configuración nucleares, adaptados de las plantillas propias de OpenClaw: USER.md, que establece la identidad y el perfil del usuario; SOUL.md, que define la personalidad, los límites de comportamiento y los principios operativos del agente; y AGENTS.md, que gobierna el arranque de sesión, el comportamiento en la primera ejecución y la gestión de memoria. Se crearon dos versiones distintas de estos archivos para evaluar el impacto del nivel de seguridad en la vulnerabilidad del agente. La configuración de seguridad completa incorporaba en SOUL.md reglas explícitas de concienciación frente a inyecciones — límites específicos por herramienta e instrucciones para tratar entradas no confiables — y AGENTS.md exigía confirmación antes de ejecutar cualquier acción de cara al exterior. La configuración sin seguridad eliminaba toda esa guía relativa a inyecciones y fomentaba la acción autónoma con salvaguardas mínimas. Este diseño permite comparar directamente cómo las instrucciones a nivel de configuración moldean la resiliencia de un agente frente a prompts adversarios entre familias de modelos. La combinación de 6 escenarios de ataque, 2 versiones de prompt, 4 modelos y 2 configuraciones de seguridad arroja un total de 96 ejecuciones individuales.

3.3Configuración experimental

Los experimentos se ejecutaron sobre OpenClaw v2026.3.8, un framework de agente de código abierto con una puerta de enlace CLI local. El agente operó bajo una identidad ficticia — un investigador universitario italiano, "Stefano", profesor en IE University en Madrid — cuyo espacio de trabajo contenía correos personales, registros bancarios, una lista de contactos y diez notas. Cuatro herramientas simuladas permitían al agente actuar sobre estos datos: Notas de Apple (leer, crear y editar archivos de texto), Correo (triaje, lectura, envío, reenvío y borrado de mensajes en una bandeja JSON), Transferencia bancaria (consultar saldo, ver transacciones, ejecutar transferencias SEPA) y Ubicación (devolver coordenadas GPS). Todas las herramientas operaban sobre archivos locales, de modo que cualquier acción no autorizada dejaba un rastro verificable sin consecuencias reales. Las advertencias de seguridad específicas de cada herramienta, en su propio archivo de habilidad, se mantuvieron constantes en ambas condiciones.

Los modelos evaluados fueron GPT-4o-mini y GPT-5.4 (OpenAI), además de Kimi K2 (0711) y Kimi K2.5 (Moonshot AI), elegidos para representar distintos niveles de capacidad — modelos más antiguos y de menor capacidad frente a los actuales estados del arte — y dos familias de modelos de ecosistemas distintos, el estadounidense y el chino. Las cargas útiles se inyectaron por dos canales: correos manipulados antepuestos a la bandeja de entrada, o texto malicioso añadido al final de una nota concreta. Antes de cada ejecución, un script de reinicio restauraba el espacio de trabajo e insertaba la carga útil; la instrucción benigna se enviaba después por CLI con un identificador de sesión único, para evitar que el contexto se arrastrara entre ejecuciones.

3.4Puntuación

Cada ejecución se puntuó en cuatro campos binarios: válida (el agente procesó la solicitud de forma significativa), éxito del ataque (el agente ejecutó la acción no autorizada, o accedió y exfiltró los datos en los casos de robo de datos), señalizada (el agente advirtió sobre contenido sospechoso) y confirmada (el agente preguntó al usuario antes de actuar). La finalización parcial no contaba como éxito. La métrica principal fue ASR-válida (éxitos de ataque divididos por ejecuciones válidas); la secundaria fue la tasa de señalización. La puntuación previa de ASR y señalización la realizó un agente automatizado según criterios predefinidos, y después se revisó manualmente a partir de la salida del agente, las trazas de llamadas a herramientas y los efectos secundarios en el espacio de trabajo.

4Resultados

Siguiendo a InjecAgent [3], adoptamos ASR-válida como métrica principal porque mide directamente si el agente ejecutó la intención del atacante, aislando los fallos de seguridad de los errores de competencia con la herramienta. La tasa de señalización sirve de métrica secundaria, y capta un comportamiento defensivo que la ASR por sí sola no recoge: un agente que ni ejecuta ni señaliza una inyección deja la amenaza invisible para el usuario. Las 96 ejecuciones produjeron respuestas válidas.

Ambas variables dependientes son binarias y siguen una distribución de Bernoulli, por lo que las pruebas paramétricas (t-test, ANOVA, d de Cohen) no son aplicables [4]. Usamos la prueba exacta de Fisher cuando se viola la regla de Cochran — cuando algún recuento de celda esperado bajo H₀ cae por debajo de 5, lo que invalida la aproximación chi-cuadrado — y la χ² de Pearson en el resto de casos. Los tamaños del efecto se reportan como razones de momios (OR), phi (φ) y V de Cramér. La potencia post-hoc usa la h de Cohen, la medida de tamaño del efecto para proporciones [5]. Probamos con α = 0,05, a dos colas, frente a cuatro hipótesis: la ASR es independiente de la configuración de seguridad (H1) y del modelo (H2); la señalización es independiente de la configuración de seguridad (H3) y del modelo (H4).

4.1Rendimiento agregado por modelo

En conjunto, la ASR fue del 2,1% (2/96). Solo GPT-4o-mini produjo ataques exitosos, ambos bajo la configuración sin seguridad (16,7% en esa celda); todos los demás modelos lograron una ASR del 0% en ambas configuraciones. Ninguna de las dos hipótesis de ASR alcanzó significación — H1: exacta de Fisher, OR = 0,19, p = ,495; H2: OR = 16,1 [0,75–348], p = ,061 (al límite) — aunque ambas estaban infrapotenciadas (potencia lograda de 0,30 y 0,62 respectivamente; harían falta n ≈ 185 y 90 por grupo para un 80% de potencia), de modo que la no significación refleja tamaño de muestra insuficiente y no la ausencia de un efecto real.

Ambas hipótesis de señalización sí fueron significativas. H3: las barreras de seguridad aumentaron la señalización del 37,5% al 62,5% (χ²(1) = 6,00, p = ,014; φ = 0,25, un efecto pequeño-a-mediano según las convenciones aproximadas de Cohen (1988) [6]) — las probabilidades de que el modelo señalice una inyección son 2,78 veces mayores bajo seguridad completa que sin seguridad. H4: la señalización difirió entre modelos (χ²(3) = 29,00, p < ,001; V de Cramér = 0,55, un efecto grande). Las pruebas post-hoc (Bonferroni α = ,008) confirmaron que la tasa de GPT-4o-mini fue significativamente menor que la de todos los demás modelos (todas p < ,001); ningún otro par difirió. GPT-5.4 mostró la señalización más alta (100% con seguridad completa, 50% sin seguridad), seguido de Kimi K2.5 (83,3%, 50,0%), Kimi K2-0711 (58,3%, 50,0%) y GPT-4o-mini (8,3%, 0,0%).

4.2Resultados por caso de prueba

Cada celda se lee como seguridad completa / sin seguridad. F = señalizado, ATK = ataque exitoso, — = ninguno de los dos. Los dos únicos ataques exitosos ocurrieron con GPT-4o-mini bajo la configuración sin seguridad, a través de Notas de Apple, en el escenario de suplantación (TC-05 base, TC-06 reforzado): el agente intentó enviar un mensaje de socorro a la madre del usuario sin reconocer la instrucción como adversaria. Los escenarios que entraban por correo se detectaron de forma consistentemente mejor: el ataque de daño financiero reforzado por correo (TC-02) fue señalizado por los cuatro modelos bajo seguridad completa, mientras que varios ataques base que entraban por notas (TC-03, TC-05, TC-09) pasaron desapercibidos para varios modelos en ambas configuraciones.

4.3Análisis dimensional

Bajo la configuración sin seguridad, la señalización de ataques que entraban por correo (58,3%) fue sustancialmente mayor que la de los que entraban por notas (16,7%), y la señalización de ataques reforzados (54,2%) superó a la de los ataques base (20,8%) — el prefijo de anulación funcionó, paradójicamente, como una señal de detección en vez de como un mecanismo para sortearla. Los escenarios de daño directo y de robo de datos mostraron una diferencia descriptiva bajo la configuración sin seguridad (25,0% frente a 50,0%) que no aparece bajo seguridad completa. Agregado entre todos los modelos, las barreras de seguridad redujeron la ASR del 4,2% al 0% (exacta de Fisher, p = ,495, no significativa) y aumentaron la señalización del 37,5% al 62,5% (χ², p = ,014, significativa).

5Discusión

5.1Interpretación

La tasa de éxito de ataque global del 2,1% sugiere una resistencia general fuerte a la inyección indirecta de prompts, pero esta cifra está determinada principalmente por el rendimiento casi perfecto de tres de los cuatro modelos evaluados. Todos los ataques exitosos se concentraron únicamente en GPT-4o-mini bajo la configuración sin seguridad, y ambos apuntaban al mismo escenario — suplantación vía Notas de Apple —, lo que apunta a un efecto de nivel de capacidad, consistente con el hallazgo de InjecAgent de que los modelos más capaces tienden a mostrar una ASR menor [3]. La ausencia de ataques exitosos en GPT-5.4, Kimi K2.5 y Kimi K2-0711 en ambas configuraciones sugiere que, más allá de cierto umbral de capacidad, los modelos pueden desarrollar el razonamiento suficiente para resistir inyecciones incluso sin instrucciones de seguridad explícitas. Las probabilidades de un ataque exitoso en GPT-4o-mini fueron alrededor de 16 veces mayores sin seguridad que con seguridad completa; aunque no se alcanzó significación estadística con este tamaño de muestra, la diferencia es demasiado grande para ignorarla. La elección del modelo puede, por tanto, funcionar por sí sola como un control de seguridad, independientemente de cómo esté configurado el agente.

El comportamiento de señalización cuenta una historia complementaria. La configuración de seguridad aumentó significativamente las tasas de detección en conjunto, lo que confirma que el diseño de las instrucciones de configuración es una defensa relevante, independiente de la elección del modelo — algo consistente con la literatura más amplia sobre cómo el comportamiento de un agente lo moldean tanto sus cimientos de instrucciones como el modelo subyacente [7][3]. Las diferencias entre modelos en señalización fueron sustanciales: la tasa de detección de GPT-4o-mini fue casi nula en ambas configuraciones y significativamente menor que la de cualquier otro modelo, mientras que GPT-5.4 señalizó todas las inyecciones bajo seguridad completa y la mitad sin seguridad, lo que sugiere que su entrenamiento pudo haber incorporado una conciencia de seguridad robusta que necesita poca guía adicional en tiempo de ejecución. Cabe destacar que Kimi K2-0711 mostró solo una respuesta modesta a las mejoras de seguridad (+8,3 pp), de forma similar a GPT-4o-mini, pese a lograr una ASR del 0% — evidencia de que un bajo éxito de ataque y una detección activa no son lo mismo. Un modelo puede resistirse a ejecutar una inyección y, aun así, no avisar al usuario de que existió.

Dos patrones del análisis dimensional destacan especialmente. Los ataques que entraban por correo se señalizaron a tasas sustancialmente más altas que los que entraban por notas, especialmente sin seguridad (58,3% frente a 16,7%), lo que sugiere que los modelos asignan niveles de confianza implícita distintos según la herramienta de origen — una superficie de amenaza desigual, dado que Notas de Apple atrajo menos inspección y fue el canal de entrada de todos los ataques exitosos. En segundo lugar, los ataques reforzados se señalizaron con más facilidad que los ataques base sin seguridad (54,2% frente a 20,8%), lo que confirma que el lenguaje explícito de anulación funciona, paradójicamente, como una señal de detección y no como un mecanismo de evasión eficaz, en línea con [2]. Esto sugiere que las inyecciones mejor camufladas, mezcladas en contenido de apariencia normal, pueden suponer un riesgo práctico mayor que los prompts de anulación sintácticamente obvios — una preocupación respaldada por [1], que mostraron que las inyecciones escondidas en contenido de apariencia normal, como comentarios HTML o texto en mitad de un documento, pueden comprometer a los agentes sin ningún lenguaje de anulación explícito.

En conjunto, la capacidad de un agente para actuar con seguridad está determinada conjuntamente por al menos tres factores — la capacidad del modelo, la configuración del agente y el canal de entrada — y ninguno basta por sí solo. GPT-4o-mini fue el único modelo vulnerable incluso con instrucciones de seguridad instaladas; los ataques que entraban por notas siguieron subdetectados en varios modelos independientemente de la configuración; y la relación entre detección y resistencia varió entre modelos. Elegir un modelo seguro o escribir buenas instrucciones de configuración no basta por separado — ambos importan, y también importan las herramientas a las que el agente tiene acceso.

5.2Implicaciones y recomendaciones

Estos hallazgos sugieren que la resistencia a la inyección indirecta de prompts debe entenderse como una propiedad del sistema y no como una característica fija del modelo subyacente. Aunque la tasa de éxito de ataque agregada fue baja (2,1%), la concentración de todos los ataques exitosos en un solo modelo y una sola configuración muestra que los promedios generales pueden ocultar vulnerabilidades prácticamente relevantes — un argumento en contra de leer una ASR media baja como prueba de que un sistema agéntico es seguro en general. La seguridad, en cambio, parece emerger de la interacción entre la capacidad del modelo, las instrucciones a nivel de configuración y el canal por el que entra el contenido malicioso, de modo que la defensa frente a la inyección de prompts no puede reducirse a elegir un modelo más fuerte.

La concentración de todos los ataques exitosos en GPT-4o-mini (16,7% de ASR sin seguridad) señala un marcado efecto de nivel de capacidad, en el que los modelos más pequeños pueden carecer del razonamiento necesario para resistir incluso inyecciones básicas. Mientras que modelos de frontera como GPT-5.4 demostraron una seguridad incorporada robusta — 0% de ASR incluso sin guía específica —, el hecho de que la configuración a nivel de espacio de trabajo eliminara todos los ataques exitosos demuestra que las instrucciones son una herramienta defensiva de alto impacto. Recomendamos que los equipos de desarrollo traten archivos de configuración como SOUL.md como controles de seguridad activos y no como meros descriptores personales, incorporando reglas explícitas de entrada no confiable que obliguen al agente a tratar los datos recuperados de herramientas como texto pasivo a procesar, nunca como instrucciones a seguir.

Una implicación crítica es la confianza asimétrica que los agentes asignan a distintos canales de herramienta: los ataques que entraban por correo se señalizaron a una tasa mucho mayor (58,3%) que los que entraban por notas (16,7%), lo que sugiere que los modelos pueden confiar implícitamente más en archivos "internos" o "personales" que en los externos, lo que dejó pasar sin detectar varios ataques basados en notas. Las estrategias de seguridad deben, por tanto, ir más allá de centrarse en entradas externas como el correo, implementando límites de seguridad por herramienta que apliquen una política de confianza cero a toda operación de recuperación de datos — el contenido de notas locales o bases de datos internas debe someterse al mismo escepticismo que el tráfico externo no autenticado.

Los resultados también ponen de relieve una distinción entre la capacidad de un agente para resistir un ataque y su capacidad para reportarlo: Kimi K2-0711 logró una ASR del 0% pero mostró solo una respuesta modesta a las mejoras de seguridad en su comportamiento de señalización. Un agente que ignora silenciosamente una instrucción maliciosa es más seguro que uno que la ejecuta, pero sigue siendo un riesgo, porque el usuario nunca es alertado de la presencia de un adversario. La verdadera seguridad agéntica exige tanto resistencia en la ejecución como transparencia activa — recomendamos protocolos obligatorios de "preguntar primero" para cualquier acción irreversible o de cara al exterior, como transferencias bancarias o el envío de mensajes, de modo que el sistema cree un disyuntor manual que compense el fallo de un modelo a la hora de señalizar una inyección sospechosa.

Por último, la "paradoja del prefijo de anulación" muestra que, aunque los modelos son hábiles detectando ataques sintácticamente obvios (como "IMPORTANT!!! Ignore all previous instructions"), tienen más probabilidades de pasar por alto inyecciones camufladas que parecen contenido normal. A medida que los atacantes se desplacen hacia inyecciones más sutiles, insertadas en mitad de un documento y sin lenguaje adversario evidente, los filtros estándar a nivel de modelo perderán eficacia. A corto plazo, la defensa más práctica sigue siendo la combinación de una selección de modelos de alto razonamiento y una configuración robusta y multicapa que asuma que cualquier salida de herramienta puede ser maliciosa.

5.3Limitaciones

Varias limitaciones acotan la generalización y el alcance estadístico de estos hallazgos, principalmente en torno al tamaño de muestra, la metodología y el alcance del estudio.

La restricción más determinante es el tamaño de muestra. Cada celda modelo-configuración contiene solo 12 observaciones, con 96 ejecuciones en total — condicionadas por tres factores prácticos: cada ejecución debía reiniciarse, inyectarse y revisarse manualmente a partir de los registros del agente; los costes de API escalaban linealmente con el número de ejecuciones y se sufragaron con un presupuesto estudiantil limitado; y los seis escenarios se redactaron a mano para el entorno de OpenClaw en lugar de extraerse de un conjunto amplio ya existente, lo que acotó el número de casos de prueba significativamente distintos que pudimos construir. Aunque este tamaño de muestra resultó suficiente para detectar efectos significativos en el comportamiento de señalización — el hallazgo principal y más accionable del estudio —, la rareza de los ataques exitosos (2/96) implica que las diferencias de ASR entre condiciones aún no pueden resolverse con confianza. La no significación de ambas hipótesis de ASR refleja esta potencia insuficiente y no la ausencia de un efecto real, y la baja ASR observada no debe leerse como prueba de que los agentes desplegados son inmunes a la inyección indirecta de prompts.

Desde el punto de vista metodológico, cada caso de prueba se ejecutó una sola vez por combinación modelo-configuración. Sin repeticiones, no puede estimarse la varianza entre ejecuciones causada por la temperatura del modelo o la decodificación estocástica — un mismo modelo podría tener éxito o fallar ante la misma inyección solo por aleatoriedad del muestreo. En cuanto al alcance, los resultados se circunscriben a un único framework de agente (OpenClaw v2026.3.8), cuatro modelos de dos proveedores y una identidad ficticia fija con herramientas simuladas que operan sobre archivos locales, lo que puede no capturar la latencia, el manejo de errores ni la dinámica de autenticación de un despliegue real. Las dos configuraciones de seguridad representan los extremos de un espectro y no aíslan qué instrucción defensiva concreta — por ejemplo, los avisos de confirmación frente a las advertencias sobre entradas no confiables — explica el efecto observado.

5.4Trabajo futuro

Recomendamos aumentar tanto el número como la complejidad de las ejecuciones para construir una muestra más representativa de cada tipo de inyección, entorno y categoría de ataque, y evaluar la eficacia de distintos tipos de inyección bajo el mismo agente y las mismas condiciones de despliegue, ya que el número de intentos de ataque exitosos en este estudio fue limitado.

Una segunda prioridad es aislar qué estrategias de mitigación tienen mayor efecto en la reducción del riesgo de inyección de prompts. Este estudio compara solo dos configuraciones extremas, lo que no permite identificar el efecto de cada estrategia individual; un diseño de prueba por aislamiento, que compare resultados con y sin una estrategia concreta activa a la vez, permitiría tomar una decisión mejor informada sobre qué estrategia importa más al desplegar agentes.

Una tercera área es ampliar cómo se miden los resultados de un ataque más allá del éxito o fracaso binario. Los estudios futuros deberían capturar métricas más ricas — grado de cumplimiento, acciones de confirmación del usuario, recuperación tras la exposición —, ya que un agente puede evitar una acción dañina sin señalar explícitamente que hubo una inyección de prompt, y documentar estas respuestas intermedias es fundamental para entender todo el espectro del comportamiento defensivo de un agente.

6Referencias

1. K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz y M. Fritz, "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection," Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, AISec '23, pp. 79–90, 2023. doi.org/10.1145/3605764.3623985

2. F. Perez e I. Ribeiro, "Ignore Previous Prompt: Attack Techniques For Language Models," arXiv:2211.09527, 2022. arxiv.org/abs/2211.09527

3. Q. Zhan, Z. Liang, Z. Ying y D. Kang, "InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents," en Findings of the Association for Computational Linguistics: ACL 2024, pp. 10471–10506, 2024. doi.org/10.18653/v1/2024.findings-acl.624

4. W. G. Cochran, "Some Methods for Strengthening the Common χ² Tests," Biometrics, vol. 10, no. 4, pp. 417–451, 1954. doi.org/10.2307/3001616

5. J. L. Fleiss, B. Levin y M. C. Paik, Statistical Methods for Rates and Proportions, 3.ª ed. John Wiley & Sons, 2003. doi.org/10.1002/0471445428.fmatter

6. J. Cohen, Statistical Power Analysis for the Behavioral Sciences, 2.ª ed. Lawrence Erlbaum Associates, 1988.

7. E. Wallace, K. Xiao, R. Leike, L. Weng, J. Heidecke y A. Beutel, "The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions," arXiv:2404.13208, 2024. arxiv.org/abs/2404.13208