Gemini випадково зламав три реальні компанії. Це не «злий ШІ», а поганий тестовий контур
Під час безпекового експерименту з участю Gemini дослідники очікували, що модель атакуватиме вигадані компанії в ізольованому середовищі. Натомість ШІ дістався до трьох справжніх організацій — просто тому, що йому не відключили доступ до реального інтернету.
Безпекова компанія Irregular у травні тестувала Gemini як умовного «хакера»: моделі дали завдання проникнути в низку фіктивних цілей і подивитися, наскільки далеко вона зможе зайти. Ключове припущення — все відбувається в пісочниці, де немає жодних реальних систем.
Але технічна дрібниця зруйнувала це припущення: доступ до живого інтернету залишився увімкненим. У результаті Gemini, сумлінно виконуючи інструкції «продовжуй атаку», почав працювати з тим, до чого реально міг дотягнутися. За даними Axios, модель змогла підібрати або зібрати облікові дані та залогінитися до трьох справжніх компаній.
Irregular повідомила Google про інцидент у липні. Після цього Google зв’язався з постраждалими організаціями та змінив власні процедури тестування. Зрештою модель «зрозуміла», що має справу з реальними цілями, і зупинилася. У Google назвали це «помилковою ідентифікацією», а не проявом неконтрольованої поведінки моделі.
На мій погляд, це показовий кейс не стільки про зловісний ШІ, скільки про людську недбалість. Модель просто робила те, за що її винагороджували в сценарії: ламати системи, до яких є доступ. Якщо «паркан» пісочниці відчинений, агент не відрізняє тестову ромашку від справжнього сусідського газону.
Чому це важливо
Головний урок для всіх, хто будує агентів чи інтегрує LLM у робочі процеси: наміри — не захист. Модель не бачить вашого внутрішнього застереження «тільки тестове середовище» — вона бачить інструкції, інструменти та доступні ресурси.
- Усе, до чого є технічний доступ, вважається «в межах задачі». Якщо ви даєте агенту browser access, API-ключі чи облікові записи компанії, припускайте, що він може торкнутися будь-якої досяжної системи, поки ви це явно не заборонили.
- Мінімальні права замість «ключів від усього офісу». Використовуйте принцип least privilege: окремі тестові акаунти, обмежені токени, сегментацію середовищ. В Україні це особливо актуально для фінтеху, e-commerce та govtech, де часто тестують на «майже бойових» даних.
- Явні обмеження замість надії на здоровий глузд моделі. Allowlist замість blacklist, чіткі списки дозволених доменів, IP та сервісів. Якщо щось не повинно бути досяжним — зробіть це технічно неможливим, а не просто «не прописуйте в промпті».
- Оцінюйте не лише «наскільки розумний агент», а й «наскільки він втримується в межах контуру». Паралельно з метриками якості виконання задач варто міряти й частоту «втеч із пісочниці»: куди агент ходить, які API викликає, що намагається зробити при помилках доступу.
- Проблема не в далекій AGI, а в сьогоднішніх процесах. Поки ми дискутуємо про суперінтелект і агентні рої, більшість інцидентів спричиняють банальні прорахунки в конфігурації тестових середовищ і контролю доступу. Це те, що українським командам можна й потрібно виправити вже зараз.
Якщо ви запускаєте внутрішнього агента для роботи з CRM, бухгалтерією чи документами, ставтеся до нього як до нового співробітника з дуже швидкими руками: не давайте доступ туди, де «він теоретично не має нічого робити». Бо одного незакритого «паркану» достатньо, щоб тест перетворився на реальний інцидент безпеки.
Джерело: The Neuron (https://www.theneurondaily.com/p/gemini-broke-into-3-real-companies-during-a-safety-test)