Protección de las soluciones de IA generativa

El proyecto abierto de seguridad en aplicaciones web (OWASP por sus siglas en inglés), 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 se produce cuando un atacante puede insertar contenido malicioso en las instrucciones de LLM. El contenido puede abarcar indicaciones o instrucciones integradas en una indicación más amplia, hipervínculos a contenido que leerá el LLM (p. ej., "Lee y analiza el texto de 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 outputs indeseables o incorrectos.
   
   
2. El manejo inseguro de los outputs se produce cuando no se validan lo suficiente los resultados de un LLM para detectar posibles intenciones o acciones maliciosas. Algunos ejemplos de esta vulnerabilidad son solicitar a un LLM que genere código JavaScript que se envía al navegador del usuario para su ejecución y la ejecución directa de scripts de shell u otro código "del sistema" generado por un LLM.
   
   
3. El envenenamiento de datos de entrenamiento se produce cuando un atacante es capaz de modificar o manipular los datos de entrenamiento y/o configuración de un modelo para introducir vulnerabilidades en un modelo. Por ejemplo, un atacante podría modificar la descripción de un proceso empresarial para permitir transferencias ilimitadas de dinero a una persona determinada, o un competidor podría alterar los datos de ajuste para que el modelo recomiende sus productos en lugar de los de la empresa.
   
   
4. La denegación de servicio del modelo se produce cuando un atacante es capaz de manipular un modelo para consumir una gran cantidad de recursos, lo que provoca un rendimiento deficiente o que el modelo no esté disponible para otros usuarios. Algunos ejemplos de denegación de servicio en modelos son el envío repetido de instrucciones que apenas superan el tamaño de la ventana de contexto del modelo, lo que consume grandes cantidades de memoria, y el envío de instrucciones que provocan que el modelo amplíe y procese de forma recursiva la ventana de contexto (es decir, que se cree un bucle infinito).
   
   
5. Las vulnerabilidades de la cadena de suministro son tanto las vulnerabilidades típicas asociadas al uso de software de terceros que pueden tener vulnerabilidades desconocidas que un atacante puede aprovechar, como las vulnerabilidades creadas por los modelos que utilizan datos no verificados o de origen colectivo en su proceso de entrenamiento.
   
   
6. La divulgación de información confidencial se produce cuando un modelo divulga información confidencial o personal. Esto puede ocurrir como consecuencia de un ataque de inyección de instrucciones exitoso, mediante el manejo inseguro de las salidas del sistema empresarial o mediante instrucciones maliciosas que manipulan el modelo para producir outputs sensibles, por ejemplo, números de tarjeta de crédito válidos.
   
   
7. El diseño de complementos inseguros ocurre cuando las herramientas llamadas directamente por los modelos no están diseñadas de forma segura, por ejemplo: herramientas que se ejecutan como usuario administrativo, o herramientas que permiten la inyección de instrucciones a través de sus outputs.
   
   
8. Se produce un exceso de autonomía cuando un modelo o agente autónomo tiene la capacidad de llevar a cabo acciones perjudiciales o no autorizadas en respuesta a resultados inesperados o ambiguos de un LLM.
   
   
9. El exceso de confianza se produce cuando no se verifica la corrección del output de un modelo con respecto a fuentes fácticas o controles de procedimiento. El ejemplo más habitual de confianza excesiva se produce cuando un modelo comete un error y se acepta el output incorrecto como cierto. Por ejemplo, un chatbot que da una respuesta incorrecta a un cliente sobre la política de devoluciones de una tienda. La confianza excesiva también puede darse con código o imágenes generados por el modelo.
   
   
10. El robo de modelos se produce 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 aprovechar la valiosa propiedad intelectual incrustada en el modelo o crear un duplicado del modelo para su propio uso.
     

La figura siguiente amplía la arquitectura para mostrar la ubicación de los componentes de seguridad que protejan o mitigen las vulnerabilidades en el Top 10 de OWASP.

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

Se ha añadido el control de identificación y acceso de agentes (Agent Access Control), que funciona de manera similar al de los usuarios con privilegios, y permite hacer coincidir los derechos de acceso de los agentes con las identidades y funciones de los usuarios. De este modo, se evita que los agentes actúen con demasiada autonomía o cometan acciones anómalas como consecuencia de alucinaciones o instrucciones mal formuladas o ambiguas.

Se han incorporado componentes de monitorización de la IA generativa en toda la arquitectura para protegerla contra la inyección de instrucciones, el manejo inseguro de los outputs, la divulgación de datos confidenciales y la dependencia excesiva. Se implementa una combinación de monitorización de IA generativa y la monitorización tradicional de fugas de datos para protegerse contra ataques basados en instrucciones/respuestas, 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 API, consultas de bases de datos y similares.

Los ataques de manipulación de los datos de entrenamiento se mitigan mediante la incorporación de herramientas de gestión de la configuración y de monitorización, así como mediante un proceso estructurado de control de versiones y de lanzamiento en torno al entrenamiento de modelos, el ajuste fino y los datos de configuración.

Por último, se añade un componente de monitorización integrada del comportamiento y correlación de eventos para identificar posibles vulnerabilidades y ataques a partir de los registros de componentes individuales. Se añade un componente de notificación y alerta para notificar a los operadores del sistema los posibles problemas, y un componente de orquestación de respuestas para automatizar y/o coordinar las respuestas manuales y del sistema a los problemas identificados.