Contenido del artículo
- En resumen
- Qué se revisa: tabla
- Prompt injection: directa e indirecta
- Fugas de datos por RAG y la base de conocimiento
- Permisos excesivos de los agentes de IA
- Contexto oculto y prompt de sistema
- Manejo inseguro de las respuestas del modelo
- Inicio de sesión, roles y aislamiento de clientes alrededor del LLM
- Abuso de costes y denegación de servicio
- Qué no suele incluir un pentest de una aplicación de IA
- Qué aporta el cliente
- Qué recibes como resultado
- Checklist antes de un pentest de una aplicación de IA
- FAQ
- Referencias
Un pentest de una aplicación de IA comprueba si se puede conseguir que un chatbot, una búsqueda RAG o un agente de IA haga algo que su desarrollador no previó: seguir instrucciones ajenas (prompt injection), mostrar documentos de otro cliente, llamar a una herramienta sin los permisos adecuados, revelar su prompt de sistema oculto o agotar el presupuesto del modelo. La base es el OWASP Top 10 for LLM Applications 2026 (la lista de los diez riesgos principales para aplicaciones basadas en grandes modelos de lenguaje, publicada en agosto de 2026), y el inicio de sesión, los roles y la API alrededor del modelo se prueban como en cualquier aplicación web. [1] [7]
Un pentest de aplicación LLM significa una revisión manual de todo el sistema alrededor del modelo: la interfaz de chat, la base de conocimiento, las herramientas del agente, la API y los permisos. Nadie «hackea» el modelo de OpenAI, Anthropic o Google: se revisa qué le deja ver y hacer tu aplicación. Abajo tienes una tabla de riesgos, una explicación de cada uno, qué darle al equipo de pruebas y qué recibes. El formato general del trabajo está en la página de pentest.
En resumen
- La edición actual de la lista de OWASP para LLM salió en agosto de 2026 y sustituyó a la edición de 2025. Pregunta al proveedor con qué edición trabaja. [1] [2] [3]
- La prompt injection sigue siendo el riesgo número uno, y OWASP dice claramente que hoy no existe una forma fiable de evitarla por completo. Por eso la prueba no solo revisa los filtros, sino qué pasa cuando alguien los salta. [1]
- Lo que más sube en la edición de 2026 es Excessive Agency, del sexto al tercer puesto. Cuantas más herramientas y permisos tiene el modelo, más cuesta un error. [1]
- Del cliente se necesitan cuentas de prueba para cada rol, una descripción de las herramientas del agente, documentos de prueba para la base de conocimiento y un límite de gasto para la prueba.
- El resultado: un informe con escenarios de ataque reproducidos, impacto en el negocio y orden de corrección, y un retest tras las correcciones si se acordó.
Qué se revisa: tabla
| Qué se revisa | Ejemplo de riesgo | Por qué importa al negocio |
|---|---|---|
| Prompt injection directa (LLM01) | Un usuario le dice al bot «olvida tus reglas» y obtiene un descuento que no existe o una declaración en nombre de la empresa que nunca debió publicarse | El bot no promete ni hace nada fuera de su papel |
| Prompt injection indirecta (LLM01) | Una instrucción oculta en un CV, un correo o una web hace que el agente reenvíe datos a una dirección externa al leer el documento | El texto ajeno que lee el modelo no controla tu sistema |
| Fugas de datos por RAG (LLM02, LLM09) | Una pregunta del cliente A trae el contrato del cliente B porque la base de conocimiento es común y no revisa permisos | El modelo solo ve los documentos que ese usuario puede ver |
| Permisos excesivos del agente (LLM03) | Un bot de soporte puede ejecutar «devolver dinero» sin límite ni aprobación humana | Un error o engaño del modelo no se convierte en una acción real con dinero o datos |
| Contexto oculto y prompt de sistema (LLM08) | El prompt de sistema contiene una clave de API, reglas internas de descuentos o la lista de herramientas, y el bot las repite | Revelar el prompt no le da nada útil a un atacante |
| Manejo inseguro de la salida (LLM10) | La respuesta del modelo se inserta en una página como código y se ejecuta un script en el navegador de un empleado | Lo que genera el modelo no se ejecuta sin control |
| Inicio de sesión, roles y aislamiento de clientes | Cambiar el ID de la conversación en una petición a la API muestra el chat de otra persona | Un cliente no ve los datos de otro, como en cualquier SaaS |
| Costes y denegación de servicio (LLM06) | Sin límites, una cuenta lanza miles de peticiones largas y la factura del modelo se multiplica | Ni facturas sorpresa ni servicio caído |
Los números entre paréntesis siguen la edición de OWASP de 2026. La fila de roles no está en la lista para LLM, se prueba con el OWASP API Security Top 10, pero en las aplicaciones de IA ahí suele esconderse la fuga más sencilla. [7]
Prompt injection: directa e indirecta
La prompt injection ocurre cuando un texto que lee el modelo cambia su comportamiento en contra de lo que quería el desarrollador. La directa la escribe el propio usuario en el chat. La indirecta llega a través de contenido que el modelo lee como parte de su tarea: una web, un correo, un documento, la respuesta de una herramienta, un fragmento de la base de conocimiento. OWASP subraya que las instrucciones pueden ser invisibles para las personas, escondidas en caracteres Unicode, en una imagen o en un audio. [1]
El equipo de pruebas prueba ambos caminos. En la directa, comprueba si puede sacar al bot de su papel, hacer que revele datos internos o que llame a una herramienta. En la indirecta, coloca documentos preparados donde el modelo los leerá: la base de conocimiento, el correo, un ticket de soporte. La pregunta clave no es «se saltó el filtro», sino «qué pasó después». OWASP aconseja diseñar el sistema como si el salto fuera a ocurrir tarde o temprano, y limitar lo que el modelo puede hacer y adónde llegan sus respuestas. [1]
Fugas de datos por RAG y la base de conocimiento
RAG (Retrieval-Augmented Generation) significa que, antes de responder, la aplicación busca fragmentos en tus documentos y los añade a la consulta al modelo. El modelo no sabe quién puede ver cada documento. Si la búsqueda no filtra los resultados por los permisos del usuario, resumirá sin problema el contrato, los salarios o la correspondencia de otro.
Con dos cuentas de clientes o departamentos distintos, el equipo de pruebas comprueba si uno puede llegar a los documentos del otro, con una pregunta directa o con una formulación indirecta. También revisa si se puede colar en la base de conocimiento un documento con instrucciones que luego leerán otros usuarios. OWASP trata las debilidades de las bases vectoriales y de la búsqueda en LLM09 y la divulgación de datos sensibles en LLM02. [1]
Permisos excesivos de los agentes de IA
Un agente de IA es un modelo que no solo responde, sino que llama a herramientas: busca en el CRM, abre tickets, envía correos, ejecuta código. OWASP señala tres causas de fondo: funciones de más, permisos de más y autonomía de más sin aprobación humana. [1]
El equipo de pruebas hace una lista de todas las herramientas del agente y pregunta por cada una: si hace falta, con qué permisos funciona (los del usuario o los de una cuenta de servicio con acceso total), si permite llegar a datos de otro cliente, si hay aprobación para acciones con dinero o borrado. Luego intenta que el agente ejecute esas acciones mediante una inyección. Si el agente tiene memoria a largo plazo y actúa por su cuenta, OWASP recomienda revisarlo también con la lista aparte OWASP Top 10 for Agentic Applications, publicada en diciembre de 2025. [1] [4]
Contexto oculto y prompt de sistema
El prompt de sistema (la instrucción oculta que la aplicación da al modelo antes de la conversación) casi siempre se puede extraer. En la edición de 2026 OWASP cambió el nombre de System Prompt Leakage a Hidden Context Exposure (LLM08) y lo amplió: el contexto oculto incluye también las descripciones de herramientas y las reglas que llegan desde la base de conocimiento. [1]
El equipo de pruebas no mira solo si hay fuga, sino qué se filtra. Claves de API, contraseñas, cadenas de conexión a la base de datos o lógica de acceso en el prompt son un hallazgo grave. La regla de OWASP es sencilla: da por hecho que el contexto oculto se descubrirá, no metas secretos en él y no lo uses como control de seguridad. [1]
Manejo inseguro de las respuestas del modelo
La respuesta del modelo debe tratarse como una entrada no verificada de un usuario anónimo. Si la aplicación la inserta en una página como HTML, en una consulta a la base de datos, en un comando del servidor o en una URL, la inyección en el modelo se convierte en una vulnerabilidad web clásica. En la edición de 2026 este punto (LLM10) abarca también el código inseguro que generan los asistentes de IA. [1]
El equipo de pruebas hace que el modelo genere contenido malicioso y sigue adónde llega: la interfaz del operador, los registros, el panel de administración, un correo al cliente.
Inicio de sesión, roles y aislamiento de clientes alrededor del LLM
Un chatbot suele tener un backend normal: API de conversaciones, historial, subida de archivos, un panel de administración con los ajustes del prompt. Aquí aplican los mismos riesgos que en cualquier aplicación web: acceso a objetos ajenos por su ID, acciones fuera del rol, sesiones débiles. [7] En un SaaS con varios clientes en una misma plataforma, la pregunta principal es si los datos, el historial de chat y la base de conocimiento de un cliente están aislados de los de otro. Más sobre pruebas de API en cómo se revisa la seguridad de una web y una API, y sobre productos multicliente en pentest para una startup SaaS.
Abuso de costes y denegación de servicio
Cada petición al modelo cuesta dinero. OWASP describe Unbounded Consumption (LLM06) como el riesgo de caída del servicio, costes descontrolados y clonación del modelo mediante consultas masivas, y señala que limitar el número de peticiones ya no basta: hacen falta límites de tokens, topes de gasto estrictos y cortes automáticos para los agentes. [1] En la edición de 2026 este punto subió cuatro puestos.
El equipo de pruebas revisa límites por cuenta y por sesión, longitud de la entrada, tamaño de archivos y bucles de llamadas a herramientas. No se lanzan ataques de carga contra producción sin un acuerdo aparte: normalmente basta con demostrar que falta un límite y estimar el coste posible.
Qué no suele incluir un pentest de una aplicación de IA
- El modelo del proveedor (OpenAI, Anthropic, Google, etc.) y su infraestructura: solo se pueden probar con las reglas del propio proveedor.
- El entrenamiento de un modelo propio con datos envenenados (LLM05) y la cadena de suministro de modelos (LLM04), salvo que entrenes o ajustes el modelo tú mismo. Eso es una auditoría de proceso aparte.
- La calidad de las respuestas, los sesgos y los errores factuales (LLM07 Misinformation) como línea propia. El pentest muestra casos en los que una respuesta errónea lleva a una acción peligrosa, pero no sustituye a las pruebas de calidad.
Para un marco más amplio de gestión de riesgos de IA puedes usar el NIST AI Risk Management Framework, y para un catálogo de técnicas de ataque contra sistemas de IA, la base de conocimiento MITRE ATLAS. [5] [6] La edición de OWASP de 2026 relaciona sus puntos con ambos. [2]
Qué aporta el cliente
- Una descripción de la arquitectura: qué modelo y proveedor, qué hay en la base de conocimiento, qué herramientas tiene el agente y con qué permisos.
- Dos cuentas de prueba para cada rol y cada cliente de prueba, para comprobar si uno llega a los datos del otro.
- Un entorno de pruebas con una copia de la base de conocimiento sin datos personales reales, o un conjunto de documentos de prueba.
- El prompt de sistema y la descripción de las herramientas si eliges el formato abierto: la prueba llega más hondo en el mismo tiempo.
- Un límite de gasto del modelo para la prueba y un contacto que pueda detenerla.
- Una autorización escrita con el alcance y la lista de servicios de terceros que la prueba no debe tocar.
La lista completa de pasos está en cómo prepararse para un pentest.
Qué recibes como resultado
- Un resumen breve para la dirección: qué se encontró, qué supone para el negocio, qué corregir primero.
- Hallazgos con las consultas o documentos exactos que reproducen cada ataque, pruebas y una valoración del riesgo vinculada a los puntos de OWASP.
- Recomendaciones para el equipo de desarrollo: qué permisos quitar al agente, dónde poner aprobación humana, qué sacar del prompt, cómo filtrar la búsqueda por permisos.
- Una lista de lo que se revisó y de lo que quedó fuera del alcance.
- Un retest tras las correcciones si está en el contrato. Como las respuestas del modelo varían, los escenarios de ataque se repiten varias veces.
El plazo depende del número de roles, herramientas del agente y fuentes de datos, así que se fija antes de empezar. Si el alcance aún no está claro, empieza por un pentest de los escenarios más arriesgados: acceso a datos de otros clientes y acciones del agente con dinero. Qué hacer después con el informe se explica en qué hacer después de un pentest.
Checklist antes de un pentest de una aplicación de IA
Descargar la lista de preparación (PDF)PDF · A4
FAQ
¿Qué se revisa en un pentest de una aplicación de IA?
La prompt injection, directa y a través de documentos, las fugas de datos por RAG, los permisos de las herramientas del agente, la fuga del prompt de sistema, el manejo de las respuestas del modelo, el inicio de sesión, el aislamiento entre clientes y los límites de gasto. La base es el OWASP Top 10 for LLM Applications 2026, y la API alrededor del modelo se prueba como cualquier aplicación web.
¿Se puede uno proteger por completo de la prompt injection?
No, y OWASP dice claramente que hoy no existe una forma fiable de evitarla. Por eso la protección se construye alrededor del modelo: herramientas con el mínimo de permisos, aprobación humana para acciones importantes, búsqueda filtrada por permisos del usuario y control de las respuestas antes de usarlas.
¿Se prueba el propio modelo de OpenAI u otro proveedor?
No. El modelo y su infraestructura son del proveedor. Se revisa tu aplicación: qué ve el modelo, qué herramientas puede llamar y qué pasa con sus respuestas.
¿En qué se diferencia un pentest de IA de un pentest normal?
A las revisiones habituales de API y roles se suman ataques a través del texto que lee el modelo y revisiones de la base de conocimiento y de los permisos del agente. Las respuestas del modelo varían, así que cada escenario se repite varias veces y se guardan las consultas exactas.
¿Cuándo hay que hacer un pentest de una aplicación de IA?
Antes de abrirla a clientes y tras cambios importantes: una herramienta nueva para el agente, una fuente de datos nueva en la base de conocimiento, el cambio a otro modelo. Un permiso nuevo del agente cambia el riesgo más que cambiar la redacción del prompt.
Referencias
- OWASP Top 10 for LLM Applications 2026 genai.owasp.org
- OWASP GenAI Security Project unveils the 2026 Top 10 for LLM Applications genai.owasp.org
- OWASP Top 10 for LLM Applications 2025 genai.owasp.org
- OWASP Top 10 for Agentic Applications (December 2025) genai.owasp.org
- MITRE ATLAS atlas.mitre.org
- NIST AI Risk Management Framework nist.gov
- OWASP Top 10 API Security Risks 2023 api-security.owasp.org
