Protección de las soluciones de IA generativa

El Proyecto de Seguridad de Aplicaciones Web Abiertas, OWASP, ha publicado la versión 1 de los 10 principales riesgos y vulnerabilidades para los LLM y las aplicaciones de IA generativa. El siguiente diagrama ilustra estas vulnerabilidades en el contexto de una arquitectura de IA agéntica.

1. La inyección de instrucciones ocurre cuando un atacante puede insertar contenido malicioso en las instrucciones de LLM. El contenido puede variar desde instrucciones integradas en una instrucción más amplia hasta hipervínculos a contenido que leerá el LLM (por ejemplo, “Lee y analiza el texto en la siguiente URL”), u otros medios. La inyección de instrucciones puede permitir que un atacante manipule el modelo para que ignore instrucciones o proporcione resultados no deseados o incorrectos.
   
   
2. El manejo inseguro de resultados ocurre cuando los resultados de un LLM no están suficientemente validados para detectar potencial o intención maliciosa. Ejemplos de este tipo de vulnerabilidad son cuando se le pide a un LLM que genere código Javascript que se pasa al navegador del usuario para su ejecución, y la ejecución directa de scripts de shell u otro código de "sistema" generado por un LLM.
   
   
3. El envenenamiento de datos de entrenamiento ocurre cuando un atacante puede modificar o manipular los datos de entrenamiento o configuración de un modelo para introducir vulnerabilidades en él. Por ejemplo, un atacante podría modificar la descripción de un proceso de negocio para permitir transferencias ilimitadas de dinero a una persona específica; o un competidor podría modificar los datos de ajuste fino para que el modelo recomiende sus productos sobre los de la empresa.
   
   
4. El modelo de denegación del servicio ocurre cuando un atacante es capaz de manipular un modelo para consumir una gran cantidad de recursos, lo que resulta en un rendimiento deficiente o que el modelo no esté disponible para otros usuarios. Los ejemplos de denegación de servicio del modelo incluyen el envío repetido de instrucciones que están justo por debajo del tamaño de la ventana de contexto del modelo, consumiendo grandes cantidades de memoria; y enviar instrucciones que hacen que el modelo se expanda y procese recursivamente la ventana de contexto (un bucle sin fin).
   
   
5. Las vulnerabilidades de la cadena de suministro son tanto las vulnerabilidades típicas asociadas al uso de software de terceros que quizá tenga vulnerabilidades desconocidas que pueden ser explotadas por un atacante, como las vulnerabilidades creadas por modelos que utilizan datos no verificados yo de origen colectivo en su proceso de entrenamiento.
   
   
6. La divulgación de información confidencial se produce cuando un modelo revela información confidencial o personal. Esto puede ocurrir como consecuencia de un ataque de inyección de instrucción exitoso, mediante el manejo inseguro de las salidas del sistema empresarial o mediante instrucciones maliciosas que manipulan el modelo para producir resultados confidenciales, por ejemplo, números de tarjetas de crédito válidos.
   
   
7. El diseño de complementos inseguro ocurre cuando las herramientas llamadas directamente por los modelos no están diseñadas de forma segura; p. ej., herramientas que se ejecutan como un usuario administrativo, o herramientas que permiten la inyección de instrucciones a través de sus resultados.
   
   
8. La agencia excesiva se produce cuando un modelo o agente autónomo tiene la capacidad de realizar acciones perjudiciales o no autorizadas en respuesta a resultados inesperados o ambiguos de un LLM.
   
   
9. El exceso de confianza se produce cuando la salida de un modelo no se verifica para su corrección frente a fuentes fácticas o controles de procedimiento. El ejemplo más común de dependencia excesiva es cuando un modelo alucina y el resultado incorrecto se acepta como fáctico, por ejemplo, un chatbot que proporciona una respuesta incorrecta a un cliente sobre la política de devoluciones de un almacén, pero la dependencia excesiva también puede ocurrir con código o imágenes generados por modelos.
   
   
10. El robo de modelo ocurre cuando un atacante es capaz de comprometer, robar físicamente o copiar un modelo, sus pesos o sus parámetros. Una vez en posesión de un modelo, un atacante puede sacar provecho de la valiosa propiedad intelectual incorporada en el modelo, o crear un duplicado del modelo para su propio uso.
     

La siguiente figura aumenta la arquitectura para mostrar la ubicación de los componentes de seguridad para mitigar o proteger contra las vulnerabilidades en Los 10 principales de OWASP.

Se añade un componente de gestión de identidades y accesos (IAM) para proporcionar identidades y roles de usuario sólidos, lo que mitiga el riesgo de robo de modelos al controlar el acceso a las funciones de la aplicación y las API que podrían dar lugar al robo o la divulgación de modelos.

La identificación del agente y el control de acceso (Control de acceso del agente), que funciona de manera similar al usuario privilegiado, se agrega para hacer coincidir los derechos de acceso del agente con las identidades y roles del usuario; protegerse contra la agencia excesiva y las acciones anormales de los agentes como resultado de alucinaciones o instrucciones mal formadas o ambiguas.

Se añaden componentes de monitoreo de IA generativa (Monitoreo de la IA generativa) en toda la arquitectura para proteger contra la inyección de instrucciones, el manejo inseguro de los resultados, la divulgación de datos confidenciales y la dependencia excesiva. Se despliega una combinación de monitoreo de IA generativa y monitoreo tradicional de fugas de datos para proteger contra ataques basados en instrucción/respuesta, por ejemplo, una instrucción inyectada en los resultados de una consulta SQL, así como la divulgación de información confidencial que puede aparecer en los resultados de llamadas a API, consultas de bases de datos y similares.

Los ataques de saturación de datos de entrenamiento se mitigan con la incorporación de herramientas de gestión de configuración y monitoreo, así como un proceso estructurado de control de versiones y lanzamiento en torno al entrenamiento del modelo, ajuste y datos de configuración.

Por último, se agrega un componente integrado de monitoreo de comportamiento y correlación de eventos para identificar posibles vulnerabilidades y ataques a partir de registros de componentes individuales. Se añade un componente de notificación y alerta para informar a los operadores del sistema de posibles problemas, y se añade un componente de coordinación de respuestas para automatizar o coordinar las respuestas automáticas y manuales a los problemas identificados.