Preguntas de entrevista de AI & LLM Security

La autonomía sin límites más el acceso a herramientas es la «agencia excesiva» de OWASP LLM: un modelo manipulado o equivocado puede tomar acciones destructivas. Acótalo con herramientas de mínimo privilegio, exige confirmación humana para operaciones irreversibles, y mantén los permisos estrechos y auditados. Confiar en él o darle admin amplía el radio de impacto, y ocultar un botón en la interfaz no hace nada respecto a la capacidad subyacente del modelo de invocar la acción.

El contenido no confiable que el modelo ingiere puede llevar instrucciones — es la inyección de prompts indirecta. No puedes evitar del todo que el modelo sea influido, así que aísla el contenido recuperado como dato, acota qué herramientas/permisos tiene el agente, exige confirmación para acciones sensibles, y evita darle secretos que pudiera ser coaccionado a filtrar. Suponer que el modelo simplemente ignorará las instrucciones inyectadas es exactamente el modo de fallo que se explota.

Un modelo de terceros es una dependencia de cadena de suministro: verifica que provenga de una fuente de confianza con sumas de verificación/firmas coincidentes, que su licencia permita tu uso, y que el formato de archivo no ejecute código arbitrario al cargarse (prefiere serialización segura frente a formatos tipo pickle). «Se carga» y «velocidad de descarga» no dicen nada sobre la confianza, y suponer que los modelos públicos son seguros ignora los riesgos reales de envenenamiento y deserialización.

Esto es el «manejo inadecuado de la salida» de OWASP LLM: la salida del modelo, influida por la entrada del usuario, puede convertirse en inyección de comandos al pasarla a un shell o a eval. Trátala como no confiable — asigna intenciones a una pequeña lista blanca de acciones parametrizadas, valida estrictamente y ejecuta en un entorno aislado en vez de lanzar cadenas generadas en bruto. Confiar en la salida, subir el límite de tokens o solo registrar no detiene la inyección.

Enviar PII de clientes a una API externa la expone al procesamiento y la retención de un tercero y puede incumplir obligaciones de privacidad. Minimiza y redacta lo que se envía, confirma los términos de uso/retención del proveedor y un acuerdo de procesamiento de datos (o garantías de no entrenamiento), o pasa a un despliegue privado para datos sensibles. La longitud de la clave es irrelevante, y enviar más PII aumenta la exposición.

Si la recuperación extrae cualquier documento indexado sin importar quién pregunta, el modelo expondrá fielmente datos que el usuario no debería ver — es un fallo de autorización, no una alucinación. Aplica los permisos del usuario a nivel de documento en el momento de la recuperación, para que solo los fragmentos autorizados entren en el contexto. Un prompt de sistema más largo es evitable y no implementa control de acceso, la temperatura no tiene relación, y otro modelo tiene la misma brecha.

Entrenar con datos de usuario no verificados permite a un atacante envenenar el modelo — implantando puertas traseras, disparadores o comportamiento sesgado que aflora más tarde. Contrólalo con verificación y filtrado de datos, seguimiento de procedencia, detección de anomalías en el conjunto de datos y evaluación del comportamiento del modelo tras el entrenamiento. «Más datos es mejor» ignora la integridad, y la verdadera preocupación es el envenenamiento, no la velocidad ni el espacio en disco.

La inyección de prompts no se resuelve por completo con más texto; asume que el modelo puede ser subvertido y restringe lo que se le permite HACER. Da a las herramientas el mínimo privilegio, condiciona las acciones de alto impacto a confirmación humana, y valida o aísla las llamadas a herramientas antes de actuar (OWASP LLM «agencia excesiva» y «gestión inadecuada de salidas»). Suplicar en el prompt del sistema es evitable. Una temperatura mayor solo añade aleatoriedad, y solo registrar deja constancia del daño sin impedir la acción inyectada.

La IA ayuda al SOC triando y deduplicando alertas, resumiendo incidentes, enriqueciendo contexto, redactando detecciones y acelerando la incorporación de analistas, reduciendo la fatiga y el tiempo de permanencia. Los riesgos: conclusiones alucinadas o erróneas con seguridad, sesgo de automatización donde los analistas dejan de verificar, prompt injection mediante datos de logs o alertas controlados por el atacante, fuga de datos sensibles a modelos de terceros, y adversarios que usan las mismas herramientas. Mantén un humano en el bucle, verifica las salidas y aísla las entradas no confiables.

La prompt injection directa es cuando un usuario escribe instrucciones adversarias directamente en el prompt para anular el system prompt o las reglas de seguridad. La prompt injection indirecta esconde instrucciones maliciosas dentro de contenido externo que el modelo ingiere después —una página web, un correo, un PDF o un documento RAG—, de modo que el ataque se dispara sin que la víctima lo escriba. La inyección indirecta es el mayor riesgo porque el atacante y la víctima son personas distintas, y la carga útil llega en datos en los que la app confía implícitamente.

El manejo inseguro de salidas es confiar en lo que el modelo devuelve y pasarlo a un sistema aguas abajo sin validación ni codificación. Como la salida del modelo es influenciable por el atacante, renderizarla como HTML en bruto causa XSS, pasarla a un recuperador de URL causa SSRF, y pasarla a un shell o una consulta SQL causa inyección de comandos o SQL. La solución es tratar la salida del modelo exactamente como entrada de usuario no confiable: codificación de salida sensible al contexto, listas de permitidos, saneamiento y parametrización antes de que llegue a cualquier sink.

Un jailbreak ataca el alineamiento de seguridad del modelo: engaña al modelo para que produzca contenido que el proveedor intentó prohibir, como instrucciones dañinas. La prompt injection ataca la jerarquía de instrucciones de la aplicación: anula el system prompt del desarrollador o secuestra el comportamiento del modelo dentro de una app, a menudo mediante datos no confiables. Los jailbreaks atacan el modelo; la prompt injection ataca el sistema circundante. Se solapan, pero el objetivo y el límite de confianza que cruzan son distintos.

La cadena de suministro de LLM abarca modelos base, variantes fine-tuneadas, datasets, embeddings, plugins, librerías y la plataforma de alojamiento, cada uno un lugar para introducir riesgo. Las amenazas incluyen descargar pesos de modelo manipulados o con backdoor, fine-tunes maliciosos, datasets envenenados o con licencia contaminada, plugins vulnerables o sobreprivilegiados, y repos de modelos con typosquatting. Defensas: obtener modelos de registros de confianza, verificar integridad y procedencia, mantener un AI bill of materials, escanear y fijar dependencias, verificar plugins y aplicar mínimo privilegio a todo lo que el modelo integre.

El NIST AI Risk Management Framework (AI RMF 1.0) es un marco voluntario y basado en el riesgo para gobernar una IA confiable a lo largo de su ciclo de vida. Su núcleo son cuatro funciones: Govern (cultura, política, rendición de cuentas, y atraviesa las demás), Map (contexto e identificación de riesgos), Measure (evaluar y seguir riesgos) y Manage (priorizar y responder). También define características de confiabilidad: válida y fiable, segura, segura y resiliente, responsable y transparente, explicable, con privacidad mejorada y justa. Complementa listas técnicas como el OWASP LLM Top 10 a nivel de programa.

El OWASP Top 10 for LLM Applications es la lista de consenso de los riesgos más críticos al construir con grandes modelos de lenguaje. La edición 2025 cubre prompt injection, divulgación de información sensible, supply chain, envenenamiento de datos y modelo, manejo inseguro de salidas, excessive agency, fuga de system prompt, debilidades de vectores y embeddings, desinformación y consumo no acotado. Existe porque las listas tradicionales de appsec no capturan los modos de fallo propios de los LLM, y da a los equipos un vocabulario común y una checklist para priorizar controles.

La seguridad RAG significa tratar cada documento recuperado como entrada no confiable. Riesgos clave: prompt injection indirecta oculta en el contenido recuperado, envenenamiento de la base de conocimiento o los embeddings, y falta de autorización por usuario, de modo que el modelo devuelve datos a los que el usuario no tiene acceso. Las defensas incluyen control de acceso aplicado en la recuperación, procedencia del contenido y verificación en la ingesta, tratar el texto recuperado como datos y no como instrucciones, validación de salidas, y aislar el almacén de vectores por inquilino.

Un agente LLM convierte texto en acciones mediante herramientas y function calls, así que una prompt injection se convierte en una acción real: el riesgo de excessive agency. Asegúralo dando a cada herramienta el mínimo privilegio y alcance que necesite, validando y acotando los argumentos de las herramientas, exigiendo confirmación humana para acciones sensibles o irreversibles, ejecutando en sandbox, limitando la tasa y presupuestando las llamadas, y registrando cada invocación de herramienta. Nunca dejes que la salida del modelo, influida por datos no confiables, autorice directamente una acción de alto impacto.

Las apps LLM filtran datos de varias formas: el modelo memoriza y regurgita datos sensibles de entrenamiento o fine-tuning, el system prompt (que puede guardar secretos o lógica) se extrae, los documentos RAG recuperados exponen datos que el usuario no debería ver, y el contexto de un usuario o sesión se mezcla con otro. La prevención implica minimización de datos antes del entrenamiento, nunca poner secretos en los prompts, aplicar autorización por usuario en la recuperación, filtrado de salidas y redacción de PII, y aislamiento por inquilino.

El envenenamiento de datos de entrenamiento es cuando un atacante manipula los datos usados para preentrenar, hacer fine-tuning o generar los embeddings de un modelo, de modo que el modelo resultante se comporte de forma maliciosa: incrustando un disparador de backdoor, inyectando sesgo o degradando la precisión. Explota el hecho de que los modelos rastrean y confían en datasets enormes, a menudo de origen web. Las defensas incluyen curar y firmar las fuentes de datos, verificaciones de procedencia e integridad, detección de anomalías en los datos de entrenamiento, versionado de datasets, y limitar quién puede contribuir a los corpus de entrenamiento y RAG.