Si ya ha desplegado un asistente, un chatbot o un sistema con RAG, esto es lo que un atacante va a intentar contra él. Lo hacemos nosotros primero, con alcance pactado, y le entregamos lo que encontramos antes de que lo encuentre otro.
Por qué un sistema de IA es un objetivo distinto
Un asistente corporativo con acceso a documentación interna concentra dos cosas que a un atacante le interesan mucho: información sensible agregada y una interfaz que acepta instrucciones en lenguaje natural. Las defensas clásicas no cubren eso, porque el ataque no viaja como un exploit sino como una frase.
El escenario que más nos encontramos: un sistema que responde correctamente a todo el mundo, y que con la instrucción adecuada revela documentación que ese usuario no debería poder ver. No hay vulnerabilidad de software: hay un control de acceso que se aplicó al buscador y no al modelo.
Qué probamos
El alcance se ajusta a su despliegue, pero el marco de referencia es el OWASP Top 10 for LLM Applications. Estos son los vectores que trabajamos:
Inyección de prompt directa. Instrucciones del usuario que sobrescriben las reglas del sistema.
Inyección indirecta. Instrucciones escondidas dentro de un documento del corpus o de una web que el sistema consulta, y que se ejecutan sin que nadie las escriba en el chat. Es el vector más subestimado.
Exfiltración a través del RAG. Conseguir que el sistema recupere y muestre documentación fuera del alcance del usuario que pregunta.
Envenenamiento del corpus. Introducir contenido que altere las respuestas futuras de forma sostenida.
Manejo inseguro de las salidas. Lo que ocurre cuando la respuesta del modelo se pasa a un navegador, a una consulta o a un sistema que la ejecuta.
Exceso de agencia. Si el asistente puede invocar herramientas, enviar correo o tocar sistemas, hasta dónde se le puede empujar.
Consumo no acotado. Degradar el servicio o disparar el coste con peticiones diseñadas para ello.
Cadena de suministro del modelo. Procedencia, integridad y versionado de lo que está ejecutando.
Fuga por el propio sistema. Extracción del prompt de sistema, de la configuración o de credenciales incrustadas.
Cómo trabajamos
1
Alcance y reglas
Qué está dentro, qué queda fuera, ventana de pruebas y contactos de emergencia. Por escrito, antes de tocar nada.
2
Reconocimiento
Arquitectura del despliegue, superficie expuesta, modelo y motor en uso, fuentes documentales y permisos declarados.
3
Explotación
Ejecución de los vectores acordados, en caja negra o con conocimiento previo según lo pactado. Documentando cada paso reproducible.
4
Verificación de impacto
No basta con que una técnica funcione: medimos qué se llega a obtener realmente y qué habría supuesto en manos hostiles.
5
Informe y re-test
Hallazgos priorizados con evidencia y corrección concreta. Y una segunda pasada cuando haya aplicado los arreglos.
Qué recibe
Informe ejecutivo para dirección: qué riesgo real hay y qué decisión toca tomar.
Informe técnico con cada hallazgo reproducible paso a paso, su severidad y la corrección propuesta.
Evidencias de lo que se llegó a obtener, tratadas con el mismo cuidado que el material de cualquier pericial.
Re-test incluido para confirmar que lo corregido está efectivamente corregido.
Preguntas frecuentes
¿Sirve si nuestro sistema lo montó otro proveedor?
Sí, y de hecho es el caso más habitual. No necesitamos haberlo desplegado nosotros. Si el proveedor quiere estar presente durante las pruebas, mejor: acorta muchísimo el ciclo de corrección.
¿Y si usamos una herramienta comercial en la nube?
También se puede auditar la parte que está bajo su control: configuración, permisos, qué documentación se ha conectado y cómo se maneja la salida. Lo que no auditamos es la infraestructura del proveedor, que no es suya.
¿Puede romper el sistema en producción?
Las pruebas se acotan para que no lo hagan, y cuando hay riesgo se ejecutan en un entorno espejo o en ventana pactada. Las de consumo no acotado, en particular, no se lanzan contra producción sin autorización expresa por escrito.
¿Cada cuánto hay que repetirla?
Cada vez que cambie el modelo, se conecte una fuente documental nueva o se le den herramientas al asistente. Esos tres cambios alteran la superficie de ataque más de lo que la gente supone. En un sistema estable, una revisión anual y pruebas ligeras periódicas.
Sepa qué se puede sacar de su asistente
Media hora para revisar cómo está montado su sistema de IA, a qué documentación llega y qué alcance de pruebas tendría sentido. Sin compromiso y sin formularios.
Teléfono: 686 250 244 · Correo: info@jaymonsecurity.com
También le puede interesar
