Nuestra metodología de auditoría
Cuando los equipos de ciberseguridad de Niji realizan una auditoría de un sistema de información que integra inteligencia artificial, se apoyan en las buenas prácticas publicadas por OWASP, en particular el LLM Top 10, un referencial reconocido dentro de la comunidad de ciberseguridad.
La auditoría se estructura en varios ejes. Primero, un control de las buenas prácticas generales de seguridad del sistema de información: OWASP Top Ten para aplicaciones web, recomendaciones de la ANSSI para las auditorías internas. Después, un análisis específico de la integración de la IA, conforme a las recomendaciones del pliego de condiciones y, en su caso, a la PSSI-IA de CLUSIF. Los auditores buscan las vulnerabilidades y los defectos de diseño propios de estos sistemas (envenenamiento de datos, inversión de modelo, inyección de prompts, deriva, fugas de información) y formulan recomendaciones operativas junto con buenas prácticas de desarrollo.
Lo que sigue es una selección no exhaustiva de vulnerabilidades descubiertas por nuestros auditores en proyectos recientes, a modo de ilustración concreta de los riesgos que tratamos en nuestras auditorías.
Inyección de prompt y exfiltración del contexto del sistema
En una de nuestras auditorías de un asistente conversacional, un simple prompt bastó para forzar al modelo a revelar su contexto de sistema:
El modelo devolvió íntegramente las instrucciones confidenciales del editor: lógica de negocio, restricciones de comportamiento, datos sensibles. Este tipo de vulnerabilidad corresponde al LLM01 – Prompt Injection del LLM Top 10 de OWASP, y ilustra bien los riesgos cuando no existe ningún aislamiento entre las instrucciones de sistema y las entradas del usuario.
Análisis de código fuente mediante agentes especializados y vulnerabilidades MCP
Cuando tenemos acceso al código fuente, agentes de IA vienen a reforzar a los auditores para detectar vulnerabilidades. Este enfoque combinado nos ha permitido, en particular, identificar fallos en integraciones Model Context Protocol (MCP), un protocolo cada vez más extendido para conectar los LLM con herramientas y servicios externos.
Ejecución remota de código (RCE) a través de una herramienta MCP
En una de las plataformas auditadas, esta es la cadena de ataque que reconstruimos:
Al enviar una dirección de correo con el dominio correcto, incluso para una cuenta inexistente, la API de autenticación emitía un token válido sin ninguna verificación por parte del SSO.
Una vez conectados, bastaba con incitar al asistente a usar una herramienta MCP de tratamiento de ficheros, lo que abría una vulnerabilidad de ejecución de comandos en el servidor.
Las protecciones que bloqueaban ciertas palabras clave se eludieron fragmentando las cadenas en tiempo de ejecución, por ejemplo "urllib.re" + "quest" para importar un módulo sin activar las reglas de detección.
El código ejecutado desde el contexto MCP permitía alcanzar una API interna alojada en la red privada, sin ningún token de autenticación entre servicios que bloqueara las llamadas.
Con un simple token de usuario, nuestros auditores recuperaron credenciales MCP, listas de grupos de Active Directory, configuraciones de LLM y system prompts. Con un token de privilegios elevados, el alcance se amplió todavía más: decenas de system prompts con datos internos clasificados (RRHH, finanzas, jurídico, SSI) y la configuración completa de todos los asistentes de la plataforma.
Cinco pasos, cero exploits complejos. Cada uno, por separado, parece menor: una elusión de verificación, una concatenación de cadenas, una ausencia de token entre servicios. Encadenados, abrieron un acceso a datos clasificados de RRHH, finanzas, jurídico y SSI de toda la plataforma.
Lectura de ficheros locales (LFI) a través de un servidor MCP
Un servidor MCP exponía una función que permitía recuperar el contenido de una página web a partir de una URL. El problema venía del comportamiento de la aplicación: en caso de fallo de la petición HTTP, el servidor relanzaba automáticamente el intento mediante un motor de renderizado de páginas (del tipo Playwright). Nuestros auditores explotaron este comportamiento pasando una URL que apuntaba al sistema de ficheros local (file://), lo que bastó para listar y leer ficheros en la máquina que alojaba el MCP, sin ninguna autenticación adicional.
Qué recomendamos
Estas vulnerabilidades se basan en causas bien conocidas. Combinan fallos clásicos de seguridad de aplicaciones (elusión de autenticación, ausencia de aislamiento de red) con puntos ciegos propios de las arquitecturas agénticas: confianza implícita otorgada a las herramientas MCP, ausencia de validación estricta de los esquemas de URL, ausencia de aislamiento entre las instrucciones de sistema y las entradas del usuario.
- Aislar las instrucciones de sistema y las entradas del usuario. Un prompt de usuario nunca debe poder hacer aflorar el contenido del system prompt ni de las instrucciones de negocio.
- Aplicar el principio de mínimo privilegio a los tokens MCP. Un token de usuario no debe abrir el acceso a credenciales, configuraciones o datos compartidos por toda la plataforma.
- Autenticar las llamadas entre servicios. Un pivote desde el contexto de un agente hacia una API interna debe bloquearse mediante un token de servicio, no solo por la posición en la red.
- Validar estrictamente los esquemas y protocolos aceptados como entrada. Una herramienta que recupera una URL solo debe aceptar
http(s), nuncafile://ni un repliegue silencioso hacia un motor de renderizado que eluda los controles.
Nuestra convicción: auditar una IA no es una auditoría de un perímetro aparte, es auditar un sistema de información ampliado con nuevos puntos de entrada. La base (autenticación, aislamiento de red, mínimo privilegio) sigue siendo la primera línea de defensa; los controles específicos de la IA (prompt injection, envenenamiento de datos, deriva) llegan después. Ambas capas son necesarias.
