AI-браузеры опасны не потому, что добавляют чатбота во вкладку. Риск начинается тогда, когда чатбот становится агентом: читает страницы, переходит по ссылкам, нажимает кнопки, запоминает контекст и действует внутри сессий, где пользователь уже залогинен. Это уже не удобная строка поиска. Это новая граница доверия внутри браузера.

AI-агент в браузере упирается в границы изоляции вкладок, пока подозрительная страница пытается выполнить prompt injection

Две свежие исследовательские линии хорошо показывают проблему. Команда University of Washington изучила семь agentic browsers и нашла, что четыре создают условия для обхода same-origin policy — старого правила веба, которое не дает одному сайту читать данные другого. Полный proof of concept был показан на ChatGPT Atlas. Условия для похожих атак исследователи также описали в Chrome with Gemini, Claude for Chrome и Perplexity Comet. Отдельно LayerX показал BioShocking: атаку, где AI-браузер убеждают, что он находится в игровой реальности, и guardrails перестают работать как реальная граница.

Это не повод паниковать и запрещать все AI-инструменты. Но это повод перестать считать agentic browser обычным браузером с умной подсказкой. Веб строился на изоляции. AI-агенты смешивают контексты, потому что читают текст одновременно как данные и как инструкцию.

Same-origin policy простыми словами

Same-origin policy — одна из тихих причин, почему веб вообще работает. Магазин, почта и банк могут быть открыты в одном браузере, но скрипт с одного origin не должен свободно читать данные с другого. MDN определяет origin через scheme, host и port. Практический смысл проще: случайная страница не должна вытаскивать содержимое вашей почты только потому, что обе вкладки открыты.

Эта защита существует с 1990-х. Пользователь почти никогда ее не видит, но именно она позволяет держать много авторизованных сайтов в одном браузере и не превращать каждую страницу в окно ко всем остальным.

Agentic browser добавляет нового участника. Агент может видеть страницу, суммаризировать ее, работать с embedded content, помнить прошлые действия и действовать с правами пользователя. Если вредоносная страница внедрит инструкции в текст, который агент читает, атаке не нужен классический XSS. Она может попросить агента перейти границу самому.

Что нашла команда UW

Исследование UW ценно тем, что отделяет архитектурный риск от шума вокруг AI. Команда изучила Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode и Perplexity Comet. Эксперименты проводились в начале 2026 года, поэтому поведение продуктов может измениться. Но урок по дизайну остается актуальным.

В менее ограниченных вариантах вредоносная страница, если ей удается prompt injection, может заставить агента смешивать информацию между origins. UW показал полный proof of concept на ChatGPT Atlas в Agent Mode: один сайт получил информацию из другого embedded-сайта, примерно как если бы реклама внутри почтовой страницы смогла вытащить содержимое писем. Для Chrome with Gemini, Claude for Chrome и Perplexity Comet исследователи нашли предпосылки для похожих атак.

Также они описали cross-origin action forgery, чтение masked input вроде паролей и chat memory poisoning. Последнее особенно неприятно: агенты сжимают и переиспользуют увиденную информацию. Если данные разных origins смешиваются в памяти, старой браузерной изоляции уже недостаточно.

Что добавляет BioShocking

LayerX атакует проблему с другой стороны. BioShocking бьет не по same-origin policy напрямую, а по safety-модели агента. Вредоносная страница строит игровую реальность, где неправильные ответы считаются правильными. Когда агент принимает эту логику, его можно подтолкнуть к действиям, которые обычные guardrails должны были бы остановить.

LayerX утверждает, что proof of concept сработал на нескольких AI-браузерах и ассистентах, включая ChatGPT Atlas, Perplexity Comet, Fellou, Genspark Browser, Sigma Browser и Claude Chrome plugin. Сценарии включают утечку чувствительной информации, изменение паролей и credentials. Ars Technica, The Hacker News и другие профильные издания быстро подхватили тему, потому что она показывает простую вещь: guardrails не равны access control.

Отказ LLM — это policy layer. Браузерной безопасности нужны жесткие границы. Если один и тот же агент видит вредоносную страницу, приватную страницу и может выполнять действия в авторизованной сессии, удачный prompt становится мостом между местами, которые должны были оставаться раздельными.

Что реально может пострадать

Наиболее вероятные риски не выглядят как киношный взлом. Они скучнее и опаснее.

Пользователь просит AI-браузер суммаризировать страницу. Скрытый текст на этой странице просит агента добавить данные из другой вкладки, скопировать одноразовый код, открыть приватный документ или вставить summary в форму злоумышленника. Сотрудник дает агенту помочь с CRM, пока в том же профиле открыты почта, GitHub, календарь и админки. Вредоносный комментарий в issue или документации просит агента принести секреты из другого места и показать их как обычный контекст.

Часть этих сценариев пока proof of concept, а не массовые атаки in the wild. Это важно не преувеличивать. Но proof of concept достаточно серьезен, когда актив — уже авторизованный браузерный профиль. Обычное расширение опасно при лишних permissions. Агент опаснее, потому что понимает язык, строит план и переносит данные между шагами.

Правила для пользователей

Если хотите пробовать AI-браузер, используйте отдельный профиль. Не держите банк, рабочие админки, приватные GitHub repos, cloud dashboards, почту и password manager в том же профиле, где агенту разрешено действовать.

Отключайте автоматические действия там, где можно. Агент должен спрашивать перед отправкой форм, покупками, копированием данных между сайтами, открытием приватных документов и использованием credentials. Если продукт не дает такого подтверждения, не подпускайте его к чувствительным сессиям.

Не давайте агенту страницы, которым вы бы не доверили инструкции. Веб-страница, PDF, комментарий в issue или форумный пост могут стать для агента и контентом, и командой. Это главный сдвиг в мышлении: вы не просто читаете страницу, вы можете позволить странице поговорить с программой, которая действует за вас.

Правила для компаний

Компании должны относиться к agentic browsers как к привилегированной автоматизации, а не как к обновлению обычного браузера. Начните с policy: какие продукты разрешены, какие identities они используют, какие сайты запрещены, может ли агент действовать или только читать.

Разделяйте аккаунты и browser profiles. Не позволяйте одной сессии держать payroll, CRM, cloud admin, source control и экспериментального агента. Рассмотрите browser isolation, endpoint controls, SASE/SWG policy, allowlist расширений и мониторинг AI-browser traffic.

Перед rollout нужен threat modeling. Что агент может читать? Что нажимает? Что помнит? Куда уходят логи? Можно ли увидеть audit trail? Как пользователь отзовет доступ? Если ответы расплывчатые, инструменту не место рядом с production credentials.

Обучение тоже придется обновить. Люди уже знают про suspicious links. Намного меньше людей понимают suspicious instructions, спрятанные внутри обычной страницы. Спокойная формулировка такая: AI-браузеры не зло, но untrusted web content может стать инструкцией для агента.

Что должны исправить vendors

Безопасный путь — не просто переписать safety prompt. Agentic browsers нужны origin-aware memory, жесткие permission boundaries, confirmations на действия, надежная изоляция embedded content, понятные логи и defaults с минимальными правами. В исследовании UW варианты с меньшими правами выглядели безопаснее, пусть и менее эффектно.

Компромисс реальный. Агент, который почти ничего не видит, не кажется магическим. Агент, который видит все, похож на младшего администратора внутри всей веб-жизни пользователя. Vendors должны сделать границы видимыми, enforceable и проверяемыми. Пользователь не должен гадать, может ли функция summary прочитать masked password field.

Спокойный вывод

AI-браузеры могут стать полезными. Они пригодятся для research, сравнения товаров, планирования поездок и рутинных форм. Но их нельзя по умолчанию пускать в профиль, полный ценных сессий.

Простое правило: разделять, ограничивать, подтверждать. Отделяйте AI-agent browsing от чувствительных аккаунтов. Ограничивайте, что агент видит и делает. Подтверждайте каждое действие, которое переносит данные, тратит деньги, использует credentials или касается рабочих систем.

Браузер раньше был viewer с прочными стенами между сайтами. AI-браузер больше похож на ассистента, который ходит по этим комнатам с блокнотом. Пока стены не перестроены под агентов, не выдавайте этому ассистенту все ключи.