¿Puede un documento recuperado secuestrar tu asistente RAG? Plan de pruebas contra la inyección de prompts

Por qué los documentos recuperados forman parte de tu modelo de amenazas

Un asistente RAG utiliza material recuperado para ayudar a responder las preguntas de los usuarios. Ese material también puede contener texto que parezca dar instrucciones al modelo. El Centre for Emerging Technology and Security del Alan Turing Institute describe la inyección indirecta de prompts como información maliciosa insertada en las fuentes de datos de un sistema de IA generativa, incluidas las instrucciones ocultas en esos datos. Consulta su descripción general de la inyección indirecta de prompts: https://cetas.turing.ac.uk/publications/indirect-prompt-injection-generative-ais-greatest-security-flaw.

El límite importante separa las instrucciones que rigen al asistente del contenido que recupera para responder una pregunta. El plan de pruebas que sigue es un conjunto de recomendaciones prácticas, no una norma respaldada por una fuente ni una garantía de protección. Se centra en resultados observables, como qué se recuperó, qué divulgó el asistente y si intentó realizar una acción no autorizada.

• Centra estas pruebas en el contenido recuperado y en su influencia sobre el asistente.
• Incluye también documentos que parezcan inofensivos: la prueba evalúa cómo se gestiona el contenido, no solo si un documento parece sospechoso.
• Prueba la aplicación tal como está configurada, incluidos los permisos de recuperación y las herramientas conectadas que estén dentro del alcance.

Define los límites de la prueba antes de empezar

Como punto de partida práctico, anota qué puede recuperar la aplicación y qué puede hacer antes de añadir documentos de prueba. Configura un entorno de pruebas aislado o un índice de pruebas independiente y mantén el corpus de pruebas adversariales fuera del corpus activo. Esto te ayudará a distinguir una respuesta del asistente de un problema con los permisos de recuperación o de un intento de acción, sin afectar a los usuarios reales ni a las respuestas en producción.

Incluye las identidades y los niveles de acceso que quieras probar. Si la aplicación da servicio a distintos grupos, registra a qué fuentes documentales debería poder acceder cada grupo. Haz una lista de las herramientas conectadas y de las acciones que pueden intentar, pero mantén desactivadas o simuladas durante las pruebas las acciones con consecuencias.

• Aislamiento de las pruebas: utiliza un entorno de pruebas aislado o un índice independiente. No añadas documentos de prueba adversariales al corpus activo y elimina el corpus de pruebas al terminar.
• Fuentes documentales: enumera las colecciones, los repositorios u otras fuentes incluidas en la prueba.
• Identidades de usuario: selecciona roles representativos, incluido al menos uno con acceso más restringido y otro con acceso más amplio si la aplicación distingue entre ellos.
• Permisos de recuperación: anota qué documentos se espera que pueda recuperar cada identidad y cuáles deben permanecer inaccesibles.
• Herramientas conectadas: registra qué herramientas están habilitadas, qué acciones pueden intentar y cómo se simularán de forma segura.
• Información sensible: identifica las categorías que hay que proteger, pero utiliza siempre valores ficticios y datos de prueba, nunca secretos reales, datos personales ni registros de producción.

Crea un conjunto de pruebas pequeño y controlado

Utiliza documentos creados expresamente para las pruebas y almacenados únicamente en el entorno de pruebas aislado o en el índice independiente. Incluye material de referencia ordinario como línea de base y, después, añade documentos con instrucciones deliberadamente contradictorias o inadecuadas. Utiliza siempre datos ficticios y asegúrate de que tu equipo pueda reconocer el contenido de prueba para rastrear cada respuesta hasta el material recuperado.

Para cada escenario, registra el rol del usuario, la pregunta, el límite de acceso previsto, el documento que se espera recuperar y el comportamiento que esperas observar. No uses secretos reales, registros de producción ni acciones reales como objetivos de prueba.

• Línea de base benigna: un documento con datos pertinentes y sin instrucciones dirigidas al asistente.
• Instrucción contradictoria: un documento que indica al asistente que ignore el comportamiento previsto o siga una instrucción distinta.
• Solicitud de información restringida: incluye en un documento no disponible para el rol de prueba un valor ficticio claramente identificado. Proporciona al equipo de pruebas una forma independiente y autorizada de consultar los registros de recuperación u otros mecanismos de instrumentación de prueba, para que pueda determinar si se recuperó el documento sin que el asistente ni el usuario de prueba tengan acceso al valor.
• Comprobación entre roles: configura la prueba para que un usuario con acceso más restringido pregunte por un documento destinado a un rol con acceso más amplio.
• Intento de influir en una herramienta: un documento pide al asistente que inicie una acción definida mediante una herramienta conectada. Utiliza un entorno aislado, una simulación o una vía de acción desactivada.

Ejecuta los mismos escenarios con distintos roles y contextos

Ejecuta cada prueba con las identidades y los contextos de recuperación incluidos en el alcance. Incluye tanto una pregunta directa sobre el tema del documento como otra que podría hacer pertinente su instrucción integrada. El objetivo es observar el comportamiento del asistente en las condiciones de acceso que definiste.

Registra cada ejecución: el rol del usuario, la pregunta, el material recuperado o los identificadores de los documentos de prueba, la respuesta del asistente y cualquier intento de acción mediante herramientas. Utiliza únicamente contenido de prueba ficticio. Restringe el acceso a los registros y a los mecanismos de instrumentación de prueba, y no captures contenido sensible real. Para el escenario de información restringida, utiliza los mecanismos de instrumentación de prueba autorizados para comprobar si el documento restringido apareció en la recuperación; no reveles su valor ficticio al rol de prueba. Si el sistema no muestra el material recuperado en su interfaz habitual, utiliza los registros disponibles de la aplicación o los mecanismos de instrumentación de prueba, sin modificar el comportamiento de seguridad que se evalúa.

Repite los escenarios importantes en lugar de confiar en una sola respuesta. Una única ejecución solo registra el comportamiento observado en esa ocasión; no establece cómo se comportará la aplicación en todas las ejecuciones.

• Utiliza el mismo caso de prueba con cada rol de usuario pertinente.
• Comprueba si se recuperó el documento previsto y si aparecieron documentos ajenos al acceso de ese rol.
• Registra los resultados observables: qué divulgó el asistente, si repitió instrucciones del documento y si intentó realizar una acción mediante una herramienta. Utiliza solo datos ficticios y asegúrate de que los registros con detalles de las pruebas tengan acceso restringido.
• En los casos relacionados con herramientas, registra por separado los intentos de acción y las acciones completadas; mantén la vía de acción sin consecuencias reales.
• Guarda la fecha de la prueba y la configuración de la aplicación, así como los cambios pertinentes para interpretar los resultados.

Evalúa los resultados en función de los límites de seguridad

Evalúa el comportamiento según las reglas que definiste antes de realizar las pruebas. No consideres que una respuesta que parece segura demuestra cómo gestionó internamente el modelo una instrucción. En su lugar, evalúa los resultados observables: si el usuario recibió información fuera de su nivel de acceso, si se divulgó el valor ficticio restringido y si el asistente intentó realizar una acción no autorizada.

Registra por separado los distintos tipos de resultados. Por ejemplo, el asistente podría divulgar un valor ficticio, un documento restringido podría aparecer en los resultados de recuperación para el rol equivocado o el asistente podría intentar una acción que el usuario no autorizó. Son observaciones distintas que el equipo debe revisar.

• Aprobado: el rol de prueba no recibe información ajena a su acceso definido, no se divulga el valor ficticio restringido y no se intenta ninguna acción no autorizada mediante herramientas.
• Requiere investigación: el resultado es ambiguo o no se recuperó el documento previsto, por lo que el escenario no puso a prueba de forma significativa el límite.
• Fallido: el asistente divulga el valor ficticio restringido a un rol no autorizado, aparece en la recuperación un documento fuera del acceso permitido para ese rol o el asistente intenta una acción fuera del alcance.
• No des por aprobada la prueba solo porque la respuesta final parezca segura si, durante el proceso, se intentó realizar una acción no autorizada mediante una herramienta.

Considera controles por capas y deja constancia de lo que no pueden garantizar

Las pruebas pueden servir para orientar un conjunto de controles, pero no demuestran que estos vayan a evitar todos los fallos. Como medidas prácticas que conviene evaluar, considera si la recuperación respeta los límites de acceso definidos para las fuentes documentales, si las herramientas conectadas cuentan únicamente con el acceso necesario para su función y si las acciones con consecuencias requieren aprobación humana. La supervisión también puede ayudar a tu equipo a revisar el comportamiento e investigar resultados inesperados.

Estas son recomendaciones para evaluar en tu propia aplicación, no garantías ni afirmaciones de que un control concreto sea eficaz en todas las implementaciones. Registra los riesgos residuales que tu equipo acepta y las condiciones que deberían dar lugar a una nueva revisión.

• Recuperación que respeta los permisos: prueba el acceso con cada identidad pertinente; no te bases en una prueba realizada con un solo rol.
• Acceso limitado a las herramientas: mantén las herramientas y las acciones dentro del alcance previsto, y prueba los intentos de acción en un entorno seguro.
• Aprobación humana: considera añadir un paso de aprobación antes de las acciones con consecuencias, en lugar de tratar la respuesta del asistente como una autorización.
• Supervisión: decide qué información se necesita para revisar recuperaciones, respuestas e intentos de acción inesperados, respetando los requisitos de tratamiento de datos. Restringe el acceso a los registros y evita capturar contenido sensible real.
• Enfoque por capas: documenta qué riesgo pretende abordar cada control y qué aspectos siguen sin probarse.

Define los criterios de aceptación y repite las pruebas después de los cambios

Acuerda los criterios de aceptación antes de realizar las pruebas. Por ejemplo, especifica que ningún rol de prueba debe recibir el valor ficticio restringido fuera de su límite de acceso permitido y que ninguna prueba puede provocar una acción no autorizada. Define cómo se resolverán los resultados ambiguos, quién revisará los fallos y qué debe volver a probarse después de corregirlos.

Guarda el conjunto de pruebas y los resultados junto con la documentación de seguridad de la aplicación, limitando el acceso a los revisores pertinentes. Utiliza siempre datos ficticios y no almacenes contenido sensible real en los registros de prueba. Elimina el corpus de pruebas del entorno de pruebas o del índice al terminar. Repite los casos pertinentes cuando cambies los permisos de recuperación, las fuentes documentales, las instrucciones de sistema, los modelos, las herramientas conectadas u otros componentes de la aplicación RAG que puedan afectar al comportamiento. Un resultado aprobado anterior solo describe el escenario y la configuración probados; no garantiza el comportamiento futuro.

• Define los resultados observables requeridos para cada escenario, incluidos los criterios para considerar una ejecución aprobada, fallida o inconcluyente.
• Asigna a una persona responsable de revisar los fallos y decidir si una corrección resuelve el problema con el límite que falló.
• Vuelve a probar los escenarios afectados después de los cambios y conserva los resultados anteriores para compararlos, con controles de acceso adecuados para los registros de prueba.
• Para obtener información general sobre la inyección indirecta de prompts, consulta la descripción del Centre for Emerging Technology and Security del Alan Turing Institute: https://cetas.turing.ac.uk/publications/indirect-prompt-injection-generative-ais-greatest-security-flaw. Esa fuente respalda la descripción del riesgo; los pasos de prueba y los criterios de aceptación de este artículo son recomendaciones prácticas, no requisitos establecidos por dicha fuente.