Una inyección rápida puede ocultarse en un documento que consulta un asistente: el texto intenta que abandone su tarea o revele información. Trate el contenido recuperado como datos no confiables y limite las acciones que el sistema puede realizar.
Identificar la frontera de la confianza
Una página web, PDF o mensaje recibido no tiene la autoridad para las instrucciones de su aplicación. Un contenido que afirma lo contrario debe seguir siendo una fuente a analizar. OWASP identifica inyección de prompts entre los riesgos de las aplicaciones de modelos de lenguaje. Una simple instrucción que invita al modelo a ignorar los ataques no constituye una separación técnica suficiente.
Reducir las posibles consecuencias
Un asistente de documentos generalmente no necesita poder enviar mensajes, editar archivos o ver todas las carpetas de la empresa. Limite sus herramientas y acceso al perímetro útil. Separe la búsqueda de documentos de la ejecución de una acción. Cuando exista una acción sensible, tenga sus parámetros validados en una interfaz controlada, con reglas externas al texto generado.
Construya un escenario de prueba sin datos confidenciales
Trabaje en un entorno de prueba de aceptación planificada, con un corpus y cuentas de demostración. La prueba no debe pedir una fuga real para demostrar que existe el riesgo. Coloque en un documento ficticio una instrucción que intente desviar la tarea, luego haga una pregunta legítima sobre este documento. El objetivo es observar el comportamiento de toda la aplicación, incluyendo sus herramientas y controles de acceso.
| Contenido ficticio | Comportamiento esperado | Prueba útil |
|---|---|---|
| una instrucción que pide ignorar la pregunta | La solicitud del usuario sigue siendo el alcance del trabajo | Pregunta, respuesta y documentos utilizados |
| una solicitud para enviar un documento a un tercero | No es posible envío no autorizado | Lista de herramientas accesibles y registro de llamadas |
| una solicitud para leer un recurso fuera del perímetro | El control de acceso de la aplicación rechaza la reproducción | Resultado de control independiente del modelo |
| Una salida que parece una acción empresarial | La salida sigue siendo contenido para ser validado | Rastreo que muestra la ausencia de ejecución automática |
losOWASP describe las inyecciones directas e indirectas y recomienda medidas que limiten sus consecuencias. El hecho de que un ensayo no desvíe el modelo no demuestra una protección total. La pregunta crítica sigue siendo: ¿qué podría suceder si se siguiera un próximo intento? La respuesta debe ser impulsada por los permisos y controles de la aplicación.
Comprobar salidas antes de usar
No transmita directamente una respuesta de modelo a un intérprete de comandos o una consulta comercial. Verifique la estructura, los destinos y los permisos en el código de la aplicación. Los enlaces mostrados también deben ser tratados con precaución. La respuesta se puede registrar para el análisis en un entorno adecuado, evitando el mantenimiento innecesario de información confidencial.
Ejemplo ficticio: un documento de soporte
Un archivo de demostración contiene una instrucción que le pide al asistente que revele su configuración. El resultado esperado es una respuesta centrada en la pregunta del usuario, sin divulgación o llamada a la herramienta fuera del perímetro. La prueba debe utilizar datos ficticios en un entorno aislado. Sobre todo, verifique que las protecciones técnicas eviten la fuga incluso si el modelo sigue una instrucción no deseada.
Respuesta separada, propuesta de acción y ejecución
- Para un Asistente para la Primera Documentación, comience sin enviar, eliminar o cambiar la herramienta de negocio. Compruebe que estas funciones realmente faltan en los permisos y no solo están ocultas en la interfaz.
- Cuando una acción sea necesaria, valide en el código su destino, su tipo y los derechos del solicitante. Una cadena producida por el modelo no debe utilizarse directamente como autorización.
- Vea los ajustes importantes en una pantalla de confirmación adecuada. Las instrucciones en la página vista no deberían poder modificar este proceso.
- Compruebe también la presentación de la respuesta: HTML, enlaces y partes propuestas deben seguir las reglas de su aplicación. No haga un texto ejecutable porque proviene de un modelo.
En un ejemplo ficticio de soporte web, el asistente puede explicar cómo solicitar una intervención. Puede preparar un resumen que la persona relee. No es necesario poder enviar todo el archivo técnico o cambiar el acceso al hosting. Esta separación reduce las consecuencias de una respuesta comprometida manteniendo la utilidad del servicio.
El expediente de la prueba de aceptación debe distinguir entre las pruebas realizadas, las protecciones controladas y los riesgos que quedan sin probar. Después de una evolución de las herramientas o derechos, reproduzca los casos en cuestión. Vincule este trabajo a la Preparación de la base documental RAG : El origen y los derechos de los documentos siguen siendo importantes incluso cuando el modelo parece seguir las instrucciones.
Integra la prueba en la prueba de aceptación
Mantenga algunos documentos de prueba que representan intentos directos e indirectos. Reproducirlos después de una evolución del modelo, herramientas o corpus. Tenga en cuenta los comportamientos esperados y los límites residuales en lugar de declarar invulnerable el sistema. Para un primer proyecto, elija un asistente de lectura restringido y consulte el método de Preparación de un sitio web para agentes web.