GhostJacking expone brechas de gobernanza de identidades en los agentes de IA

Google News puso de relieve GhostJacking después de que investigadores demostraran cómo un único informe de error envenenado podía dirigir a un agente de IA autorizado hacia código controlado por un atacante. El ataque tiene éxito pese a las defensas perimetrales porque el agente realiza cada paso mediante herramientas legítimas y permisos de desarrollador.

Esta distinción cambia el debate sobre seguridad. Las credenciales del agente no tienen por qué haber sido robadas, ni su software tiene por qué haber sido comprometido. En cambio, datos operativos no confiables modifican la intención del agente mientras su identidad autenticada sigue siendo válida.

La investigación subyacente denomina a la técnica más amplia “Agentjacking”, mientras que la etiqueta GhostJacking enfatiza la naturaleza casi invisible de la toma de control. Un agente sigue operando con su identidad habitual, obligando a los defensores a distinguir la automatización legítima de la intención hostil.

No se trata simplemente de otra historia de inyección de prompts. Expone una colisión entre modelos de lenguaje, telemetría confiable, integraciones de Model Context Protocol y sistemas de identidad diseñados para usuarios predecibles.

El conflicto central es claro. Las empresas quieren que los agentes investiguen incidentes y ejecuten reparaciones sin supervisión constante. Sin embargo, los permisos que hacen útiles a esos agentes también hacen que las decisiones manipuladas sean operativamente peligrosas.

El informe GhostJacking convierte una cola de errores en una vía de ataque

GhostJacking transforma información que se espera que un agente confíe en instrucciones que podría ejecutar.

El ataque descrito en el informe GhostJacking comienza con un error de software falso. Un atacante inserta texto elaborado dentro de telemetría que un agente de programación recupera posteriormente mientras investiga problemas sin resolver.

La telemetría abarca los registros, errores, trazas y datos de diagnóstico generados por el software. Los equipos de desarrollo suelen tratar este material como evidencia sobre el comportamiento del sistema, no como un canal de comandos activo.

Esa suposición se rompe cuando un modelo de lenguaje lee el material. El modelo recibe hechos de diagnóstico, comentarios, formato e instrucciones potenciales dentro del mismo flujo de texto.

Threat Labs de Tenet Security demostró este patrón usando Sentry, una plataforma de monitorización de errores que acepta eventos de aplicaciones. Sentry utiliza un Data Source Name, o DSN, para que las aplicaciones puedan enviar esos eventos al proyecto correcto.

Una aplicación de navegador suele necesitar ese DSN en código del lado del cliente. Por tanto, poseerlo puede permitir a alguien enviar un evento sin comprometer antes la red interna de la organización.

El evento del atacante contiene una descripción convincente del error y aparentes instrucciones de corrección. Cuando un agente recupera el evento a través de una integración, las instrucciones maliciosas llegan junto a datos de diagnóstico legítimos.

El modelo se enfrenta entonces a un problema de clasificación. Debe decidir si el texto describe un error, cita a una parte externa o instruye al agente para realizar una acción correctiva.

Según la investigación controlada, los agentes evaluados en ocasiones interpretaron el material implantado como pasos válidos de resolución. Después ejecutaron un paquete controlado por los investigadores con los privilegios locales del desarrollador.

Tenet afirma que su paquete de validación fue diseñado para pruebas controladas y no para actividades perjudiciales. La empresa también señala que la información recopilada fue anonimizada y tratada conforme a su proceso de divulgación.

La consecuencia de seguridad sigue yendo más allá del paquete benigno. Un comando hostil que se ejecute bajo una cuenta de desarrollador podría alcanzar variables de entorno, repositorios de código fuente, credenciales de nube o herramientas de desarrollo autenticadas.

Tenet informó haber identificado 2.388 organizaciones con credenciales de Sentry potencialmente inyectables. También indicó haber observado a más de 100 agentes actuar sobre errores inyectados durante pruebas controladas.

Estas cifras proceden del proveedor de seguridad y no han sido reproducidas de forma independiente en toda la población analizada. Deben interpretarse como una medición de la exposición observada en el estudio, no como evidencia de compromisos confirmados por delincuentes.

El cambio importante es arquitectónico. Antes, los registros eran evidencia pasiva para personas y software determinista. Los flujos de trabajo agénticos pueden transformar esos mismos registros en contexto ejecutable.

Esto crea un ciclo de retroalimentación inusual. Un control de seguridad bloquea tráfico sospechoso, registra la solicitud bloqueada y almacena el texto del atacante en una plataforma de monitorización confiable.

Más tarde, un agente de IA lee el registro almacenado para diagnosticar el incidente. El bloqueo exitoso se convierte entonces en la ruta de entrega para la siguiente etapa.

Por qué la atención de Google News importa más allá de una demostración de seguridad

La visibilidad en Google News importa porque GhostJacking conecta un riesgo abstracto de IA con un flujo de trabajo de desarrollo cotidiano.

La inyección indirecta de prompts se ha documentado durante años. Ocurre cuando se incrustan instrucciones maliciosas dentro de datos que un sistema de IA procesa mientras completa otra tarea.

El atacante no necesita colocar instrucciones en el prompt directo del usuario. La carga puede aparecer dentro de una página web, correo electrónico, documento, ticket de soporte, comentario de código o registro recuperado de una base de datos.

GhostJacking aplica esta debilidad conocida a la evidencia operativa. El objetivo no es un chatbot que responde una pregunta inofensiva. Es un agente al que se pide diagnosticar software y posiblemente ejecutar comandos correctivos.

Esa diferencia eleva el riesgo. Un chatbot podría generar una respuesta engañosa, mientras que un agente de programación con capacidades puede modificar archivos, invocar una shell o acceder a servicios autenticados.

El evento también llega durante la rápida adopción de agentes conectados a herramientas. Model Context Protocol, conocido habitualmente como MCP, ofrece a los modelos una forma estándar de comunicarse con herramientas externas y fuentes de datos.

MCP puede reducir el trabajo necesario para conectar un agente con sistemas de seguimiento de incidencias, bases de datos, repositorios, plataformas de monitorización y herramientas locales de desarrollador. No hace automáticamente confiable el contenido procedente de esos sistemas.

Una herramienta puede ser auténtica y, aun así, devolver datos controlados por un atacante. Esa distinción es fundamental para el ataque GhostJacking.

La seguridad de aplicaciones tradicional suele preguntar si un solicitante puede acceder a un recurso. En este caso, el agente autenticado tiene permiso para acceder al recurso y ejecutar la acción resultante.

La pregunta ausente es si la acción refleja la intención del usuario. La autenticación responde quién actúa, pero no demuestra por qué se eligió la acción.

NIST describe el secuestro de agentes como una forma de inyección indirecta de prompts causada por una separación deficiente entre instrucciones confiables y datos externos no confiables. Sus evaluaciones de secuestro incluyeron escenarios de ejecución remota de código, exfiltración de datos y phishing automatizado.

Los investigadores de NIST descubrieron que los ataques adaptativos tenían una importancia considerable. En una evaluación, el ataque de referencia más sólido logró una tasa de éxito del 11 por ciento contra un modelo actualizado.

Un ataque desarrollado recientemente alcanzó el 81 por ciento en el mismo entorno de prueba comunicado. El resultado no ofrece una tasa universal de fallo de modelos, pero cuestiona las afirmaciones estáticas sobre resistencia a la inyección de prompts.

Un modelo puede rendir bien frente a un conjunto de pruebas conocido y aun así fallar ante un ataque adaptado a su comportamiento. Por ello, los equipos de seguridad no pueden tratar un único benchmark como una garantía duradera.

La cobertura de Google News puede ayudar a llevar este hallazgo fuera de los círculos especializados en seguridad de IA. El flujo de trabajo afectado se parece a lo que los equipos de desarrollo ya quieren que hagan los agentes: inspeccionar un problema, identificar una causa y aplicar una solución.

Por tanto, el artículo no advierte sobre una superinteligencia hipotética. Trata de una herramienta de automatización conocida que opera con credenciales conocidas frente a servicios en la nube conocidos.

Esa familiaridad es precisamente lo que facilita subestimar el riesgo. Cada componente puede parecer legítimo cuando se examina por separado.

El servicio Sentry es legítimo. La integración MCP es legítima. El agente de programación es legítimo y la cuenta del desarrollador está autenticada.

El elemento hostil existe en la transición entre los datos y la intención. Los controles de identidad actuales rara vez inspeccionan esa transición.

La gobernanza de identidades de agentes de IA se detiene en la autenticación

La gobernanza de identidades de agentes de IA falla cuando verifica al actor, pero no puede verificar la autoridad detrás de cada decisión.

Los sistemas de identidad humana suelen comenzar con una persona, una cuenta y permisos asignados. Los administradores pueden revisar quién posee la cuenta y a qué recursos puede acceder.

Las cuentas de servicio extienden ese modelo a las aplicaciones. Funcionan razonablemente bien cuando el software sigue código determinista y realiza una función limitada y documentada.

Un agente de IA se comporta de forma diferente. Su próxima acción depende de objetivos en lenguaje natural, contexto recuperado, razonamiento del modelo, herramientas disponibles y pasos previos dentro de un flujo de trabajo.

El mismo agente autenticado puede revisar un error, editar un repositorio, llamar a un servicio de despliegue y enviar mensajes a un equipo. Su rol efectivo cambia a medida que evoluciona la tarea.

Las organizaciones suelen gestionar esta complejidad permitiendo que el agente herede el acceso existente de un usuario. Este enfoque simplifica el despliegue, pero debilita la atribución.

Un registro de auditoría puede mostrar que una cuenta de desarrollador inició un paquete. Puede no mostrar si el desarrollador solicitó ese paquete exacto o revisó primero el comando.

También puede omitir qué documento recuperado influyó en el modelo. Sin esa procedencia, los investigadores ven la acción final, pero no la cadena de autoridad que hay detrás.

La encuesta sobre seguridad de agentes de Cloud Security Alliance ilustra la brecha de preparación. El cuarenta por ciento de las organizaciones encuestadas informó tener agentes en producción, mientras que otro 31 por ciento los estaba probando.

Solo el 18 por ciento manifestó una alta confianza en que los sistemas de identidad existentes pudieran gestionar eficazmente las identidades de los agentes. Apenas el 21 por ciento mantenía un registro o inventario de agentes en tiempo real.

La encuesta también detectó una dependencia continuada de claves API estáticas, cuentas de servicio compartidas y combinaciones de nombre de usuario y contraseña. Estos mecanismos pueden autenticar el acceso sin representar una intención delegada.

Una identidad de agente útil debería responder a algo más que “¿qué token realizó esta solicitud?”. Debería vincular la solicitud con un propietario, tarea, herramientas aprobadas, ámbito de datos y punto de expiración.

Ese registro debería mantenerse tras la delegación. Si un agente principal crea un subagente, el hijo no debería heredar silenciosamente todos los privilegios disponibles para su progenitor.

Cada identidad delegada debería recibir únicamente la autoridad necesaria para el paso asignado. El sistema también debería conservar la relación entre el usuario, el agente principal, el subagente y la acción resultante.

GhostJacking expone lo que ocurre cuando esa cadena permanece implícita. El error malicioso no necesita robar la identidad del agente porque puede dirigir la identidad ya presente.

Esto se parece al clásico problema del diputado confundido. Un programa confiable hace un uso indebido de su autoridad después de aceptar una entrada influida por un atacante que no puede clasificar correctamente.

Los modelos de lenguaje dificultan el problema porque interpretan el contenido de forma probabilística. Una “resolución” hábilmente formateada puede parecer más accionable que una instrucción vaga del usuario.

La jerarquía de prompts ayuda a los modelos a priorizar las instrucciones del sistema y del usuario. No crea una frontera criptográfica entre la salida factual de herramientas y los comandos incrustados dentro de esa salida.

Etiquetar una fuente como no confiable también tiene límites. Tenet afirma que los agentes a veces siguieron instrucciones inyectadas incluso cuando las configuraciones les indicaban que desconfiaran del contenido externo.

Esa afirmación requiere pruebas independientes más amplias en distintos modelos y configuraciones. Sin embargo, los resultados adaptativos de NIST respaldan la advertencia más general de que las defensas basadas únicamente en instrucciones se degradan bajo presión dirigida.

Por lo tanto, la capa de identidad debe asumir que el modelo puede tomar una mala decisión. La gobernanza debería limitar las consecuencias antes de que esa decisión se convierta en una acción irreversible.

La disyuntiva central es entre acceso útil e intención verificable

Un agente se vuelve más útil a medida que obtiene acceso, pero cada permiso añadido amplía el impacto de una intención manipulada.

Un asistente de programación limitado a sugerencias aún puede producir código inseguro. Un agente de programación con acceso a la terminal puede ejecutar ese código antes de que un desarrollador lo revise.

Un agente de incidentes limitado a resúmenes puede distorsionar una investigación. Ese mismo agente con acceso a producción puede modificar la infraestructura mientras sigue un registro de diagnóstico contaminado.

Esto crea una disyuntiva práctica, no un motivo para rechazar toda automatización basada en agentes. Las organizaciones deben vincular la autonomía con controles progresivamente más sólidos.

El acceso de solo lectura debería seguir siendo el predeterminado para el descubrimiento y el diagnóstico. El acceso de escritura debería concederse para tareas, recursos y ventanas de tiempo específicos.

La ejecución de comandos merece una frontera independiente. Un agente que puede recuperar datos de monitorización no debería recibir automáticamente permiso ilimitado para ejecutar cualquier cosa que esos datos recomienden.

Las acciones de alto riesgo también necesitan autorización semántica. Esto significa evaluar el propósito y el contexto de una acción, no solo comprobar si quien llama posee un token válido.

Por ejemplo, una política puede permitir que un agente ejecute un comando de prueba aprobado dentro de un espacio de trabajo aislado. La misma política puede denegar la instalación de paquetes, el acceso a credenciales o las conexiones salientes.

Esas decisiones deberían tomarse fuera del modelo. Pedir al mismo agente potencialmente manipulado que evalúe su propio comando no establece un control independiente.

La aplicación de políticas en tiempo de ejecución proporciona una separación más sólida. Una puerta de enlace puede inspeccionar cada llamada a herramienta solicitada, compararla con la política y bloquear las acciones fuera de la tarea aprobada.

La puerta de enlace también crea un lugar para registrar evidencia estructurada. Esa evidencia puede incluir la identidad solicitante, el objetivo del usuario, la fuente recuperada, la operación solicitada, la decisión de política y el resultado.

La aprobación humana sigue siendo útil cuando el impacto potencial es alto. Sin embargo, un cuadro de confirmación genérico no es suficiente.

La persona revisora necesita ver qué hará el comando, a qué archivos o sistemas puede acceder y qué contenido externo lo activó. De lo contrario, la aprobación se convierte en otro clic rutinario.

El aislamiento en entornos controlados limita los daños cuando falla la autorización. Un agente de programación puede trabajar dentro de un entorno desechable sin acceso a credenciales de producción ni conexiones de red sin restricciones.

Las credenciales de corta duración también reducen la exposición persistente. El agente debería obtener un token de alcance limitado para la operación actual y perder esa autoridad cuando termine la tarea.

La investigación de Microsoft sobre AutoJack refuerza la misma lección de diseño mediante un mecanismo diferente. Contenido web no confiable llegó a una ruta local de control MCP y pudo generar procesos en una compilación de desarrollo.

Microsoft informó que la superficie afectada se reforzó antes de llegar a la versión empaquetada correspondiente. El hallazgo más amplio sigue siendo importante porque el agente disolvió una frontera que normalmente se considera confiable.

Un navegador humano que visita una página externa normalmente no se convierte en el proceso local de automatización. Un navegador controlado por un agente puede ocupar ambos roles simultáneamente.

El ataque GhostJacking cruza una frontera semántica, mientras que AutoJack cruzó fronteras entre la web, localhost y el plano de control. Ambos casos muestran cómo los agentes conectan dominios de seguridad que los controles anteriores mantenían separados.

Esa comparación presiona al mismo tiempo a los proveedores de identidad, proveedores de modelos, marcos de agentes y equipos de seguridad empresarial. Ninguno puede resolver el problema por sí solo.

Los desarrolladores de modelos pueden mejorar la resistencia frente a instrucciones maliciosas. Los desarrolladores de marcos pueden etiquetar datos y restringir herramientas.

Los proveedores de identidad pueden emitir credenciales de carga de trabajo con alcance limitado y preservar la delegación. Las empresas aún deben definir la propiedad, los umbrales de aprobación y la autonomía aceptable.

El diseño correcto asume que cada capa puede fallar. Un modelo resistente debería seguir operando con el principio de mínimo privilegio, y una identidad bien delimitada debería seguir enfrentando comprobaciones de políticas en tiempo de ejecución.

Lo que la evidencia de GhostJacking aún no demuestra

La demostración revela una clase de ataque creíble, pero no prueba una explotación criminal generalizada ni un fallo universal de los agentes.

Las cifras más elevadas reportadas provienen de Tenet Security, que también vende protección para sistemas basados en agentes. Esa posición comercial no invalida los hallazgos, pero hace especialmente importante la replicación independiente.

La cifra de 2.388 organizaciones describe condiciones de exposición detectadas. No significa que los atacantes hayan comprometido con éxito a cada organización ni que cada una conectara activamente datos de Sentry con un agente dotado de permisos.

Asimismo, más de 100 acciones de agentes observadas procedieron de investigación controlada. El resultado demuestra viabilidad y escala dentro de la prueba reportada, no una tasa de brechas medida en toda la industria del software.

Las configuraciones de los productos también varían. Algunos agentes requieren aprobación antes de ejecutar comandos de shell, mientras que otros operan dentro de contenedores o espacios de trabajo restringidos en la nube.

Distintos modelos pueden interpretar la misma carga útil de forma diferente. Su comportamiento también puede cambiar tras actualizaciones, nuevos prompts del sistema o formatos modificados de respuesta de herramientas.

La superficie de ataque depende de los permisos. Un agente con acceso de solo lectura dentro de un repositorio aislado presenta menos riesgo que uno que posee claves de nube y acceso irrestricto a la terminal.

Estas diferencias hacen que una única tasa de fallos en titulares resulte engañosa. Los equipos de seguridad necesitan pruebas basadas en sus modelos, herramientas, credenciales y reglas de aprobación reales.

El nombre “GhostJacking” también puede generar confusión. Los materiales publicados por Tenet utilizan principalmente “Agentjacking” para la técnica de errores envenenados.

GhostJacking se entiende mejor como una etiqueta descriptiva para una toma de control invisible de un agente, no necesariamente como una categoría de vulnerabilidad estandarizada independiente. El mecanismo central sigue siendo la inyección indirecta de prompts seguida del uso autorizado de herramientas.

Tampoco existe un parche universal de plataforma. Filtrar una carga útil conocida puede detener una demostración sin resolver el problema general de las instrucciones frente a los datos.

Bloquear encabezados de Markdown, comandos de gestores de paquetes o frases específicas invita a los atacantes a reformatear la misma intención. Las evaluaciones adaptativas muestran repetidamente por qué las defensas basadas solo en firmas envejecen rápidamente.

Por el contrario, afirmar que el problema es completamente imposible de resolver exageraría la evidencia. Un mejor entrenamiento de modelos, el etiquetado de datos, el aislamiento de herramientas y la aplicación de políticas pueden reducir el riesgo.

El objetivo realista no es una detección perfecta dentro del modelo. Es impedir que una interpretación errónea se convierta en una ejecución sin restricciones.

Las organizaciones deberían comenzar con un inventario. Los equipos no pueden gobernar agentes cuya existencia desconocen, incluidas las herramientas locales de desarrolladores y las integraciones experimentales.

Cada agente necesita una persona propietaria identificada y un propósito documentado. Los equipos de seguridad deberían registrar sus modelos, herramientas, fuentes de datos, credenciales, entornos de ejecución y rutas de delegación.

El contenido influido externamente necesita una clasificación explícita. Los registros, tickets, comentarios de repositorios, correos electrónicos y páginas web deberían entrar al agente como datos no confiables.

Los permisos de herramientas deberían seguir siendo independientes de la clasificación del contenido. Una fuente no confiable nunca debería obtener autoridad simplemente porque un conector confiable la recuperó.

Después, los equipos deberían probar cadenas de ataque realistas. Los ejercicios de red team deben incluir telemetría envenenada, tickets manipulados, páginas web hostiles, descripciones de herramientas comprometidas y texto de remediación engañoso.

Las pruebas deberían medir resultados, no solo si el modelo repite una frase maliciosa. La cuestión crucial es si el agente solicita o completa una acción no autorizada.

Qué deberían seguir los lectores de Google News

La siguiente etapa estará determinada por los controles en tiempo de ejecución, los estándares de identidad y la evidencia procedente de implementaciones reales.

La primera señal es la replicación independiente. Los investigadores deberían probar la cadena de telemetría envenenada en versiones actuales de agentes de programación, modos de aprobación, entornos aislados y políticas empresariales.

Una replicación que confirme altas tasas de ejecución reforzaría el argumento a favor de la aplicación obligatoria de políticas en tiempo de ejecución. Tasas más bajas bajo configuraciones reforzadas identificarían controles que ya funcionan.

La segunda señal es la separación a nivel de producto entre los datos recuperados y las instrucciones ejecutables. Los protocolos de herramientas necesitan formas estructuradas de describir la procedencia, la confianza y el uso permitido.

Un modelo debería saber que un texto procede de un campo de evento no autenticado. Más importante aún, la capa de ejecución debería negar a ese texto la autoridad para solicitar un comando.

Conviene observar si las plataformas de agentes adjuntan procedencia verificable a las respuestas de herramientas y la preservan durante el razonamiento de varios pasos. Las simples etiquetas de advertencia ofrecerán un valor limitado sin aplicación de políticas.

La tercera señal es una infraestructura de identidad diseñada para la delegación. Las empresas necesitan credenciales de agentes de corta duración, alcances vinculados a tareas, inventarios en tiempo real y relaciones auditables entre entidades principales y subordinadas.

El progreso se hará visible cuando los sistemas de identidad puedan responder una pregunta precisa: ¿qué persona autorizó a este agente, para qué objetivo y bajo qué límites?

Estas señales importan más allá de la programación. Los agentes de atención al cliente leen tickets, los agentes financieros procesan documentos y los agentes de seguridad investigan alertas.

Cualquier flujo de trabajo que combine contenido no confiable con herramientas privilegiadas contiene el mismo riesgo estructural. El canal de entrega específico cambiará, pero el problema de la autoridad permanece.

La atención de Google News da a GhostJacking un nombre memorable. La lección duradera es menos dramática y más trascendental: la autenticación por sí sola no puede establecer una intención confiable.

Los equipos de seguridad deberían ahora mapear cada lugar donde un agente lee contenido influido externamente antes de actuar. Empiecen por registros, tickets, correo electrónico, repositorios y herramientas web.

Después, identifiquen qué acciones pueden modificar datos, ejecutar código, exponer secretos o contactar sistemas externos. Coloquen comprobaciones de políticas independientes entre esas entradas y los resultados.

No esperen pruebas de una campaña de explotación masiva. Utilicen el ataque reportado como una advertencia controlada y prueben si sus agentes pueden reproducirlo.

Si un agente no puede explicar quién delegó su autoridad, qué fuente dio forma a su decisión y por qué se permitió una llamada a herramienta, no está plenamente gobernado.