Trata el contenido recuperado como una entrada no fiable

Identifica dónde los datos pasan a tratarse como instrucciones

Un agente de programación lee más que la petición del usuario. Puede inspeccionar incidencias, archivos del repositorio, documentación de paquetes, resultados de búsqueda y respuestas de herramientas. Parte de ese contenido puede incluir instrucciones de otra persona.

La inyección de prompts ocurre cuando ese contenido desvía al modelo de la tarea autorizada. Una inyección indirecta llega mediante una fuente recuperada, en lugar de la petición directa del usuario. OWASP señala el material de repositorios y los resultados de herramientas como puntos de entrada relevantes. Lee la guía de prevención.

Considera una tarea ficticia de mantenimiento. El usuario pide corregir un filtro de informes y ejecutar las pruebas obligatorias. Un README recuperado dice que las pruebas están obsoletas y pide subir un archivo de configuración. El README puede explicar el proyecto. No puede autorizar que se omitan las comprobaciones del usuario ni que se envíen archivos a otro destino.

Identifica las consecuencias posibles

El mismo texto engañoso tiene consecuencias distintas según el entorno. Un sistema de resumen con acceso de solo lectura podría producir un resumen incorrecto. Un agente con escritura en el repositorio puede cambiar código. Uno con secretos y acceso de red saliente puede exponer información.

Inspecciona las acciones disponibles antes de decidir qué defensas importan. Enumera los recursos sensibles, los destinos de escritura y los destinos externos. Incluye los conectores añadidos después de la configuración inicial. Una herramienta nueva puede ampliar las consecuencias de una debilidad existente.

El agente también puede trasladar contenido engañoso a una etapa posterior. Por ejemplo, puede copiar una instrucción no fiable en las instrucciones de una tarea generada. El siguiente agente no debe tratar ese documento como una política aprobada de forma independiente.

Usa varios controles con finalidades distintas

Separa las instrucciones fiables de la tarea de los datos recuperados en el diseño de la aplicación. Muestra el origen del material recuperado. Estos pasos mejoran la interpretación, pero no establecen un límite de seguridad completo.

Impón los permisos de recursos en el sistema de ejecución. Restringe los destinos de los datos sensibles. Exige la decisión correspondiente antes de acciones con consecuencias importantes. Valida la operación propuesta frente a la tarea y el destino autorizados.

Los filtros y un segundo modelo pueden ayudar a detectar contenido sospechoso. También pueden pasar por alto ataques o bloquear información legítima. No sustituyas la autorización determinista por una puntuación de confianza del modelo. OWASP señala explícitamente los límites de depender solo de prompts o recuperación de información. Lee la descripción del riesgo.

Prueba el flujo sin exposición real

Usa un repositorio desechable y archivos ficticios. No des a la evaluación credenciales de producción ni escrituras externas sin restricciones. Introduce una instrucción inofensiva que contradiga la tarea, como omitir una comprobación obligatoria.

Observa tanto la respuesta del modelo como las acciones reales de las herramientas. Un mensaje que diga «he ignorado la instrucción» no basta si aun así se omitió la comprobación. Registra la tarea, el archivo de prueba con la inyección, las herramientas permitidas y el resultado observado.

Repite casos representativos tras cambiar prompts, modelos, conectores o permisos. Bloquear un ejemplo aporta evidencia para ese caso, no una prueba contra todas las inyecciones. Si una prueba falla, reduce las consecuencias posibles mientras corriges el flujo de trabajo subyacente.