Cuando una página web intenta dar órdenes a tu agente de IA

Un agente recibe el encargo de comparar proveedores y visita una web. La página contiene información útil, pero también un texto que intenta cambiarle la tarea. El riesgo no es que la página tenga una opinión: es que el sistema trate ese contenido externo como una orden con autoridad.

Esto es una forma de inyección indirecta de prompts. OWASP la distingue de las instrucciones introducidas directamente por quien utiliza el sistema: aquí el mensaje llega a través de un documento, una web u otra fuente que consulta el agente. [OWASP]

Leer una instrucción no es recibir autorización

Para entender el límite, proponemos un ejemplo sencillo. Un asistente que resume una factura debe poder leer una dirección de cobro. Eso no significa que la factura pueda autorizar una transferencia. El documento aporta datos a la tarea; la autorización debe proceder del proceso y de la persona correspondiente.

Este ejemplo es conceptual, no un incidente que hayamos observado. Sirve para separar dos preguntas: qué dice el material y qué tiene permiso para hacer el sistema. Si ambas respuestas proceden del mismo texto externo, la frontera queda mal definida.

La defensa no depende solo del modelo

Anthropic explicó en noviembre de 2025 mejoras de resistencia para agentes de navegador, pero también advirtió que la inyección de prompts seguía siendo un problema abierto. El resultado de una prueba del fabricante no equivale a inmunidad en todos los entornos. [Anthropic]

OWASP plantea defensas como restringir privilegios, separar contenido externo y exigir control humano en operaciones sensibles. No presenta una sola medida como solución completa. La cuestión práctica es reducir lo que puede ocurrir si el modelo interpreta mal un contenido. [OWASP]

En una revisión de diseño, preguntaríamos si el agente que compara precios necesita también enviar correos o modificar datos de clientes. Si no lo necesita, esa capacidad no aporta nada a la tarea concreta. Separar operaciones facilita entender el alcance de un error y decidir dónde revisar el resultado.

Qué conviene observar en una prueba

Un ejercicio útil sería comprobar que el sistema sigue respetando el encargo original cuando los documentos incluyen instrucciones ajenas a la tarea. La prueba debería realizarse con datos ficticios y herramientas sin efectos reales. El objetivo sería observar las fronteras del sistema, no exponer información de clientes.

También habría que registrar qué información ha motivado una acción y quién la ha autorizado. Si aparece una propuesta de envío sin que el usuario la haya solicitado, el proceso debería permitir detectar esa desviación antes de convertirla en una comunicación real.

Nuestra lectura es que un agente útil necesita acceso, pero ese acceso debe corresponder a un trabajo definido. La pregunta decisiva no es solo si sabe navegar. Es si puede leer un entorno que no controla sin dejar que ese entorno decida, por él, qué está autorizado a hacer.