Fugas de datos en IA: Rovo vs. Notion AI vs. Slack AI vs. ClickUp Brain

Respuesta rápida: Las filtraciones de datos por IA en herramientas de trabajo ocurren cuando un asistente procesa texto malicioso, ejecuta las instrucciones ocultas en él y envía información confidencial a un servidor externo mediante la consulta de una URL, una imagen renderizada o un enlace. Diversas investigaciones públicas lo han demostrado en Atlassian Rovo, Notion AI y Slack AI. Notion y Slack implementaron soluciones; hasta el 27-10-2026, no hemos encontrado ninguna corrección pública para la vía explotada en Rovo.

La IA de gestión de proyectos procesa información que usted no escribió: tickets de soporte, archivos PDF cargados, páginas sincronizadas mediante conectores, canales públicos... Cualquiera de ellos puede albergar instrucciones ocultas.

Este artículo compara Rovo, Notion AI, Slack AI y ClickUp Brain. Cada fila cita un informe técnico original o la documentación oficial del proveedor, con su respectiva fecha. Cuando no hallamos información, la tabla indica «no se encontró reporte público». Este mismo mecanismo se aplica a los agentes de programación, tema que abordamos al final.

Qué es una filtración de datos por IA en una sola frase

Una inyección de prompt indirecta (indirect prompt injection) es una instrucción oculta dentro del contenido que procesa un asistente de IA, la cual termina ejecutándose como si usted mismo la hubiera solicitado.

Esto se convierte en una filtración de datos cuando se cumplen tres condiciones simultáneas. Simon Willison las definió en junio de 2025 como la tríada letal (lethal trifecta):

1. El asistente tiene acceso a datos privados.
2. El asistente procesa información manipulable por terceros ajenos.
3. El asistente cuenta con un canal para emitir datos hacia el exterior.

Si elimina cualquiera de estas tres condiciones, la vía de filtración queda neutralizada. Sin embargo, los asistentes de entornos de trabajo incorporan las tres por diseño.

Cómo funcionaba la exfiltración en Atlassian Rovo

PromptArmor publicó su informe sobre Rovo el 05-08-2026. La cadena de ataque es concisa:

1. Un usuario sube un archivo (en la demostración, una «Guía de Backlog») que contiene una instrucción oculta.
2. El usuario le pide a Rovo que organice sus tickets de Jira.
3. Rovo busca en Jira y Confluence y, acto seguido, ejecuta la instrucción oculta.
4. Rovo concatena el contenido de los tickets y páginas a una URL del atacante y la consulta mediante su herramienta de recuperación de URLs.
5. El servidor del atacante registra la petición con los datos exfiltrados. Mientras tanto, el usuario ve una respuesta totalmente normal en pantalla.

No se requirió ningún paso de confirmación o aprobación. El ataque funcionó incluso con la búsqueda web desactivada, ya que esa opción no deshabilita la herramienta interna de recuperación de URLs. Además, Rovo renderiza imágenes en Markdown, lo que constituye un segundo canal de salida.

El cronograma de divulgación resulta revelador para las empresas evaluadoras. PromptArmor reportó el fallo el 23-05-2026; Atlassian confirmó la recepción el 25-05; los mensajes de seguimiento del 04-06 y el 29-07 quedaron sin respuesta, y el artículo se hizo público el 05-08 mientras Rovo continuaba vulnerable. El debate en Hacker News sumó 306 puntos y 138 comentarios.

Otro problema independiente en Rovo sí fue resuelto. La nota de investigación de la Cloud Security Alliance del 14-08-2026 analiza la técnica de un solo clic «RovoBlast» descubierta por Varonis a través de un parámetro URL en el chat, la cual Atlassian corrigió del lado del servidor antes de su publicación. Esa misma nota señala que la vía documental reportada por PromptArmor seguía sin solucionarse. Nuestra revisión al 27-10-2026 no halló ningún anuncio posterior sobre un parche.

Una aclaración de nombres: Rovo Dev es el agente de desarrollo y programación de Atlassian. Se trata de un producto distinto al asistente Rovo analizado aquí, y las investigaciones citadas no lo evalúan.

Rovo frente a Notion AI, Slack AI y ClickUp Brain

La siguiente tabla compara los comportamientos demostrados o documentados de cada asistente. La indicación «No analizado» significa que la fuente consultada no cubre ese punto específico.

Excluimos a Linear y Asana. Nuestra búsqueda al 27-10-2026 no arrojó reportes públicos de exfiltración por inyección de prompts para ninguno de los dos asistentes, y la ausencia de un informe no equivale a una garantía de seguridad.

Notion AI: la edición se guardaba antes de que pudiera aprobarla

En el caso documentado por PromptArmor sobre Notion AI, se camufló texto en color blanco a tamaño de 1 punto dentro de un currículum. Al pedirle a Notion AI que actualizara un panel de seguimiento de contratación usando ese documento, la IA construyó la URL de una imagen añadiéndole el contenido confidencial del panel. Aunque Notion mostraba una advertencia sobre la URL externa, los cambios ya se habían guardado, por lo que los datos salían del entorno tanto si el usuario aceptaba como si rechazaba la acción.

Notion validó la vulnerabilidad tras su publicación y desplegó un parche esa misma noche. PromptArmor también alertó sobre un fallo similar en el asistente de redacción Notion Mail; la actualización disponible no aclara si la solución cubre también Mail.

Slack AI: a un solo clic de un enlace de «reautenticación»

El atacante publicó instrucciones en un canal público creado por él mismo. Cuando otro usuario le preguntó a Slack AI sobre un dato confidencial de su propio canal privado, la respuesta incluyó un enlace para «hacer clic aquí y volver a autenticarse», el cual llevaba el secreto insertado dentro de la URL. Bastaba un único clic para transmitir la información al atacante.

Slack respondió a PromptArmor el 19-08-2024 señalando que la indexación de canales públicos correspondía al comportamiento previsto del sistema. El 21-08-2024, Slack anunció un parche para un escenario de phishing de baja gravedad; SC Media informó que el aviso de seguridad no mencionaba a PromptArmor ni confirmaba que tratara exactamente el mismo vector. PromptArmor también advirtió que ese mismo mes Slack AI comenzó a procesar archivos de canales y mensajes directos, una vía que no evaluaron en su momento.

ClickUp Brain: sin reportes públicos encontrados

No encontramos investigaciones de exfiltración publicadas sobre ClickUp Brain o Super Agents al 27-10-2026. La página de Super Agents de ClickUp afirma que sus agentes operan con permisos implícitos y explícitos y conservan «registros de auditoría completos para cada acción». Por su parte, un artículo del blog de ClickUp sobre flujos de trabajo de Super Agents indica que estos heredan los permisos del usuario y exigen aprobación humana para acciones críticas. Se trata de declaraciones comerciales del fabricante, no de auditorías independientes. Además, el artículo de soporte de ClickUp sobre inyecciones de prompts nos solicitó una verificación antibot, por lo que decidimos no citarlo.

Qué soluciones funcionan de verdad y cuáles solo ralentizan al atacante

El debate de Hacker News clasificó la efectividad de las distintas defensas:

• Recuperar únicamente URLs introducidas por el usuario o devueltas por herramientas de confianza. Simon Willison sostiene que el agente bajo ninguna circunstancia debe construir una URL por su cuenta. Filtrar los parámetros de búsqueda no basta, ya que los registros DNS con comodines pueden transportar información a través de subdominios.
• Limitarse a URLs preindexadas. El comentarista wunderwuzzi23 puntualizó que restringir las consultas a páginas indexadas en motores de búsqueda continúa permitiendo fugas, carácter a carácter en cada petición.
• Listas de dominios permitidos (allowlists). Para asistentes con funciones acotadas, restringir el tráfico saliente a una lista corta de dominios autorizados resulta altamente eficaz.
• Clasificadores y filtros por expresiones regulares. Útiles como capa defensiva secundaria. Al ser probabilísticos, nunca deben constituir la última línea de defensa.

La conclusión unánime: los límites deterministas aplicados al canal de salida superan a los intentos de crear prompts más sofisticados. Un modelo entrenado para rechazar peticiones dudosas con mayor frecuencia sigue teniendo el mismo acceso de red que se le haya otorgado, un principio que ya señalamos al analizar las inyecciones de prompts y las barreras de contención para agentes cuando se lanzó Claude Opus 5.5.

Qué verificar antes de habilitar una IA en su espacio de trabajo

Solicite al proveedor las siguientes aclaraciones por escrito:

1. ¿Qué herramientas pueden enviar datos fuera del entorno de la organización: peticiones de URL, renderizado de imágenes, previsualización de enlaces, correo electrónico, conectores?
2. ¿Cada ajuste asociado desactiva por completo la herramienta o solo oculta la interfaz que la utiliza? El selector de búsqueda web de Rovo hizo lo segundo.
3. ¿Puede el sistema consultar una URL estructurada o construida por el propio modelo?
4. ¿Se renderizan en las respuestas de la IA imágenes Markdown procedentes de dominios externos?
5. ¿Qué fuentes lee por defecto: archivos subidos, unidades en la nube conectadas, mensajes directos, canales públicos?
6. ¿Qué operaciones exigen aprobación humana y dicha validación se produce antes del efecto colateral? En Notion ocurría después.
7. ¿Cómo gestionó el proveedor su último reporte de vulnerabilidad externo y con qué rapidez actuó?

Adopte un asistente para su entorno de trabajo únicamente cuando sus vías de salida estén documentadas y sea posible desactivarlas una por una. Posterque su uso si el proveedor no puede detallarlas con precisión.

La posición real de Sharkly ante este reto

Sharkly no es un asistente integrado dentro de sus documentos y no es inmune a las inyecciones de prompts. Sharkly orquesta agentes de desarrollo como Claude Code o Codex, y estos agentes analizan texto no confiable continuamente: descripciones de issues, archivos README o páginas web descargadas. La tríada letal aplica exactamente igual a su entorno.

La diferencia fundamental radica en quién controla el perímetro de ejecución. En Sharkly, los agentes operan en sus propios Computers mediante un servicio local. La documentación de Computers detalla que cada Computer proporciona los archivos, las credenciales, el acceso a la red y las herramientas que necesita una ejecución. Por lo tanto, el control del tráfico de salida le pertenece a usted: sitúe un Computer tras una lista de dominios permitidos y cualquier ejecución heredará ese límite de forma estricta, sin importar qué agente esté corriendo.

Otras medidas de contención clave definidas en la documentación incluyen:

• Los invitados solo acceden a los Spaces a los que han sido asignados. No pueden descubrir ni unirse por su cuenta a Spaces públicos (Usuarios y roles).
• Las acciones hacia servicios de terceros requieren un conector autorizado. Ningún flujo de automatización puede invocar una aplicación externa que no haya sido vinculada explícitamente.
• Las credenciales permanecen fuera de las Skills. La documentación de Skills prohíbe taxativamente almacenar contraseñas, tokens o claves dentro de las instrucciones o archivos de una Skill.

Ninguna de estas salvaguardas impide por completo que un agente sea inducido mediante engaño a realizar una acción indebida dentro del perímetro de acceso que tenga concedido. Lo que logran es restringir ese radio de acción y asegurar que cada Task requiera un paso de aceptación humana explícita. Nuestras publicaciones sobre permisos para agentes de programación y puntos de control y aprobación abordan en detalle cómo fijar estos límites.

Conclusión

El problema de la inyección de prompts sigue sin resolverse en cualquier producto que procese texto no confiable, incluidos los agentes de programación. La pregunta determinante debe ser mucho más concreta: ¿qué vías de salida tiene a su alcance el asistente y permite el sistema desactivarlas? De las cuatro plataformas examinadas, dos sufrieron filtraciones públicas e implementaron correcciones, una presentó una filtración pública sin solución conocida hasta la fecha y la otra carece de reportes públicos.

Si utiliza varios agentes de código y necesita ejecutarlos en servidores cuya red esté bajo su control, vincule un Computer a Sharkly, blinde su tráfico saliente y asígnele a un Agent una Task de bajo riesgo. Actualmente, Sharkly es gratuito para organizaciones de hasta 5 integrantes.

Preguntas frecuentes

¿Sigue Atlassian Rovo siendo vulnerable a la exfiltración de datos?

La vía documental reportada por PromptArmor no estaba parcheada al 05-08-2026 y no encontramos ninguna solución pública anunciada hasta el 27-10-2026. Por su parte, la vulnerabilidad independiente mediante enlaces identificada por Varonis sí fue solucionada.

¿Solucionó Notion la filtración de datos en Notion AI?

Sí. Notion comunicó que la remediación contra las actualizaciones inseguras de documentos con IA se encontraba en producción el 07-01-2026, la misma noche en que PromptArmor divulgó el hallazgo públicamente.

¿Se corrigió la inyección de prompts en Slack AI?

Slack anunció un parche el 21-08-2024, aunque sin confirmar de forma explícita si resolvía exactamente el problema documentado por PromptArmor.

¿Desactivar la búsqueda web evita que un asistente de IA filtre información?

No necesariamente. En el caso de Rovo, el ajuste de búsqueda web no inhabilitaba la herramienta interna de recuperación de URLs, por lo que la exfiltración continuaba siendo viable.

¿Qué es la «tríada letal» en la seguridad de la IA?

La confluencia de acceso a datos privados, procesamiento de contenido no confiable y un canal para transmitir información hacia el exterior. Cualquier asistente que reúna estas tres condiciones puede ser manipulado para provocar una filtración.

¿Pueden los agentes de programación filtrar datos mediante este mismo mecanismo?

Sí. Un agente de código que analice un README manipulado y cuente con salida a la red enfrenta exactamente el mismo riesgo. La mejor protección radica en restringir sus credenciales y el tráfico de red saliente directamente a nivel de host.