Los navegadores con IA son una nueva frontera de confianza

Los navegadores con IA no son arriesgados por añadir un chatbot a una pestaña. El riesgo aparece cuando el chatbot se convierte en agente: lee páginas, sigue enlaces, pulsa botones, recuerda contexto y actúa dentro de sesiones donde el usuario ya inició sesión. Entonces deja de ser una comodidad de búsqueda. Se convierte en una nueva frontera de confianza dentro del navegador.

Dos investigaciones recientes lo muestran bien. University of Washington estudió siete agentic browsers y encontró que cuatro creaban condiciones para saltarse la same-origin policy, la regla que impide que un sitio lea datos de otro. Su proof of concept completo fue sobre ChatGPT Atlas. También describieron condiciones similares en Chrome with Gemini, Claude for Chrome y Perplexity Comet. Por otro lado, LayerX presentó BioShocking, un ataque que convence al navegador con IA de que está en una realidad de juego, hasta que sus guardrails dejan de ser una barrera real.

No hay que entrar en pánico ni borrar toda herramienta de IA. Sí hay que dejar de tratar un agentic browser como un navegador normal con autocompletado más listo. La web se construyó sobre separación. Los agentes la difuminan porque leen el texto como contenido y como instrucción al mismo tiempo.

Same-origin policy sin jerga

La same-origin policy es una de las razones silenciosas por las que la web funciona. Una tienda, el correo y el banco pueden estar abiertos en el mismo navegador, pero un script de un origen no debería leer libremente los datos de otro. MDN define el origen por esquema, host y puerto. En la práctica: una página cualquiera no debería poder extraer su correo solo porque ambas pestañas están abiertas.

Esa protección existe desde los años noventa. Casi nadie la ve, pero permite mantener muchas sesiones abiertas sin convertir cada página en una ventana hacia todas las demás.

Un agentic browser añade un actor nuevo. El agente puede inspeccionar una página, resumirla, usar contenido incrustado, recordar páginas anteriores y actuar con los privilegios del usuario. Si una página maliciosa consigue inyectar instrucciones en lo que el agente lee, no necesita un ataque web clásico. Puede pedirle al agente que cruce la frontera.

Qué encontró UW

El trabajo de UW es útil porque habla de diseño, no de miedo. El equipo examinó Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode y Perplexity Comet. Las pruebas fueron a comienzos de 2026, así que los productos pueden cambiar. La lección sigue siendo válida.

En los diseños menos restrictivos, una página maliciosa que logra prompt injection puede hacer que el agente mezcle información entre origins. UW demostró un ataque completo en ChatGPT Atlas en Agent Mode: un sitio obtuvo información de otro sitio incrustado, algo parecido a un anuncio dentro del correo leyendo contenido del buzón. En Chrome with Gemini, Claude for Chrome y Perplexity Comet hallaron precondiciones para ataques parecidos.

También señalaron cross-origin action forgery, exposición de campos enmascarados como contraseñas y chat memory poisoning. Esto último importa porque los agentes comprimen y reutilizan lo que han visto. Si la memoria mezcla datos de origins distintos, la vieja separación del navegador ya no basta.

Qué añade BioShocking

LayerX mira el problema desde otro ángulo. BioShocking no ataca directamente la same-origin policy, sino el modelo de seguridad del agente. La página maliciosa crea un mundo de juego donde las respuestas equivocadas ganan. Cuando el agente acepta esa lógica falsa, puede ser empujado hacia acciones que sus guardrails normales rechazarían.

LayerX dijo que su proof of concept funcionó contra varios navegadores y asistentes, incluidos ChatGPT Atlas, Perplexity Comet, Fellou, Genspark Browser, Sigma Browser y el plugin de Claude para Chrome. Los escenarios incluyen exponer información sensible, cambiar contraseñas o filtrar credenciales. Ars Technica y The Hacker News lo cubrieron porque la lección es clara: los guardrails no son access control.

Una regla de rechazo de un LLM es una capa de política. La seguridad del navegador necesita límites duros. Si el mismo agente ve una página maliciosa, una página privada y además puede actuar dentro de una sesión autenticada, un prompt listo puede unir espacios que deberían seguir separados.

Qué puede salir mal

Los riesgos realistas son más aburridos que una película de hackers. Y por eso son peligrosos.

Un usuario pide resumir una página. Texto oculto en esa página ordena al agente incluir datos de otra pestaña, copiar un código de un solo uso, abrir un documento privado o pegar un resumen en un formulario del atacante. Un empleado usa el agente con CRM mientras tiene abiertos correo, GitHub, calendario y consolas internas. Un comentario malicioso en un issue o una página de documentación le pide traer secretos de otro sitio y presentarlos como contexto normal.

Algunos escenarios son proof of concept, no ataques masivos confirmados. Conviene decirlo. Pero un proof of concept basta para planificar riesgos cuando el activo es un perfil de navegador ya autenticado. Una extensión con demasiados permisos es peligrosa. Un agente lo es más porque interpreta lenguaje, planifica y mueve datos entre pasos.

Reglas para usuarios y empresas

Si va a probar un navegador con IA, use un perfil separado. No mezcle banca, consolas de trabajo, repositorios privados, correo y password manager en el mismo perfil donde el agente puede actuar.

Desactive las acciones automáticas cuando sea posible. El agente debería pedir permiso antes de enviar formularios, comprar, copiar datos entre sitios, abrir documentos privados o usar credenciales. Si el producto no ofrece ese nivel de confirmación, manténgalo lejos de sesiones sensibles.

Las empresas deben tratar estos navegadores como automatización privilegiada, no como una actualización normal. Definan qué productos se permiten, qué identidades usan, qué sitios quedan prohibidos y si el agente puede actuar o solo leer. Separar perfiles, usar controles de endpoint, aislamiento de navegador, allowlists y monitoreo de tráfico AI-browser no es exageración. Es higiene básica.

La formación también debe cambiar. La gente ya entiende enlaces sospechosos. Menos gente entiende instrucciones sospechosas escondidas dentro de una página normal. El mensaje correcto no es "los navegadores con IA son malos". Es: el contenido web no confiable puede convertirse en una instrucción para el agente.

Qué deben arreglar los proveedores

No basta con mejorar el safety prompt. Los agentic browsers necesitan memoria consciente del origen, límites de permisos estrictos, confirmaciones por acción, separación fiable de contenido incrustado, logs claros y valores por defecto con pocos permisos. En el trabajo de UW, los diseños que daban menos privilegios parecían más seguros, aunque fueran menos mágicos.

El veredicto tranquilo es simple: separar, limitar y confirmar. Separe el uso del agente de las cuentas sensibles. Limite lo que puede leer y hacer. Confirme cualquier acción que mueva datos, gaste dinero, use credenciales o toque sistemas de trabajo.

Un navegador solía ser un visor con paredes fuertes entre sitios. Un navegador con IA se parece más a un asistente caminando por esas habitaciones con una libreta. Hasta que esas paredes se rediseñen para agentes, no le dé todas las llaves.