El secuestro sin clic expone un riesgo de seguridad fundamental en los navegadores con IA

Google News ha puesto de relieve una advertencia: los navegadores con IA pueden ser secuestrados sin que la víctima haga clic, apruebe o abra conscientemente un comando malicioso. Investigadores de seguridad afirman que contenido manipulado puede redirigir a un agente mientras realiza una tarea habitual. La misma automatización que ahorra tiempo puede entonces exponer archivos, credenciales, mensajes o cuentas autenticadas.

La investigación se centra en PleaseFix, una clase de vulnerabilidad que Zenity Labs presentó en marzo de 2026 y amplió en Black Hat USA. A diferencia de la ingeniería social convencional, el ataque se dirige al software que actúa en nombre del usuario. Una invitación de calendario, publicación social, sitio web o formulario de boletín puede convertirse en el canal de instrucciones.

Esto crea un conflicto que los fabricantes de navegadores no pueden descartar como otro fallo aislado. Los navegadores con IA necesitan un acceso amplio para completar tareas útiles en distintos sitios web. Ese acceso se vuelve peligroso cuando el agente no puede separar de forma fiable el objetivo del usuario de las instrucciones insertadas en contenido no confiable.

Dark Reading informó que investigadores de Zenity identificaron vías de ataque en los principales diseños de navegadores agénticos, incluidos productos conectados con OpenAI, Google, Anthropic, Microsoft y Perplexity. La cuestión importante ya no es si un producto necesita un parche. Es si la navegación autónoma puede preservar los límites de seguridad web conocidos mientras actúa con la autoridad del usuario.

PleaseFix convierte el contenido cotidiano en un detonante de ataque

PleaseFix desplaza la ingeniería social de persuadir a una persona a redirigir al agente que ya cuenta con la autoridad de esa persona.

Los ataques ClickFix tradicionales convencen a los usuarios de realizar una acción insegura, a menudo copiando un comando o aprobando una solicitud sospechosa. PleaseFix elimina ese cuello de botella humano. En su lugar, un atacante introduce instrucciones allí donde un navegador con IA las encontrará durante un flujo de trabajo normal.

Zenity reveló inicialmente PleaseFix el 3 de marzo de 2026. Sus investigadores demostraron dos vías de explotación relacionadas con Perplexity Comet. Una podía utilizar una invitación de calendario para dirigir al agente del navegador hacia archivos locales y enviar su contenido a un destino controlado por el atacante.

La segunda vía apuntaba a flujos de trabajo de gestión de contraseñas. Según Zenity, el atacante no necesitaba explotar directamente el gestor de contraseñas. El contenido malicioso redirigía al agente del navegador mientras operaba dentro de una sesión autenticada.

Perplexity corrigió el problema subyacente del lado del navegador antes de la divulgación pública. Zenity indicó que 1Password confirmó que la causa raíz no estaba dentro de su gestor de contraseñas. Esta distinción importa porque el agente actuaba como intermediario autorizado entre sistemas que, por lo demás, eran legítimos.

La categoría técnica es la inyección indirecta de prompts. Esto ocurre cuando un modelo de IA trata datos no confiables como una instrucción, aunque el usuario nunca haya emitido esa instrucción. Una página web, correo electrónico, documento o evento de calendario puede contener el texto malicioso.

El ataque puede permanecer oculto mientras el agente completa la tarea visible. Un usuario podría pedir a un navegador con IA que acepte una invitación o resuma una página. El agente puede devolver la respuesta esperada mientras realiza una acción adicional elegida por el atacante.

El cofundador y CTO de Zenity, Michael Bargury, describió el fallo como una quiebra de confianza del agente, no simplemente como un gestor de contraseñas o sitio web defectuoso. La investigación de PleaseFix de la empresa afirma que la instrucción inyectada hereda cualquier acceso que el usuario haya otorgado al agente.

Ese acceso heredado cambia el impacto. Una página web comprometida normalmente opera dentro de las restricciones del navegador. Un agente comprometido puede navegar por pestañas, leer servicios conectados, introducir texto, hacer clic en controles e invocar otras herramientas.

En Black Hat, los investigadores ampliaron el hallazgo más allá de las demostraciones originales de Comet. Describieron una técnica denominada colisión de intenciones. Evita indicarle directamente a un agente que abandone la solicitud del usuario.

En cambio, el contenido malicioso ofrece una definición falsa de cómo debe completarse la solicitud. Si el usuario pide suscribirse a un boletín, el ataque puede decirle al agente que una acción maliciosa no relacionada forma parte del registro.

El agente sigue pareciendo alineado con la tarea original. Simplemente ha aceptado una ruta controlada por el atacante para completarla. Esto hace menos eficaces las comprobaciones simples de instrucciones que resultan obviamente contradictorias.

Los reportes de Dark Reading de julio señalaron que Zenity encontró diseños y garantías de seguridad sustancialmente diferentes entre los navegadores agénticos. Sin embargo, los investigadores dijeron que cada producto exponía alguna vía de ataque. Ese patrón convierte el secuestro de agentes sin clic en un problema de categoría.

Un único parche puede cerrar una cadena demostrada. No elimina la colisión subyacente entre contenido no confiable, decisiones autónomas y acceso autenticado.

Por qué los navegadores con IA someten a presión los límites web conocidos

Un navegador con IA gana utilidad al cruzar límites que los navegadores convencionales dedicaron décadas a imponer.

La política del mismo origen es uno de esos límites. En general, impide que el contenido de un sitio web lea o manipule contenido perteneciente a otro. Una página maliciosa no debería obtener acceso a una sesión abierta de banca, correo electrónico o trabajo.

Los agentes de navegador complican ese modelo porque la actividad entre sitios forma parte de su propósito. Una tarea de viaje puede requerir leer un sitio de reservas, comparar mapas, abrir el correo electrónico, introducir datos de pago y actualizar un calendario. El agente necesita una visibilidad más amplia que la que recibe cualquier página web individual.

Investigadores de la University of Washington probaron siete navegadores agénticos a principios de 2026. Su estudio sobre el mismo origen examinó Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode y Perplexity Comet.

El equipo demostró un ataque completo de robo de datos entre orígenes contra ChatGPT Atlas en Agent Mode. Los investigadores también encontraron condiciones para ataques relacionados en Chrome with Gemini, Claude for Chrome y Perplexity Comet si la inyección de prompts tenía éxito.

En la prueba de concepto, un sitio malicioso incrustaba contenido de otro origen. Una instrucción inyectada dirigía al agente a leer ese contenido y colocarlo en un formulario que se enviaba automáticamente. El agente se convirtió en el puente que el código ordinario del navegador tenía prohibido crear.

Los investigadores no afirmaron que todos los productos evaluados sufrieran la misma explotación completa. Su hallazgo era más estructural. Varios diseños reducían la eficacia de la política del mismo origen a la eficacia de las defensas contra la inyección de prompts.

Es una dependencia exigente. La inyección de prompts no es una firma convencional que los defensores puedan bloquear de forma fiable de una vez y para siempre. Los atacantes pueden reformular una instrucción, ocultarla en contenido visual, dividirla entre elementos o presentarla como parte de la tarea.

Una persona podría ignorar texto tenue o metadatos de página inaccesibles. Un agente multimodal puede extraer esa información y actuar sobre ella. Cloud Security Alliance señala que investigadores han demostrado instrucciones con colores que los humanos tienen dificultades para percibir, pero que los sistemas de IA aún pueden leer.

La memoria crea otro problema de límites. Los agentes pueden comprimir la actividad previa en resúmenes que influyen en el comportamiento posterior. Si contenido hostil llega a esa memoria, su fuente original puede volverse menos visible durante decisiones futuras.

LayerX describió anteriormente Tainted Memories, un ataque que introducía instrucciones maliciosas en la memoria de ChatGPT Atlas. Otras divulgaciones han utilizado fragmentos de URL, documentos compartidos y rutas de recuperación del lado del servidor para entregar instrucciones adversarias.

Estos métodos difieren, pero explotan la misma ambigüedad. El modelo recibe la intención del usuario y el contenido externo a través de canales que no proporcionan una procedencia de instrucciones fiable.

La procedencia de las instrucciones significa saber quién proporcionó un comando y qué autoridad debe tener. El software convencional puede etiquetar código, entradas, permisos y procesos mediante estructuras técnicas explícitas. Los modelos de lenguaje suelen recibir estos elementos como texto dentro de un contexto compartido.

Por ello, los navegadores con IA presionan a los equipos de seguridad en dos direcciones. Restringir el acceso reduce el daño, pero también reduce las tareas que un agente puede completar. Ampliar el acceso mejora la automatización y, al mismo tiempo, aumenta las consecuencias de una mala decisión.

El equipo de la University of Washington observó que el navegador menos arriesgado en sus pruebas también tenía las capacidades más limitadas. Ese hallazgo recoge la disyuntiva central. La capacidad y la exposición están aumentando mediante muchas de las mismas decisiones de diseño.

Los titulares de Google News ocultan un problema más profundo de permisos

El titular trata sobre prompts maliciosos, pero el fallo de seguridad más amplio se refiere a permisos que persisten después de que el agente interpreta mal una instrucción.

Google News puede hacer que el secuestro de agentes sin clic parezca otra historia sobre una vulnerabilidad que evoluciona rápidamente. Ese encuadre corre el riesgo de centrar la atención en la carga útil ingeniosa en lugar de en la autoridad disponible después de que la carga útil funciona.

Un asistente de IA que solo resume páginas públicas tiene un radio de impacto limitado. Un agente que puede leer correo electrónico, acceder a archivos locales, usar credenciales almacenadas, enviar mensajes a contactos y realizar compras presenta un riesgo diferente.

El ataque no necesita vulnerar cada servicio conectado de forma independiente. Puede manipular al agente que ya ha sido autorizado a utilizarlos. La autenticación legítima pasa a formar parte de la cadena de ataque.

Esto se asemeja a un delegado confundido, un problema de seguridad en el que un componente de confianza utiliza indebidamente su autoridad en favor de otra parte. El navegador con IA cree que está sirviendo al usuario mientras un atacante influye en cómo interpreta el objetivo del usuario.

PleaseFix demuestra este problema mediante contenido cotidiano. Otras investigaciones lo extienden a distintos canales de entrega. GeminiJack supuestamente utilizó documentos compartidos de Google que contenían instrucciones ocultas. HashJack colocó instrucciones después del símbolo hash en las URL, una zona que los controles de red pueden ignorar.

ZombieAgent apuntó al comportamiento de recuperación en un agente de investigación con IA. CometJacking utilizó parámetros de consulta manipulados y requería un clic. Las variaciones muestran que los defensores no pueden proteger únicamente las páginas web mientras dejan sin tratar el correo electrónico, los documentos, la memoria y las respuestas de herramientas.

NIST ha definido el secuestro de agentes como una forma de inyección indirecta de prompts que provoca que un agente persiga el objetivo de un atacante. Sus evaluaciones de secuestro hacen hincapié en comprobar si los agentes completan objetivos maliciosos ocultos dentro de los recursos que procesan.

Ese enfoque de evaluación es importante porque un sistema puede parecer seguro durante tareas habituales de evaluación comparativa. También puede bloquear una frase de inyección conocida y seguir siendo vulnerable a una instrucción redactada de otra manera.

La colisión de intenciones dificulta más el problema de las pruebas. El contenido hostil no siempre contradice la solicitud del usuario. Puede afirmar que el paso malicioso es necesario para completar la solicitud.

Una comprobación de alineación limitada podría ver una solicitud de registro en un boletín seguida de interacciones con formularios y concluir que el plan sigue siendo pertinente. También debe detectar que una acción propuesta cruza hacia un origen, herramienta o privilegio no relacionado.

Por lo tanto, los permisos deberían vincularse a una tarea específica, no simplemente a la identidad general del agente. Una solicitud para resumir una página web no requiere acceso a un gestor de contraseñas. Aceptar una invitación de calendario no debería autorizar la carga de archivos locales.

Los permisos de corta duración y acotados a una tarea reducirían el radio de impacto. También lo haría una separación explícita entre acceso de lectura y acceso de escritura. Un agente podría inspeccionar varias fuentes sin recibir autoridad para transmitir su contenido a otros lugares.

El mismo principio se aplica a los despliegues empresariales. Un agente de navegador conectado a registros de clientes, documentos internos, repositorios de código y sistemas de mensajería no debería recibir un único conjunto de permisos indiferenciado.

Los equipos de seguridad también necesitan visibilidad sobre las acciones de los agentes. Los registros tradicionales pueden mostrar una sesión de usuario autenticado que realiza solicitudes válidas. Puede que no muestren si esas solicitudes procedían de la persona, del planificador del agente o de contenido adversario.

Esto debilita la lógica de detección conocida. Puede que no haya una contraseña robada, un ejecutable sospechoso ni un inicio de sesión no autorizado. La actividad dañina puede producirse a través de un navegador aprobado en un dispositivo aprobado.

Para los compradores empresariales, la pregunta clave sobre el producto no es si un navegador incluye filtrado contra inyecciones de prompts. Deberían preguntar cómo el sistema delimita la autoridad, registra las fuentes de las instrucciones, aísla los orígenes y detiene el movimiento inesperado de datos.

Los fabricantes de navegadores están construyendo salvaguardas, pero ninguna elimina la disyuntiva

Las defensas por capas pueden interrumpir rutas de ataque conocidas, pero ninguna arquitectura publicada elimina la tensión subyacente entre autonomía y control.

Google identifica abiertamente la inyección indirecta de prompts como la principal nueva amenaza para los navegadores agentivos. Sus defensas propuestas para Chrome combinan entrenamiento de modelos, restricciones de origen, revisión de acciones, detección de amenazas y confirmaciones para pasos críticos.

Uno de los componentes es el User Alignment Critic. Este modelo independiente revisa una acción planificada y decide si cumple el objetivo declarado por el usuario. Google afirma que el crítico recibe metadatos de la acción sin ver el contenido sin filtrar de la página web que influyó en el planificador.

Esa separación reduce la probabilidad de que el mismo texto malicioso contamine tanto al planificador como a su revisor. El crítico puede rechazar una acción desalineada o pedir al planificador que elabore otro plan.

Google también describe los Agent Origin Sets. Estos limitan qué sitios web puede leer un agente y cuáles puede modificar durante una tarea. Una función de control de confianza decide si un origen pertenece al flujo de trabajo solicitado.

El diseño avanza hacia una autoridad acotada a la tarea. Sin embargo, aún debe determinar qué orígenes son legítimamente relevantes. Una solicitud de compras, viajes o investigación puede involucrar de forma natural varios sitios desconocidos.

Los atacantes pueden explotar esa ambigüedad. Una página maliciosa puede presentar otro destino como necesario para completar la tarea. Los falsos positivos también importan, porque un bloqueo excesivo hace que el agente sea menos útil.

OpenAI trata de forma similar la inyección de prompts como un desafío de seguridad continuo. Su trabajo de seguridad de Atlas describe red teaming continuo y actualizaciones de modelos, en lugar de una solución ya completada.

Microsoft ha adoptado un enfoque cauteloso respecto a las acciones agentivas en el navegador. Sus orientaciones públicas describen restricciones para abrir aplicaciones externas, introducir información sensible y realizar determinadas acciones de alto impacto. El acceso experimental también limita la exposición mientras evolucionan los diseños.

Las confirmaciones siguen siendo valiosas, especialmente antes de compras, mensajes, transferencias de archivos o uso de credenciales. Sin embargo, un cuadro de diálogo de confirmación puede fallar si presenta el encuadre del atacante en lugar de la consecuencia real.

Los usuarios también se acostumbran a aprobar avisos frecuentes. Una herramienta autónoma pierde gran parte de su atractivo si cada paso significativo exige una inspección manual detallada. Un control que los usuarios aceptan de forma rutinaria ofrece una protección limitada.

Los modelos de detección se enfrentan a una carrera adversarial. Los investigadores pueden generar nuevas formulaciones, codificaciones, imágenes e instrucciones de varios pasos. Un detector entrenado con los prompts de ayer puede no detectar una instrucción expresada mediante contexto e implicación.

Eso no vuelve inútiles las defensas. Los controles por capas obligan a los atacantes a superar varias barreras y limitan el daño cuando una de ellas falla. El problema es tratar cualquier modelo, política o advertencia individual como un límite suficiente.

La visión escéptica también exige cautela. Las afirmaciones amplias de Zenity describen una clase de vulnerabilidad y varias demostraciones, no pruebas de que todos los usuarios de navegadores con IA hayan sido comprometidos. El acceso mediante pruebas de concepto no demuestra una explotación generalizada.

Los productos también cambian rápidamente. Perplexity abordó el problema del lado del navegador revelado en marzo, mientras otros proveedores continúan modificando los controles de origen y confirmación. Un hallazgo contra una versión no debería describir automáticamente cada versión posterior.

Aun así, la ausencia de explotación masiva conocida no resuelve la preocupación arquitectónica. Los navegadores con IA actúan dentro de sesiones autenticadas de alto valor, y la comunidad de seguridad ha encontrado repetidamente vías desde contenido no confiable hasta acciones privilegiadas.

Las empresas deberían tratar estos productos como automatización privilegiada, no como software de productividad común. Las revisiones de despliegue deberían incluir las mismas disciplinas utilizadas para cuentas de servicio, automatización robótica de procesos y herramientas administrativas.

Eso implica limitar los servicios conectados, separar las sesiones personales y empresariales, desactivar el acceso de escritura innecesario y supervisar las acciones salientes. Los flujos de trabajo de alto impacto deberían conservar una verificación independiente fuera de la propia interfaz del agente.

Tres señales mostrarán si los navegadores con IA se están volviendo más seguros

La próxima prueba es si los proveedores pueden limitar la autoridad de los agentes sin reducir la navegación autónoma a una demostración supervisada.

La primera señal es la aplicación de controles de origen específicos para cada tarea. Los fabricantes de navegadores deben demostrar que los agentes no pueden mover libremente información entre sitios no relacionados solo porque ambos aparecen en una misma sesión.

Los investigadores independientes deberían repetir las pruebas entre orígenes tras las principales versiones. Una defensa eficaz impediría que una instrucción inyectada añadiera un nuevo destino, leyera contenido no relacionado o enviara información sensible.

Esto reforzaría la idea de que los navegadores con IA pueden preservar los límites fundamentales de la Web. La persistencia de robos mediante pruebas de concepto en productos actualizados demostraría que los controles de origen siguen dependiendo demasiado de decisiones falibles de los modelos.

La segunda señal es la confirmación independiente de las acciones con consecuencias. El diseño más sólido generaría la información de aprobación a partir de metadatos de acción confiables, no de la página web ni de la narrativa del planificador.

Una confirmación útil debería indicar qué datos se moverán, qué destino los recibirá y qué cuenta realizará la acción. También debería bloquear una escalada silenciosa de una tarea de solo lectura a una operación de escritura.

Los investigadores comprobarán si el contenido malicioso puede disfrazar, suprimir o replantear esas advertencias. Si las confirmaciones exponen sistemáticamente la consecuencia real, debilitarán los ataques de colisión de intención. Si los usuarios siguen viendo avisos vagos, la protección seguirá siendo frágil.

La tercera señal es una presentación transparente de incidentes y evaluaciones. Los proveedores deberían publicar qué clases de ataque prueban, qué permisos tienen sus agentes y qué acciones siempre requieren aprobación humana.

Las tasas de aprobación agregadas por sí solas no serán suficientes. Las pruebas necesitan correos electrónicos realistas, invitaciones de calendario, marcos incrustados, documentos, imágenes, componentes de URL, entradas de memoria y respuestas de herramientas. También deben incluir ataques que respalden la redacción superficial de la tarea del usuario.

OWASP sitúa la inyección de prompts entre los riesgos centrales de las aplicaciones de modelos de lenguaje. Su guía sobre inyección de prompts recomienda restringir el comportamiento del modelo, validar las salidas, separar el contenido externo y aplicar el principio de mínimo privilegio.

Los informes públicos pueden revelar si esos principios funcionan en navegadores desplegados. También pueden distinguir el progreso arquitectónico de la aplicación de parches a demostraciones individuales.

Los usuarios no necesitan abandonar todas las funciones de navegadores con IA mientras este trabajo continúa. Deberían ajustar la autoridad del agente a la sensibilidad de la tarea.

Resumir investigación pública conlleva menos riesgo que operar dentro de sesiones de correo electrónico, banca, almacenamiento en la nube o gestión de contraseñas. Los perfiles de navegador separados pueden reducir la exposición, aunque no pueden corregir un diseño de agente inseguro.

Las organizaciones deberían comenzar con cuentas limitadas y flujos de trabajo no críticos. Deberían impedir que los agentes accedan a credenciales o archivos locales, salvo que una tarea específica aprobada requiera ese acceso.

Los equipos de seguridad también deberían asumir que el contenido puede ser hostil incluso cuando su servicio de alojamiento sea confiable. Un documento compartido, evento de calendario, anuncio, ticket de soporte o mensaje interno puede contener instrucciones controladas por un atacante.

Google News seguirá mostrando descubrimientos individuales a medida que los investigadores prueben nuevos productos. Los lectores deberían mirar más allá de cada nombre de producto y preguntarse si el agente podía distinguir una intención verificada de contenido no confiable.

La evidencia decisiva vendrá de pruebas independientes repetidas. ¿Puede un agente actualizado rechazar contenido hostil, mantenerse dentro de orígenes específicos de la tarea y mostrar cada acción con consecuencias antes de ejecutarla?

Hasta que los proveedores puedan responder esas preguntas de forma consistente, el secuestro de agentes sin clic seguirá siendo más que un ciclo temporal de errores. Es el coste de otorgar a un software una autoridad amplia antes de proporcionarle una forma fiable de reconocer quién está emitiendo la orden.