Inyección indirecta de instrucciones: cómo impedir que un documento, correo o web convierta a un asistente conectado en un canal de fuga o de acción indebida

La amenaza: datos que intentan comportarse como órdenes

Una inyección indirecta de instrucciones aparece cuando un asistente incorpora contenido de una fuente que no controla —por ejemplo, un correo, un PDF, una página web, un ticket o el resultado de una herramienta— y ese contenido intenta cambiar su comportamiento. El texto hostil puede pedir que ignore restricciones, que busque secretos, que reenvíe información, que cambie el destinatario de una acción o que use una herramienta distinta de la necesaria. El vector es indirecto porque quien ataca no necesita escribir en el cuadro de conversación: basta con conseguir que el sistema lea el recurso manipulado.

No es lo mismo que una alucinación. Una alucinación es una respuesta incorrecta o no fundamentada; la inyección busca que el sistema siga una instrucción que no debía tener autoridad. Tampoco equivale a una petición mal redactada por un usuario legítimo. La cuestión central es la procedencia y el privilegio: quién puede fijar el objetivo de la tarea, autorizar una capacidad y determinar qué información puede salir del entorno.

El riesgo aumenta cuando el asistente combina recuperación documental, navegación, correo y herramientas con efectos externos. Un asistente puramente informativo puede dar una respuesta desviada; uno conectado puede además enviar un mensaje, consultar datos fuera del alcance previsto, modificar un registro o transmitir información a un destino no autorizado. La publicación de NIST incluye la inyección indirecta dentro de los ataques de inyección y describe escenarios de secuestro de agentes, fuga de datos y contenido malicioso en recursos como documentos o sistemas de recuperación.

La defensa no debe basarse en detectar una lista de frases sospechosas. Un atacante puede reformular, fragmentar, ocultar u ofuscar instrucciones. Más importante aún, incluso una detección perfecta de ciertos patrones no resolvería el problema de diseño: ningún contenido no fiable debería poder adquirir autoridad para cambiar el objetivo, ampliar permisos, elegir un destino externo o modificar una política de divulgación.

Mapa de fronteras: separe control, datos, capacidades y efectos

Antes de seleccionar un modelo o un filtro, dibuje el recorrido completo de una tarea. Distinga las instrucciones de control definidas por la organización, la solicitud explícita del usuario, los datos aportados por este, el contenido obtenido de fuentes internas o externas, las descripciones de herramientas, los secretos y las acciones que producen efectos. Estas categorías pueden estar presentes en una misma conversación, pero no deben confundirse en la decisión de qué puede hacer el sistema.

Las instrucciones de control incluyen la política de seguridad, el propósito del flujo, los requisitos de autorización y las restricciones de salida. La petición del usuario puede concretar una tarea dentro de esos límites. Los documentos, correos, páginas y resultados de herramientas son evidencia o contexto: pueden influir en una respuesta factual, pero no decidir que el sistema deba exportar datos, modificar permisos o contactar con alguien. Una separación conceptual explícita ayuda a que el diseño, los registros y las pruebas apliquen reglas diferentes a cada elemento.

También conviene separar el plan de la ejecución. El modelo puede proponer una acción, pero un componente de política independiente debe comprobar si la herramienta está permitida, qué identidad se utilizará, qué argumentos son válidos, a qué destino se dirige la operación y si se necesita revisión humana. Tratar una llamada de herramienta como una sugerencia verificable, en vez de como una orden ejecutable, reduce la dependencia de que el modelo interprete correctamente la jerarquía en todos los casos.

Esta frontera es especialmente relevante para los resultados de herramientas. Una búsqueda, una API de tickets o una bandeja de correo pueden devolver texto controlado por terceros. Si el asistente vuelve a insertar ese texto como si fuera una orden de alto nivel, el resultado de la herramienta se convierte en una ruta de escalada. El trabajo sobre jerarquía de instrucciones analiza precisamente la ausencia de privilegios entre instrucciones como una causa de ataques de inyección.

Inventario de superficies y relaciones de confianza

El inventario debe abarcar toda entrada que pueda llegar al contexto durante una tarea, no solo la base documental principal. Incluya archivos adjuntos, cuerpos y firmas de correo, invitaciones de calendario, comentarios, tickets, transcripciones, resultados de búsqueda, páginas navegadas, repositorios, bases vectoriales, memorias conversacionales y texto devuelto por conectores. Anote además si el contenido procede de un usuario, un sistema interno, un tercero, una fuente pública o un origen desconocido.

La procedencia no convierte automáticamente una fuente interna en fiable para dar instrucciones. Un ticket interno puede contener texto introducido por un cliente; una wiki puede estar editada por muchas personas; una memoria puede haber conservado una instrucción maliciosa de una sesión anterior. La etiqueta debe reflejar tanto el sistema de procedencia como el nivel de control editorial, el propietario, la fecha de recuperación y el método por el que se incorporó al contexto.

Haga visible el tránsito de datos entre zonas. Por ejemplo, un agente de correo puede leer un mensaje externo, usar un índice interno para contextualizarlo y proponer una respuesta mediante un servicio de envío. En ese recorrido hay al menos tres decisiones distintas: qué texto se muestra al modelo, qué datos internos se consultan y qué información se envía al exterior. Cada decisión necesita restricciones propias; no debe heredarse permiso de una etapa a otra solo porque comparten una conversación.

La documentación de Microsoft trata los correos, documentos, páginas web y complementos como vías de inyección indirecta y plantea controles de flujo de información para distinguir contenido y confianza. Es una orientación útil, pero su adaptación concreta depende de las identidades disponibles, los conectores desplegados y la sensibilidad de los datos en cada organización.

Regla de arquitectura: los datos no conceden capacidades

Una política operativa puede formularse de manera simple: un fragmento no fiable puede ser citado, resumido, comparado o usado como evidencia, pero no puede redefinir el objetivo autorizado ni activar una capacidad por sí mismo. Esto obliga a que las decisiones sobre herramientas se apoyen en una combinación de la intención autenticada del usuario, la política del flujo y los permisos de la identidad que ejecuta la acción. El contenido recuperado solo puede aportar parámetros cuando estos pasen una validación independiente.

Aplique mínimo privilegio por tarea. Un asistente que resume documentos no necesita credenciales para enviar correo. Un borrador de respuesta no necesita permiso para enviarla. Una herramienta que consulta un registro no debería reutilizar una credencial con capacidad de modificarlo. Siempre que la plataforma lo permita, use tokens de corta duración, con ámbito limitado a una operación y emitidos después de comprobar la política. La separación de credenciales reduce las consecuencias si el modelo propone una acción inapropiada.

Restrinja también la exposición de datos. Recupere solo los fragmentos necesarios, limite la cantidad de contexto y elimine campos sensibles que no aporten a la tarea. Si una consulta requiere datos internos y una posterior respuesta se dirige fuera de la organización, introduzca una puerta de salida que evalúe la clasificación de la información, el dominio de destino, el propósito declarado y la autorización aplicable. No permita que un documento sugiera el dominio o buzón al que deben enviarse datos.

Las listas de destinos autorizados pueden ser apropiadas para integraciones de alto riesgo, aunque requieren mantenimiento y no sustituyen la verificación del contenido. En flujos variables, una política de destino puede combinar relaciones organizativas verificadas, reglas de clasificación y confirmación humana. El objetivo es que el destinatario se derive de una fuente de autoridad —por ejemplo, un registro de clientes o una selección explícita del usuario— y no de una frase insertada en un adjunto.

Controles por capa y límites de los controles aparentes

El etiquetado de procedencia debe viajar con el contenido hasta la generación y la ejecución. No basta con añadir una advertencia textual al contexto, porque esa advertencia puede perderse en transformaciones posteriores. Use estructuras de datos que conserven origen, confianza, clasificación y relación con la tarea. A la vez, delimite qué campos de esas estructuras puede leer el modelo y qué campos usa exclusivamente el motor de políticas.

La validación de llamadas a herramientas necesita reglas semánticas y estructurales. Verifique que la herramienta está permitida para la tarea, que sus argumentos cumplen un esquema, que los identificadores se resuelven contra registros autorizados y que el efecto solicitado corresponde al plan aprobado. Para operaciones de escritura, valide precondiciones y aplique idempotencia cuando sea posible. Para acciones irreversibles o de gran alcance, muestre una previsualización antes de ejecutar.

La aprobación humana solo es eficaz si la persona puede decidir con información suficiente. La interfaz debería mostrar la acción propuesta, el destino final resuelto, los datos que saldrán, la fuente de los parámetros relevantes, el efecto esperado y si puede revertirse. Una aprobación que presenta solo un botón genérico de confirmar puede trasladar el riesgo a la persona sin darle capacidad real de detectar la manipulación.

Pedir al modelo que ignore instrucciones en documentos puede formar parte de una defensa en profundidad, pero no es una frontera de seguridad. Tampoco bastan un único prompt de sistema, el bloqueo de palabras o la confianza en que RAG recupere fuentes reputadas. OWASP advierte que RAG y el ajuste fino no eliminan por sí solos el riesgo de inyección; sus recomendaciones incluyen separación de instrucciones y datos, mínimo privilegio, validación de herramientas, supervisión y pruebas. Estos controles reducen riesgo, pero no permiten prometer una detección completa de contenido hostil.

Diseñe una batería de pruebas adversarias, no solo pruebas de calidad

Las pruebas deben demostrar propiedades observables: que un documento no puede ampliar el alcance de datos; que un correo no puede cambiar un destinatario; que una página no puede iniciar una llamada a herramienta no justificada; y que una instrucción en resultados de una API no puede persistir como preferencia o memoria. Defina cada caso con una petición legítima, una entrada adversaria, las capacidades disponibles, el comportamiento esperado y los eventos que deben quedar registrados.

Cubrir variantes importa más que repetir literalmente el mismo ataque. Incluya instrucciones directas, fragmentadas, codificadas, ocultas en metadatos cuando su extractor los procese, formuladas como traducciones o resúmenes y distribuidas entre varias fuentes. Pruebe también conflictos: un documento puede pedir una acción mientras otro la contradice, o un resultado de búsqueda puede intentar que el modelo olvide el propósito inicial. El criterio no es que el sistema clasifique todo texto malicioso, sino que conserve las prohibiciones de capacidad incluso si el texto se interpreta.

Mida por separado la detección, el bloqueo y la contención. La detección identifica contenido sospechoso; el bloqueo evita una acción no autorizada; la contención limita datos y privilegios si la detección falla. Registre falsos bloqueos que interrumpan tareas legítimas, pues una política excesivamente amplia puede empujar a los usuarios a buscar canales alternativos. Revise las pruebas en cada cambio de modelo, conector, plantilla de orquestación, permiso o herramienta.

El conjunto de datos LLMail-Inject estudia intentos adaptativos contra un asistente de correo con herramientas. Puede servir como referencia para plantear evaluaciones de flujos de correo, pero no demuestra por sí mismo la resistencia de otra arquitectura, otro modelo o un entorno con diferentes permisos. Complemente cualquier corpus externo con escenarios derivados de sus conectores, datos y operaciones reales.

Observabilidad y respuesta a incidentes

Un registro útil permite reconstruir el flujo sin conservar más contenido sensible del necesario. Debe relacionar la petición autenticada, la versión de la política, los identificadores y etiquetas de los fragmentos recuperados, el plan propuesto, las herramientas candidatas, los argumentos normalizados, las decisiones de autorización, las aprobaciones y el resultado. Según la sensibilidad, almacene huellas, referencias controladas o copias cifradas con acceso restringido en lugar de replicar libremente documentos completos.

Defina señales de alerta: desviación entre el objetivo inicial y una acción propuesta, solicitud de herramientas no disponibles para la tarea, cambio de destinatario, intento de acceder a campos no recuperados, cadenas inusuales de herramientas y salidas hacia destinos nuevos. Las señales no sustituyen la política preventiva, pero ayudan a priorizar revisión y a descubrir rutas no previstas. El monitoreo de desvíos de plan y de cadenas de herramientas coincide con el enfoque de defensa descrito por Microsoft.

Ante un incidente, primero contenga el flujo: desactive temporalmente la herramienta o el conector afectado, revoque tokens o sesiones cuando proceda y preserve los registros. Después determine el alcance: qué contenido se leyó, qué herramientas se propusieron y ejecutaron, qué datos salieron, con qué identidad y a qué destinos. La investigación debe diferenciar una propuesta bloqueada de una acción realmente completada.

La recuperación incluye corregir la regla que permitió el tránsito, revisar privilegios y añadir una regresión que reproduzca el caso. Si hubo salida de datos, active los procesos de respuesta y notificación que correspondan a la clasificación y jurisdicción aplicables. No atribuya automáticamente una filtración a inyección indirecta: confirme la cadena causal con trazas, porque errores de configuración, permisos excesivos o automatizaciones independientes pueden producir efectos similares.

Matriz de decisión por caso de uso y criterios de despliegue

La misma política general adopta formas distintas según el caso de uso. Un asistente documental requiere fuerte separación entre evidencia e instrucciones, pero quizá no tenga efectos externos. Un agente de correo añade riesgo de destinatarios y adjuntos. Un navegador con herramientas incorpora contenido cambiante de múltiples orígenes. Una automatización interna puede operar sobre sistemas críticos aun cuando sus fuentes parezcan internas. Ajuste los controles al impacto de las acciones, no solo a la probabilidad de encontrar texto hostil.

Antes de abrir un flujo a usuarios, exija pruebas registradas de que el contenido no fiable no altera objetivo, permisos, destinatarios ni herramientas permitidas. Verifique además que la identidad de ejecución tenga los privilegios mínimos y que las operaciones de alto impacto posean una previsualización o una puerta de aprobación. Si no puede demostrar estas propiedades, limite el flujo a lectura, reduzca conectores o mantenga la acción manual.

Esta guía se complementa con la guía de RAG con fuentes y con la guía de agentes con herramientas del índice de seguridad. La primera ayuda a evaluar la evidencia que respalda una respuesta; la segunda aborda permisos y recuperación de forma amplia. Aquí la pregunta específica es otra: aunque el asistente haya recuperado contenido pertinente y disponga de una herramienta permitida, ¿qué mecanismo impide que ese contenido se convierta en autoridad para ordenar una acción?

No existe una garantía general de que un modelo reconocerá toda inyección indirecta. Por ello, el umbral razonable no es afirmar invulnerabilidad, sino demostrar defensas por capas, limitar el daño si la detección falla y mantener pruebas de regresión para los flujos que realmente se despliegan.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.