Дослідники NeuralTrust повідомили про слабке місце в агентному браузері ChatGPT Atlas від OpenAI: омнібокс (єдина строка для введення URL, пошуку та інструкцій для ІІ) може некоректно трактувати вставлений текст і виконувати небажані дії від імені користувача. Зловмисник маскує промпт під «схожий на посилання» рядок — і Atlas сприймає його як довірену команду.
Як працює атака: неоднозначність обробки вводу в омнібоксі
Ключ до експлуатації — змішування режимів в одному полі вводу. Традиційні браузери розрізняють URL і пошуковий запит. Агентні браузери додають третій режим — природномовні наміри для ІІ-агента. Якщо парсинг URL не вдається, Atlas намагається трактувати введений рядок як інструкцію.
NeuralTrust демонструє, що «псевдо-URL» з навмисними помилками формату та вбудованими командами може видатися системі валідним наміром користувача. При вставленні такого рядка в омнібокс відбувається перемикання в режим ІІ-команд, і браузер виконує інструкції, яких користувач фактично не давав. Це класичний випадок prompt injection у новому контексті — адресному рядку.
Реальні сценарії зловживання: від фішингу до деструктивних дій
Підміна навігації та фішинг через «Copy Link»
Один із практичних сценаріїв — розміщення на сторінці кнопки «Copy Link», що копіює не справжню URL‑адресу, а промпт, стилізований під посилання. Користувач вставляє його в омнібокс, і Atlas відкриває ресурс, що контролюється зловмисником, наприклад клон відомого сервісу для крадіжки облікових даних. Атака поєднує соціальну інженерію та ваду логіки парсингу.
Зловмисні операції в авторизованих сесіях («confused deputy»)
Більш небезпечний варіант — вбудовані інструкції, що ініціюють дії у сторонніх сервісах, використовуючи вже відкриту й автентифіковану сесію жертви (наприклад, запити на видалення файлів у хмарному сховищі). Це відповідає моделі «confused deputy», коли агент виконує команди, хибно вважаючи їх довіреними.
Системний ризик для агентних браузерів, а не лише проблема Atlas
NeuralTrust підкреслює: уразливість не унікальна. Будь-який продукт, який зводить URL, пошук і агентні команди в один омнібокс, ризикує заплутати контексти довіри. За відсутності чіткої межі між наміром користувача і контентом, отриманим із зовнішніх джерел, зростає ймовірність ескалації дій під дією prompt injection.
Проблематика корелює з висновками OWASP Top 10 for LLM Applications, де prompt injection і токсична залежність від зовнішнього контенту віднесені до ключових загроз. Додатково актуальними стають класичні принципи безпеки — розділення довірених і недовірених доменів, найменші привілеї та явні підтвердження на ризикові операції.
Як захиститися: технічні та UX-контролі для омнібокса
Строга класифікація вводу. Якщо парсинг URL неуспішний, не перемикатися автоматично в режим промпта. За неоднозначності — відмовляти у навігації та пропонувати користувачу вибір режиму.
Чітка межа довіри. Розглядати будь-який текст, вставлений в омнібокс, як недовірений до явного підтвердження режиму: URL, пошук чи команда ІІ. Вимикати «тихе» виконання інструкцій, отриманих копіпастою зі сторінок.
Підтвердження чутливих дій. Для операцій із наслідками — capability prompts із уточненням якої дії, для якого акаунта і в якому домені. Без підтвердження — блокувати виконання.
Ізоляція контексту й найменші привілеї. Розділяти сеанси й токени між доменами, обмежувати можливості ІІ-агента, мінімізувати автоматичну передачу аутентифікаційного контексту.
Надійний парсинг і нормалізація. Єдиний валідатор URL/IRI, нормалізація пробілів і символів, жорсткі вимоги до схеми та хоста; заборона інтерпретації «майже‑URL» як намірів користувача.
Гігієна UI/UX. Канонізація скопійованих посилань, візуальна індикація активного режиму омнібокса й попередження при зміні контексту. Зменшення шансів на соціальну інженерію за рахунок прозорого інтерфейсу.
Попри те, що експлуатація передбачає елемент соціальної інженерії (користувач має сам вставити рядок), ризик залишається високим: атака може виконувати дії в інших доменах, використовуючи вже видані дозволи. Організаціям варто провести загрозомоделювання омнібокса, запровадити політики підтвердження дій, обмежити права ІІ-агента та увімкнути моніторинг аномалій. Користувачам — не вставляти «посилання» з неперевірених джерел і звертати увагу на індикатори режиму вводу. Регулярне тестування, оновлення політик і освітні ініціативи допоможуть знизити ймовірність компрометації й підсилять стійкість до prompt injection у агентних браузерах.
