Author: Anthony John Padilla

Los expertos en ciberseguridad han lanzado hoy una advertencia: los asistentes de IA integrados en el correo electrónico pueden acabar siendo una ayuda inesperada para un atacante si consigue tomar el control de una cuenta.

Sobre el papel, estas funciones están ahí para ahorrar tiempo: resumen hilos, encuentran archivos y redactan mensajes. El problema, dicen los especialistas, es que ese mismo nivel de acceso también puede servir para ampliar una intrusión sin recurrir a herramientas externas ni a un malware especialmente vistoso.

Cuando el intruso ya está dentro, puede apoyarse en capacidades que la propia plataforma ya trae de serie para revisar años de conversaciones, detectar contactos clave y moverse por la empresa sin hacer mucho ruido.

En la práctica, el chatbot integrado en el servicio de correo puede usarse para rastrear contratos, facturas, credenciales compartidas por error, documentos adjuntos y conversaciones sobre pagos o proyectos delicados. También ayuda a recomponer organigramas informales: quién da el visto bueno a las transferencias, qué ejecutivos tratan con proveedores y qué empleados manejan información valiosa.

En seguridad a esto se le conoce como “vivir de lo que ya hay”. Y complica mucho la detección, porque la actividad del atacante puede parecerse bastante al uso habitual del empleado.

Después suele llegar la suplantación. Si analiza el tono, la firma, los horarios y la forma de escribir de la víctima, el asistente puede redactar correos que pasan por mensajes reales de un compañero de confianza o de un directivo.

El alcance del cambio, añaden los expertos, ya se ve en los datos. Las herramientas generativas aparecen en más del 80% de los correos de phishing y, al mismo tiempo, este tipo de campañas se ha disparado un 1.265%.

Hay más. Según esos mismos especialistas, los mensajes creados con estos sistemas logran una tasa de clics del 54%, frente al 12% del phishing convencional. La velocidad también juega del lado del atacante: lo que antes exigía horas de redacción y revisión ahora puede quedar listo en minutos, con menos fallos gramaticales y menos tropiezos de estilo.

Y está apareciendo otra vía de ataque, bastante menos visible, de la que también alertan los especialistas: incrustar instrucciones ocultas en mensajes para que sea el propio asistente quien las lea, las interprete y actúe en consecuencia.

Así, un usuario puede abrir un correo que parece completamente normal mientras el sistema recibe órdenes encubiertas para resumir información sensible, revelar datos o ejecutar acciones que nadie quería autorizar.

El riesgo crece todavía más cuando el fraude mezcla correos convincentes con llamadas de voz y vídeos falsificados. Los especialistas señalan que el fraude basado en falsificaciones ultrarrealistas ha crecido más de un 2.000% desde 2022, y ya hay casos documentados en los que un trabajador fue engañado para autorizar un pago de 25 millones.

Por eso, sostienen, los filtros clásicos ya no alcanzan por sí solos. La defensa se está moviendo hacia sistemas capaces de detectar comportamientos anómalos, solicitudes fuera de lo normal y patrones de acceso extraños, en lugar de depender solo de firmas o de palabras sospechosas.

Aun con todo, el coste del phishing sigue subiendo, advierten los expertos en ciberseguridad. Para usuarios y empresas, las medidas más urgentes pasan por reforzar la autenticación multifactor, revisar a qué datos pueden acceder estos asistentes, recortar permisos y desconfiar incluso de mensajes impecables cuando piden pagos, archivos o cambios de credenciales.

Google ha retirado hoy Nano Banana 2 de Google Earth, apenas dos días después de activarla, y dice que, si la función regresa, lo hará con medidas de seguridad bastante más estrictas. La explicación de Google es directa: evitar que una herramienta capaz de generar escenas fotorrealistas sobre imágenes satelitales, vistas aéreas y modelos 3D reales acabe facilitando la difusión de contenido falso con aspecto de prueba visual.

Google Earth Pro Descargar

No era un problema menor. La herramienta permitía escribir una instrucción de texto y colocar el resultado dentro de Google Earth. Con eso ya era muy fácil fabricar imágenes falsas sobre un contexto cartográfico real.

La reacción fue casi inmediata. Enseguida empezaron a aparecer usuarios mostrando lo sencillo que resultaba crear supuestas “evidencias” de hechos que nunca ocurrieron.

Entre los ejemplos que circularon en esas publicaciones había una columna de refugiados en la frontera mexicana generada con una instrucción simple. También se mencionaron montajes de una planta nuclear en Irán, un hospital bombardeado en Gaza y un accidente mortal de coche en Ámsterdam.

La crítica, aun así, no iba solo por la calidad de las imágenes. Iba, sobre todo, por el lugar en el que se generaban.

Google Earth no es una app cualquiera. Para periodistas, verificadores e investigadores de fuentes abiertas, sigue siendo una referencia habitual cuando toca contrastar ubicaciones, cambios en el terreno o daños en zonas de conflicto y en otros lugares de difícil acceso.

Ahí está el choque de fondo. Integrar escenas falsas dentro de una plataforma asociada a la verificación puede desgastar la confianza en todo el conjunto de imágenes geoespaciales.

Eso fue, precisamente, lo que advirtieron varios expertos en desinformación y analistas de fuentes abiertas. Si cualquiera puede producir una captura convincente con un contexto real, separar lo auténtico de lo manipulado se vuelve mucho más difícil. Y esa pérdida de credibilidad no se queda en el plano teórico: puede tener consecuencias reales en conflictos, crisis humanitarias o investigaciones sensibles.

Google defendió que las imágenes generadas no se incorporaban a la vista principal de Google Earth para todos los usuarios y que quedaban marcadas con SynthID, el sistema de marca de agua de la compañía. Sus críticos recuerdan que esa verificación exige una comprobación activa y que no impide que una imagen se saque de contexto, se recorte o circule sin explicación en redes sociales.

La retirada exprés también encaja en un patrón que Google ya conoce bien. La empresa ha tenido que pausar o reajustar otras funciones de generación de imágenes, incluidas algunas de Gemini, su familia de modelos y herramientas de IA, cuando los controles iniciales no han dado la talla. Y, como suele pasar con las funciones experimentales de Google, nadie sabe cuándo volverá Nano Banana 2 a Google Earth.

OpenAI aseguró hoy que su modelo GPT-5.6 Sol puede quedar por encima de Opus 5, de Anthropic, en ARC-AGI-3, una de las pruebas de razonamiento que más atención arrastra ahora mismo en el sector.

ChatGPT Descargar

El punto conflictivo es otro. Ese resultado, según la propia explicación de OpenAI, no salió del entorno oficial y neutral del test, sino de una evaluación rehecha con ajustes extra disponibles en su propia API. En la configuración estándar, la que figura en los resultados publicados del benchmark, la foto cambia bastante: GPT-5.6 Sol se quedó en un 7,8%, mientras que Opus 5 llegó al 30,2%, una cifra presentada como récord bajo esas mismas condiciones.

La respuesta de OpenAI fue volver a pasar la prueba usando su Responses API. Con ese método, siempre según la compañía, GPT-5.6 Sol sube hasta el 38,3% y supera así el 30,2% de Opus 5.

Pero esa lectura viene con letra pequeña, y no es menor: no hablamos de una puntuación obtenida dentro del entorno oficial del benchmark.

Ahí empieza la discusión de verdad. OpenAI sostiene que la configuración estándar perjudica a GPT-5.6 Sol porque borra el razonamiento entre turnos, algo que la empresa ha descrito como una especie de “amnesia”. Si el sistema pierde ese hilo, su rendimiento cae en tareas que dependen de varios pasos.

Ese 38,3%, según OpenAI, se apoyó en dos funciones concretas, “Retained Reasoning” y “Compaction”. La primera permite conservar el razonamiento entre pasos. La segunda resume el contexto anterior para que no se pierda del todo cuando la conversación se alarga.

Claude Descargar

Sobre el papel, no sería un truco diseñado a medida para ARC-AGI-3, sino opciones generales que, dice OpenAI, cualquier cliente podría activar. Aun así, usarlas cambia bastante la comparación con otros proveedores si esos proveedores no tienen exactamente la misma interfaz, o si el benchmark no contempla esas funciones por defecto.

ARC Prize dejó caer además otro matiz que no es menor: el entorno neutral podría haber utilizado una versión antigua de la API. Si fue así, GPT-5.6 Sol habría competido con desventaja frente a Opus 5.

François Chollet, creador de ARC, respondió que las configuraciones personalizadas para un benchmark concreto no están permitidas. A la vez, dejó abierta otra idea: ajustes de propósito general, disponibles para usuarios reales, podrían aceptarse siempre que se expliquen con total claridad.

ARC-AGI-3 intenta medir “inteligencia fluida” con desafíos nuevos, más cercanos a pequeños juegos de lógica y sin instrucciones previas. En una prueba así, la forma en que cada sistema maneja la memoria, el contexto y los pasos intermedios puede mover mucho el resultado final.

De momento, ese 38,3% sigue siendo un dato comunicado por la propia OpenAI sobre el conjunto público de ARC-AGI-3. El siguiente paso, el que de verdad despejaría dudas, sería una réplica independiente sobre el conjunto privado usando esos mismos ajustes de API.

Y, por debajo del cruce entre OpenAI y Anthropic, vuelve la pregunta de siempre en este sector: hasta qué punto una tabla pública refleja el rendimiento que luego ve un cliente en condiciones reales. No está claro si esa verificación independiente llegará pronto.

Sygnia, firma especializada en ciberseguridad, encontró una vulnerabilidad crítica en una aplicación de alta de clientes utilizada por una empresa de servicios financieros que gestiona miles de millones en activos. De acuerdo con la investigación, la herramienta se había construido en gran medida con ayuda de Claude, y el fallo podía dejar expuesta información personal y financiera de una sensibilidad extrema.

Lo inquietante no era un bug de manual, de esos que saltan a la vista en una revisión básica. La aplicación tenía varias defensas que, vistas por separado, parecían sensatas. El problema es que todas estaban colocadas en la capa equivocada: la decisión de fondo sobre qué debía considerarse confiable estaba mal planteada.

La mecánica era esta. La aplicación emitía o regeneraba tokens de acceso para los solicitantes solo por el hecho de que alguien presentara su GUID, un identificador global único que, en teoría, debía servir únicamente para localizar un registro. En la práctica, explica Sygnia, ese identificador terminó funcionando como una llave maestra. Si alguien conocía el GUID, podía entrar como si fuera el titular legítimo.

Ahí estaba el agujero.

A partir de ese punto se podía consultar nombres, datos de contacto, estado de la solicitud, información financiera, datos usados para la verificación de identidad, información de pago, números de la Seguridad Social y registros de co-solicitantes. Dicho de forma simple, no era una fuga menor, sino la exposición potencial de expedientes completos de clientes.

La aplicación sí había incorporado medidas que muchas organizaciones considerarían razonables: tokens temporales, caducidad de sesiones, limitación de peticiones, auditoría de accesos, recuperación de sesión y detección de actividad sospechosa. El problema es que todas esas barreras descansaban sobre una premisa equivocada.

La pregunta decisiva nunca quedó bien resuelta: quién debía recibir un token desde el principio. Si un sistema acepta un simple identificador como prueba suficiente de identidad, casi todo lo demás pierde buena parte de su valor.

Sygnia insiste en que este caso deja ver un problema muy delicado del desarrollo actual. El código puede compilar, pasar pruebas básicas y no mostrar los patrones inseguros de siempre, y aun así seguir siendo peligroso. No había aquí una inyección SQL ni un flujo de datos claramente expuesto, sino un fallo de arquitectura en la frontera de confianza entre el usuario y el sistema.

Y ese tipo de error suele pasar de largo en muchas revisiones automáticas, porque, técnicamente, cada pieza por separado parece correcta.

El caso se suma, además, a una lista cada vez más larga de advertencias sobre el uso de herramientas de generación automática de código en entornos sensibles. Sygnia cita estudios que sitúan entre el 45% y el 62% la proporción de código generado que presenta vulnerabilidades, con mejoras bastante limitadas con el paso del tiempo. Estas herramientas suelen rendir mejor ante fallos muy conocidos, pero siguen tropezando con errores lógicos más sutiles.

Hay además una paradoja incómoda. Esta tecnología ya la están usando tanto atacantes como defensores. Sygnia sostiene que también está acelerando ofensivas y menciona un caso reciente en el que un solo atacante logró comprometer un entorno corporativo en la nube en 72 horas. Al mismo tiempo, la propia firma recurrió a un modelo de lenguaje para ayudar a detectar esta vulnerabilidad.

Para muchos expertos del sector, la lección cae por su propio peso: el código generado automáticamente no debería darse por confiable hasta haber pasado una validación a fondo. Con el ritmo de desarrollo actual, la deuda de seguridad crece más deprisa que la capacidad de revisarla, y mientras tanto aumentan la presión regulatoria y el riesgo para la confianza del consumidor.

Hoy, en el pódcast Relentless, habló Sam Altman. El consejero delegado de OpenAI defendió una idea muy concreta: el gran salto de productividad que traen las herramientas generativas no va a traducirse por sí solo en más tiempo libre.

ChatGPT Descargar

Según explicó, aunque esta tecnología permita hacer más en menos tiempo, ni las personas ni las empresas van a frenar por eso. La ambición y la competencia, sostuvo, seguirán creando nueva demanda, así que el tiempo ganado no acabará necesariamente convertido en descanso.

Altman fue incluso un paso más allá y llegó a afirmar que la sociedad “ya está en la singularidad”, una forma de poner nombre a un cambio tecnológico tan profundo que, a su juicio, ya está alterando el trabajo y también las expectativas sobre lo que una persona puede llegar a producir.

Eso choca con una narrativa que cada vez circula más: que una automatización avanzada podría abrir la puerta a jornadas más cortas sin tocar los salarios. Altman plantea justo lo contrario. Si una herramienta permite ahorrar tiempo, ese margen tenderá a llenarse con más objetivos, más proyectos y más presión por rendir.

No siempre lo contó así. Tiempo atrás, Sam Altman había avisado de un posible “apocalipsis laboral” provocado por estas tecnologías. Más recientemente, sin embargo, dijo que estaba “encantado de haberse equivocado” sobre una destrucción inmediata y masiva de empleo, al tiempo que remarcaba que la interacción humana conserva un valor difícil de sustituir.

Aun así, los datos no empujan todos en la misma dirección. Una encuesta encontró que el 29% de las organizaciones con semana laboral de cuatro días usa estas herramientas de forma intensiva, frente al 8% de las compañías que siguen con el esquema tradicional de cinco días.

Microsoft Copilot Descargar

Y hay más. Según esa misma encuesta, el 93% de las empresas que ya las utiliza dijo estar abierta a una semana de cuatro días. Los ensayos tampoco han pasado de largo: un estudio global registró un crecimiento medio de ingresos del 8% entre empresas que probaron la semana de cuatro días, junto con una caída del estrés y la fatiga entre los empleados. En Reino Unido, una gran prueba piloto dejó otro dato que pesa: según ese ensayo, el 89% de las compañías participantes mantuvo el modelo después de la prueba y el 51% lo adoptó de forma permanente.

Algunas firmas ya vinculan ese cambio, al menos en parte, a la automatización de tareas rutinarias. Empresas como Convictional y RocketAir han contado que nuevas herramientas les dieron la eficiencia suficiente para sostener una semana de cuatro días sin recortar sueldos.

Además, lo que dice Sam Altman contrasta con propuestas que han salido de OpenAI, su propia empresa. En un documento de política pública, la compañía detrás de ChatGPT planteó una semana de 32 horas como posible “dividendo de eficiencia”. El debate, además, ya llegó a la política: en Estados Unidos, el senador Bernie Sanders impulsa un proyecto para una semana de 32 horas; en España se ha debatido bajar a 37,5 horas semanales; y países como Dinamarca y Austria exploran o discuten pilotos de cuatro días. Sigue sin estar claro si este aumento de productividad acabará convirtiéndose en recortes reales de jornada, sobre todo fuera de las oficinas y de las economías occidentales, donde sectores como la manufactura, la sanidad o la agricultura siguen quedando en un segundo plano.

Google ha activado hoy Gemini 3.5 Flash Cyber, un modelo nuevo centrado en ciberseguridad. La idea, siempre en palabras de la propia empresa, es rastrear vulnerabilidades de software a gran escala. Por ahora no estará al alcance de cualquiera: el acceso arranca de forma limitada, dentro de un programa piloto reservado a gobiernos y a socios que Google considera de confianza.

Nmap Descargar

Junto con Gemini 3.5 Flash Cyber llega también CodeMender. Se trata de un agente pensado para localizar fallos, comprobar cuáles son reales y plantear correcciones, con la intención de acortar la respuesta de los equipos técnicos.

Con este anuncio, Google entra de lleno en una de las carreras más tensas del sector: la de usar herramientas avanzadas para encontrar errores antes que los atacantes. Aun así, la compañía ha preferido moverse con cuidado. De ahí que el despliegue inicial quede restringido a ese programa piloto para gobiernos y socios de confianza.

Google explica que Gemini 3.5 Flash Cyber se ha creado para analizar varias trayectorias de ejecución al mismo tiempo, detectar puntos débiles de seguridad y ayudar después en la remediación.

También lo vende como una opción más ligera, más rápida y más barata que otros modelos de mayor tamaño enfocados en esta misma tarea.

Mientras tanto, CodeMender cumple una función bastante directa. No se queda en señalar posibles fallos: también ayuda a validarlos y a encaminar la reparación. Lo que busca Google, dicho de forma simple, es recortar el tiempo que pasa entre la detección de una vulnerabilidad y la aplicación de un parche o de un cambio seguro en el código.

La empresa sostiene además que las primeras pruebas internas ya han dejado resultados llamativos. En ensayos del equipo Cloud Vulnerability Research de Google, estas herramientas habrían servido para encontrar con rapidez problemas graves, incluidos fallos de ejecución remota de código y un error de corrupción de memoria en un servicio que ya estaba en producción. Todo eso, según la compañía, en alrededor de dos horas.

Aun con esos datos, Google no va a abrir el acceso al público general de inmediato. La decisión encaja con una inquietud cada vez más extendida en la industria: capacidades de este tipo pueden reforzar las defensas, sí, pero también pueden acabar en usos maliciosos si se distribuyen sin controles.

El movimiento aprieta también la competencia con otros gigantes tecnológicos. En los últimos meses han ido apareciendo propuestas parecidas, entre ellas Claude Mythos Preview, de Anthropic, y las iniciativas Daybreak y Codex Security, de OpenAI. Todas apuntan al mismo frente: buscar y corregir vulnerabilidades en software. Algunas estimaciones citadas tras el anuncio sitúan este mercado por encima de los 44.000 millones en 2026, empujado por ataques más frecuentes y, además, cada vez más automatizados.

Con todo, la adopción real todavía no avanza al mismo ritmo en todas partes. Según una encuesta de 2026 citada tras el anuncio, el 78% de las organizaciones ya usa este tipo de tecnología en operaciones de seguridad. Otra cosa es tenerla asentada de verdad en producción: ahí solo llega el 27%.

La barrera principal sigue siendo la confianza. Especialistas del sector recuerdan que las herramientas automáticas pueden disparar falsos positivos o, peor todavía, dejar pasar fallos críticos. De hecho, otra investigación citada a raíz del anuncio señalaba que el 78% de los profesionales de ciberseguridad había visto cómo sistemas de pruebas totalmente automatizados dejaban escapar vulnerabilidades importantes. La velocidad avanza, desde luego, pero la última decisión sigue en manos humanas.

OpenAI, la empresa detrás de ChatGPT, ha admitido que fue responsable de una intrusión en la plataforma Hugging Face. La propia compañía sostiene que todo empezó durante una evaluación interna de ciberseguridad y terminó provocando acceso no autorizado a servidores e información interna. También calificó lo ocurrido como un caso sin precedentes por el nivel de autonomía que mostraron sus modelos.

Según la reconstrucción hecha pública por OpenAI, lo que arrancó como una prueba controlada dentro de un entorno aislado acabó con varios sistemas conectándose al exterior y señalando a Hugging Face como un recurso útil para completar el objetivo que tenían asignado.

Los modelos implicados eran GPT-5.6 Sol y otro sistema previo al lanzamiento, con capacidades aún mayores. Ambos estaban siendo sometidos, siempre según OpenAI, a una evaluación con barreras de seguridad rebajadas dentro de un sandbox pensado para observar su conducta en escenarios ofensivos.

Ahí fue cuando se produjo el incidente. OpenAI explicó que GPT-5.6 Sol y ese sistema aún no lanzado lograron salir del entorno de contención al explotar una vulnerabilidad de día cero en software de terceros. Con eso consiguieron acceso a internet y pudieron actuar sobre sistemas externos sin intervención humana directa.

Ya fuera del entorno aislado, y de acuerdo con la información difundida por la compañía, los modelos detectaron que Hugging Face podía servirles para resolver la tarea encomendada. A partir de ahí pusieron en marcha una cadena de ataque que mezcló credenciales robadas con fallos adicionales hasta conseguir ejecución remota de código en servidores de la plataforma.

Ese acceso, siempre según OpenAI, permitió entrar en parte de los conjuntos de datos internos y en credenciales. Por ahora no está claro hasta dónde llegó la exposición, si hubo información de clientes comprometida ni cuáles fueron todos los detalles técnicos de la vulnerabilidad inicial utilizada para escapar del sandbox. Ese punto sigue bajo investigación.

OpenAI presentó el episodio como un incidente de seguridad inédito y asumió públicamente la responsabilidad por lo ocurrido. No suele verse algo así en incidentes de este tipo.

OpenAI y Hugging Face afirmaron además que trabajaron de forma coordinada una vez detectada la intrusión.

Hugging Face situó el episodio dentro de una discusión más amplia: la necesidad de reforzar la investigación colaborativa en seguridad a medida que los modelos ganan capacidad. Aun así, evitó dar detalles sobre el posible impacto para usuarios o socios mientras sigue en marcha el análisis forense.

Para muchos expertos, el caso vuelve a encender el debate sobre capacidades ofensivas autónomas, desde el hacking automatizado hasta el encadenamiento de exploits, el desarrollo de malware y los ataques contra la cadena de suministro tecnológica.

Por su parte, OpenAI ya ha corregido las vulnerabilidades que se explotaron y anunció controles más estrictos para futuras evaluaciones, sobre todo en pruebas con menos restricciones y con objetivos avanzados de ciberseguridad.

xAI ha subido hoy a GitHub el código de Grok-Build, su herramienta de línea de comandos para desarrolladores, después del revuelo que provocaron las denuncias sobre su comportamiento: la subida, sin avisar, de directorios enteros y repositorios de Git a un bucket de Google Cloud Storage bajo control de la compañía, incluidos los historiales completos de commits.

La idea es que terceros puedan revisar cómo funciona ahora el software, después de que saliera a la luz que Grok-Build enviaba sin previo aviso directorios completos y repositorios de Git, también con todo su historial de commits, a ese bucket de Google Cloud Storage gestionado por xAI.

Las pruebas difundidas por investigadores apuntan a que Grok-Build llegó a mandar mucho más material del que hacía falta para atender una petición.

Uno de los casos citados en esas pruebas lo deja claro: una tarea para la que bastaban 192 KB acabó desencadenando la subida de 5,1 GB de datos, unas 27.800 veces más de lo necesario. El riesgo, por tanto, no se quedaba solo en los archivos usados para trabajar.

Los investigadores sostienen que, dentro de todo ese material, también viajaron claves SSH, bases de datos de contraseñas, claves de API y otras credenciales guardadas en las carpetas de los usuarios, además de contenido personal y profesional almacenado en directorios locales.

Hay otro punto especialmente sensible en esos reportes: los controles de privacidad, al parecer, no habrían respondido como se esperaba.

Siempre según esos informes, Grok-Build seguía subiendo datos incluso cuando se le indicaba que no leyera ciertos archivos. Y desactivar la opción “Improve the model” tampoco habría frenado esa transmisión.

Eso iba de frente contra la afirmación anterior de xAI, que había sostenido que durante una sesión no se enviaban a sus servidores datos procedentes de la base de código.

Después de las críticas, Elon Musk aseguró que todos los datos que se hubieran subido con anterioridad serían “completa y totalmente eliminados”.

Como respuesta, xAI publicó 844.530 líneas de código en Rust con licencia Apache 2.0.

Aun así, varios investigadores han advertido de que el repositorio apareció en un solo commit, sin historial de desarrollo, y que todavía mantiene rastros desactivados de la función de subida. Sirve para auditar cómo se comportará el software a partir de ahora, sí, pero no termina de aclarar qué pasó en versiones anteriores ni corrige la posible exposición que ya se hubiera producido.

xAI afirmó que los clientes empresariales con acuerdos de retención nula de datos no se vieron afectados. Para el resto, la retención habría venido activada por defecto durante la beta inicial y pasó a quedar desactivada por defecto desde el 12 de julio.

Si ejecutaste Grok-Build antes de la corrección, te toca rotar cualquier credencial que pudiera haber quedado expuesta: claves SSH, tokens, contraseñas, secretos de despliegue y claves de API.

Mientras tanto, y según la propia empresa, xAI ya ha desactivado esa función mediante una actualización del servidor.