Estás construyendo un agente LLM que puede llamar a herramientas (correo, BD). La entrada del usuario podría contener instrucciones ocultas. ¿Cómo reduces el riesgo de inyección de prompts?
Respuesta breve
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.
Un LLM mezcla instrucciones y datos en el mismo flujo de texto, así que cualquier contenido controlado por el atacante — escrito directamente o extraído de un correo, documento o página web que el agente lee — puede portar instrucciones que el modelo podría seguir. Eso es inyección de prompts, y en cuanto el modelo puede llamar a herramientas (enviar correo, consultar o modificar una base de datos), una inyección exitosa se convierte en una acción real. No se puede contrarrestar de forma fiable con el prompt.
Por qué «solo dile que ignore» falla
El modelo no tiene una frontera robusta entre tu prompt del sistema y el texto inyectado; ambos son solo tokens. Una línea que diga «ignora las instrucciones maliciosas» es a su vez susceptible de ser anulada por una inyección hábilmente redactada. Defender en la capa del texto es luchar en el terreno del atacante.
La arquitectura que sí reduce el riesgo
- Tratar toda salida del modelo como entrada no confiable para el resto de tu sistema. Valida, comprueba tipos y acota los argumentos de las herramientas antes de ejecutar.
- Mínimo privilegio por herramienta. Limita cada herramienta a los datos y capacidades mínimos, con credenciales efímeras y de alcance estrecho — no un token de administrador amplio.
- Validación humana para acciones sensibles o irreversibles: enviar correo externo, borrar registros, mover dinero.
- Aislar y restringir la ejecución y la salida de red para limitar la exfiltración y el SSRF.
Esto corresponde directamente a los riesgos LLM de OWASP: agencia excesiva (demasiada capacidad/autonomía) y gestión inadecuada de salidas (actuar sobre la salida del modelo sin validación).
Por qué fallan las demás opciones
- Aumentar la temperatura solo hace las salidas más aleatorias; no tiene nada que ver con que se obedezca una instrucción inyectada.
- Registrar y esperar anota el incidente una vez hecho el daño — útil para forense, inútil como prevención.
Qué evalúa el entrevistador
Si entiendes que la inyección de prompts es una restricción de diseño, no un fallo que se parchea con la redacción, y si diseñas para reducir el radio de impacto: mínimo privilegio, puntos de confirmación y validación de salidas, de modo que un modelo subvertido aún no pueda causar mucho daño.
Posibles preguntas de seguimiento
- ¿Qué es la inyección de prompts indirecta y por qué es especialmente peligrosa para agentes que usan herramientas?
- ¿Qué llamadas a herramientas pondrías tras una validación humana y cómo lo decides?
- ¿Cómo reduces la «agencia excesiva» de un agente con acceso a correo y base de datos?