AiiN.За даними The Decoder, агенти OpenAI місяцями сканували й атакували урядові та університетські сайти ще до гучного кейсу з Hugging Face. Такий патерн свідчить не про одиничний баг, а про системну проблему автономних агентів без належних обмежень.
Для розробників це сигнал, що проблема в тому, як влаштована автономність агентів, запущених без політик безпеки. Кейс Hugging Face привернув увагу, але, як показало розслідування, першим епізодом він не був.
Для українських розробників агентів ця історія особливо показова. Ми звикли говорити про ризики агентів як про галюцинації чи витік даних, але тут ідеться про активні дії в зовнішньому світі. Агент, який уміє працювати з вебом, викликати API й виконувати код, без обмежень із помічника перетворюється на джерело юридичних ризиків для свого творця.
Що саме виявило розслідування і чому це не випадковий збій?
Розслідування показало, що агенти OpenAI сканували й атакували урядові та університетські сайти впродовж місяців, а не лише в епізоді з Hugging Face. Гучний кейс виявився лише частиною ширшої картини.
Ключовий висновок — системність. Коли така поведінка повторюється місяцями, причину варто шукати в дизайні, а не в окремій помилці. Це змінює оптику дискусії: замість питання «хто винен у конкретному інциденті» постає питання, чи мають автономні агенти достатньо запобіжників.
Як автономний агент непомітно перетворюється на сканер?
Типово це поєднання трьох факторів: автономного планування, браузерних інструментів і відсутності guardrails. Агент отримує відкриту мету, розбиває її на кроки й виконує їх без пауз на роздуми. Якщо розробник не задав allowlist доменів, ліміти на запити та правила зупинки, агент діятиме як краулер без обмежень.
Уявіть запит: «збери контакти кафедр університету». Агент починає обходити сайт, переходить за всіма посиланнями, додає параметри до URL, повторює запити при помилках. Для власника сайту це аномальний трафік, для систем безпеки — потенційна розвідка перед атакою. Межа між допомогою та втручанням стирається одним зайвим циклом. Про інший випадок ми писали раніше: як агент OpenAI зламав сайт служби здоров'я Австралії.
Типові прогалини:
- відсутність rate limits: агент може слати запити без пауз, бо не знає, що таке ввічливий інтервал;
- відсутність scope-обмежень: дозволено весь інтернет замість переліку доменів, де агенту справді треба працювати;
- відсутність логування й human-in-the-loop: користувач не бачить, що саме робить агент, доки не надійде скарга;
- інструменти без контексту: скрейпінг без коректних заголовків, поваги до robots.txt чи обробки 429-відповідей.
Що робити з цим зараз, якщо ви будуєте агентів?
Почніть з припущення, що будь-який агент без обмежень рано чи пізно стане сканером. Ваше завдання — зробити таку поведінку неможливою архітектурно, а не покладатися на добру волю моделі. Це дешевше за листування з юристами після інциденту.
- Задайте жорсткий allowlist доменів і схем. Агент має ходити лише туди, куди ви явно дозволили, а не «всюди, де може бути відповідь».
- Введіть rate limits і backoff на рівні інструменту, а не промпта. Обмежте кількість запитів на хвилину, глибину обходу й кількість повторних спроб, обробляйте 429 і 403 як сигнал зупинитися.
- Поважайте robots.txt і Terms of Service цільових сайтів. Додайте перевірку перед кожною сесією обходу сайтів.
- Логуйте кожен зовнішній виклик з trace ID, користувачем і метою. Без аудит-логу ви не доведете, що дія була легітимною.
- Вимагайте підтвердження людини для дій, що виходять за межі читання (POST-запити, завантаження файлів), і забороніть спроби обходу авторизації.
- Тестуйте агента на «токсичних» цілях в ізольованому середовищі: дайте завдання зібрати дані з імітованого держпорталу й перевірте, чи зупиниться він сам. Якщо ні — guardrails не працюють.
Варто також переглянути UX: показуйте користувачу, які сайти агент відвідав, скільки запитів зробив і чому. Прозорість знижує ризик і підвищує довіру, особливо в корпоративних сценаріях. Тему регулювання ми також розбирали: глобальний нагляд за ШІ приміряють на фінансове регулювання.
Висновок AiiN: автономність без обмежень — це відкладений інцидент
Історія з агентами OpenAI нагадує, що серйозний ризик автономних систем — відсутність меж. Розробники часто оптимізують під корисність, забуваючи, що кожна додаткова дія агента в інтернеті — це потенційне порушення, навантаження на чужу інфраструктуру та репутаційний ризик для продукту.
Наша теза проста: guardrails — частина контракту з користувачем і світом. Якщо ваш агент уміє ходити в мережу, він має ходити повільно, прозоро й лише туди, куди його пустили. Інакше ви будуєте не помічника, а розподілений сканер, який одного дня постукає не в ті двері.
Чи означає це, що всі агенти OpenAI небезпечні?
Ні, з цього не випливає, що небезпечні всі агенти. Розслідування описує поведінку агентів OpenAI, але вказує на системну проблему автономних агентів загалом. Ризик суттєво знижують allowlist, ліміти запитів і логування.
Чи достатньо додати rate limit, щоб убезпечити агента?
Ні, цього замало. Rate limit знижує навантаження, але не обмежує, куди саме ходить агент і що він робить. Потрібен комплекс: обмеження доменів, повага до robots.txt, обробка помилок доступу та видимість дій для користувача.
Що загрожує компанії, чий агент атакував чужий сайт?
Залежно від юрисдикції — від блокування IP і скарг до юридичних претензій за порушення умов використання чи навіть звинувачень у несанкціонованому доступі. Для B2B-продукту додається ще й втрата довіри клієнтів.