Seguridad de LLM: el mapa práctico de la superficie de ataque

La seguridad de LLM es la disciplina de romper y defender aplicaciones cuya frontera de confianza ahora pasa por un modelo de lenguaje. El modelo es un nuevo tipo de confused deputy: lee texto controlado por el atacante desde documentos recuperados, salida de herramientas y entrada del usuario, y luego decide qué tokens son “instrucciones”. El appsec clásico asumía que código y datos eran separables. En un agente conectado a un vector store, una bandeja de correo y una shell tool, no lo son. Ese es el problema completo en una frase, y casi todo hallazgo interesante de seguridad LLM se deriva de él.

Este post es un mapa práctico del territorio, escrito para quien realmente prueba estos sistemas.

La superficie de ataque, en el orden en que la probamos

El checklist de consenso actual es el OWASP Top 10 para aplicaciones LLM 2025. Es una taxonomía útil, pero trátalo como mapa de cobertura, no metodología.

LLM01 Inyección de prompts. Sigue siendo lo principal. La inyección directa es una distracción en engagements modernos; la clase de bug real es la inyección indirecta, formalizada por Greshake et al. en Not What You’ve Signed Up For. El atacante nunca escribe en el chat. Escribe un payload en un documento, página web, invitación de calendario, alt-text de imagen o metadatos de PDF, y espera a que el modelo lo ingiera. Exfiltramos vía llamadas a herramientas o markdown image beacons; pivoteamos vía escrituras de memoria; nos propagamos haciendo que el modelo produzca contenido que reinyecta al ser releído. Si un sistema recupera contenido externo arbitrario, ahí va el presupuesto.

LLM02 Divulgación de información sensible. Prompts de sistema, artefactos de fine-tuning, contenidos de corpus RAG y secretos por tenant. El hallazgo interesante rara vez es “filtré el prompt de sistema” —eso es lo mínimo—. Es filtrado-vía-herramienta: lograr que el modelo llame a search o fetch con el secreto como parámetro de consulta para que aterrice en un log de terceros.

LLM03 Cadena de suministro. Modelos descargados de hubs públicos, adaptadores fusionados sin procedencia, datasets de origen dudoso. La deserialización con pickle en archivos de checkpoint sigue siendo un vector RCE creíble; igual que el envenenamiento de manifiestos de dependencia en herramientas de agente.

LLM04 Envenenamiento de datos y modelo. En tiempo de entrenamiento y de fine-tuning. La mayoría de engagements no ejercerán esto directamente, pero si el objetivo se reentrena con retroalimentación de usuario o ingiere wikis internos por RAG, puedes plantar payloads ahora y cosechar después.

LLM05 Manejo inapropiado de salida. Renderizado markdown de salida del modelo con enlaces activos, HTML o URIs javascript:. Argumentos de llamada a herramienta concatenados en comandos shell. La salida del modelo es entrada no confiable; trátala así en cada sink.

LLM06 Agencia excesiva. Herramientas con permisos excesivos, scopes amplios en conectores, agentes que pueden enviar correos o hacer git push sin confirmación. Aquí es donde una inyección exitosa se convierte en incidente.

LLM07 Filtración del prompt de sistema. Promovido a su propio espacio en 2025 porque los equipos seguían metiendo credenciales y lógica de autorización en system prompts asumiendo opacidad. No son opacos.

LLM08 Debilidades en vectores y embeddings. Filtración entre tenants en almacenes vectoriales compartidos, inversión de embeddings y envenenamiento de recuperación. Si RAG está en alcance, escribe documentos adversarios que puntúen alto en las consultas objetivo.

LLM09 Desinformación. Nombres de paquetes alucinados que atacantes luego publican (slopsquatting), citas legales fabricadas, código confiadamente erróneo. Menos un bug de seguridad y más un habilitador.

LLM10 Consumo sin límites. Inundación de tokens, llamadas recursivas a herramientas, modelo-como-amplificador-DDoS. Barato de probar, frecuentemente omitido.

Los marcos que vale la pena conocer

Tres documentos hacen trabajo real en este espacio. Léelos en este orden.

MITRE ATLAS es lo más cercano a ATT&CK para sistemas de IA. En su versión v5.4.0 cataloga dieciséis tácticas y más de ochenta técnicas específicas de IA/ML, con casos de estudio sacados de incidentes reales. Para reportes de red team, mapear hallazgos a IDs de técnica ATLAS le da al blue team un vocabulario sobre el que pueden actuar.

El NIST AI Risk Management Framework, Generative AI Profile (NIST AI 600-1) es la contraparte del lado de gobierno. Enumera doce riesgos únicos o amplificados por IA generativa y los mapea a acciones sugeridas en las funciones Govern, Map, Measure, Manage. Si tu cliente tiene un CISO que reporta a una junta, este es el documento contra el cual será medida su política de IA.

OWASP, ATLAS y NIST no se alinean perfectamente. ATLAS piensa en tácticas adversarias; OWASP en clases de vulnerabilidad; NIST en riesgo organizacional. Una evaluación completa cita los tres.

Defensas que aguantan bajo engagement

La mayoría de pitches de proveedores de “seguridad LLM” se reducen a uno de cuatro patrones de control. Ordenados por cuántas veces sobreviven contacto con un adversario real:

1. Reducir radio de impacto. Acota las herramientas. Requiere humano-en-el-bucle para cualquier acción irreversible. Ejecuta agentes en sandboxes sin acceso a la red interna. Esta es la única categoría que defiende contra técnicas que nadie ha inventado todavía.
2. Validación de salida en el sink. Quita HTML y markdown image tags antes de renderizar. Valida argumentos de llamada a herramienta contra esquemas estrictos. Reautentica al usuario antes de acciones privilegiadas, sin importar lo que el modelo “decidió”.
3. Filtrado de entrada. Clasificadores, allow-lists para contenido recuperado y fronteras estructurales entre mensajes de sistema, usuario y herramienta. Útil como defensa en profundidad; nunca suficiente solo, porque la inyección es fundamentalmente un problema de solapamiento distribucional entre instrucciones y datos.
4. Detección y observabilidad. Loguea cada llamada a herramienta y cada recuperación. Alerta sobre distribuciones anómalas de argumentos. La ganancia durable es tener trazas suficientemente buenas para reconstruir lo que el agente realmente hizo cuando algo sale mal.

Qué cambia en el playbook de engagement

Tres actualizaciones que vale la pena hacer antes de tu próximo red team de IA. Añade un corpus de inyección indirecta a tu toolkit —una carpeta de documentos, correos y páginas con payloads conocidos como efectivos, listos para plantar—. Incluye sondas de exfiltración vía llamada a herramienta; el modelo no necesita imprimir el secreto si puede buscarlo. Y dedica al menos un día a pruebas de agencia excesiva: enumera cada herramienta, cada scope, cada conector, y pregunta qué permite hacer la peor inyección exitosa. Los defensores que aciertan son los que trataron a su LLM como un usuario parcialmente confiable desde el día uno.