Saltar al contenido
Curso Desarrollo seguro con IA en Laravel
17/22 IA dentro de la aplicación Inyección de prompts: qué es y cómo proteger las tools de Laravel AI SDK
Tu lectura Quedan 17 min
Lección 17 de 22 · IA dentro de la aplicación

Inyección de prompts: qué es y cómo proteger las tools de Laravel AI SDK

17 min de lectura Laravel 13

Hola, bienvenido. En esta lección vamos a ver qué es la inyección de prompts y a proteger las tools del asistente de invoices frente a ella. La inyección de prompts es un fallo propio de las aplicaciones que usan un modelo de lenguaje. Un texto que el modelo lee cambia lo que hace, porque el modelo no distingue las instrucciones de los datos. En un asistente con tools, ese texto no solo cambia la respuesta. También puede decidir qué tool se llama y con qué argumentos.

Lo vamos a ver sobre nuestro propio asistente, en local y con un texto inofensivo. Después vamos a escribir el test que lo detecta, siguiendo el método de la lección 4, y a aplicar la solución en la tool, que es donde está el control.

Qué es la inyección de prompts

El OWASP Top 10 for LLM Applications 2025 la pone la primera de su lista, como LLM01:2025, y la define así: una vulnerabilidad que aparece cuando los prompts alteran el comportamiento o la respuesta del modelo de formas que no estaban previstas. Distingue 2 tipos. La directa es la que escribe el propio usuario en su mensaje. La indirecta llega dentro de contenido que el modelo procesa, como una web, un documento o un correo, y es la que nos interesa aquí, porque en invoices ese contenido son los datos de las facturas.

¿Por qué pasa? La hoja de OWASP sobre prevención de la inyección de prompts lo explica con una idea sencilla: la mayoría de los modelos procesan las instrucciones y los datos juntos, como texto, sin una separación clara. Cuando GetInvoice le devuelve al modelo una factura, las notas de esa factura entran en el mismo texto que las instrucciones del agente y la pregunta del usuario. Si las notas dicen algo que parece una petición, el modelo puede tomarla como tal.

Con tools, eso tiene consecuencias. La hoja lo llama manipulación de tools: conseguir que el agente llame a una tool con los argumentos que le interesan a otro. Y aquí la pregunta de seguridad es la misma de la lección 6, pero con otro actor: si el modelo le pide a GetInvoice la factura 14, ¿alguien comprueba que es del usuario que está hablando con el asistente?

Hay otra idea de OWASP que marca toda la lección. En la ficha de LLM01 reconoce que, por cómo funcionan los modelos, "it is unclear if there are fool-proof methods of prevention for prompt injection", es decir, que no está claro que exista una forma infalible de evitarla. Por eso el objetivo de esta lección es que, se equivoque o no el modelo, la tool solo le dé lo que el usuario puede ver.

Lo que queda de esta lección
  1. 02La inyección en el asistente de invoices
  2. 03El test: la tool no devuelve la factura de otro usuario
  3. 04La solución: la tool comprueba de quién es la factura
  4. 05El asistente con la solución
Sigue leyendo con tu suscripción El curso completo, con el certificado y el foro con los planes trimestral y anual, está incluido en la suscripción. Ver los planes