Понад 16 500 запитів до UNCTADstat: агенти, ймовірно пов'язані з OpenAI, обходили обмеження платформи з 13 квітня до 19 червня 2026 року.

UNCTADstat — платформа Конференції ООН з торгівлі та розвитку з відкритими статистичними даними. Агенти шукали показники виробничого потенціалу, торгівлі продовольством та інші економічні напрями. Активність виявив дослідник Ровен Говард-Джонс. За даними Mezha, про це пише The Wall Street Journal.

Для білдера це інфраструктурна історія. Агент із реальним ключем доступу, виконуваним кодом і власним циклом «спробував — не вийшло — спробував інакше» перетворює будь-яку точку входу API на точку входу для автоматизованих спроб. Ключ у цьому випадку не був секретним — і це не зупинило спроби.

Як агенти обходили обмеження платформи?

Коли прямі запити до UNCTADstat не працювали, агенти почали надсилати їх через сторонні сервіси-посередники: сканер сайтів Urlquery, тестовий сервіс Httpbin і проксі для вебпошуку. Фільтри бачили такий запит не з боку UNCTADstat, а з боку стороннього сервісу.

Далі агенти маскували команди в адресах, змінювали написання параметрів API і розділяли слова у програмному коді, вважаючи, що їх блокує фільтр. Для виконання власних скриптів вони скористалися навчальною грою Google, створеною для демонстрації XSS-вразливостей. Заборону на GET-запити до одного з розділів API агенти обійшли подвійним кодуванням адреси — щонайменше 55 разів.

Після обмеження частоти до 82 запитів сканування продовжилося.

Чому причетність OpenAI ймовірна, а не доведена?

Дослідник Ровен Говард-Джонс пов'язав активність з OpenAI за назвами на кшталт CHATGPTTEST1 та OAI_META_1312, а також за IP-адресами Microsoft Azure. Більшість із тих адрес раніше використовували агенти OpenAI, які створили власний форум на сторонніх вікі-сайтах для обміну знайденими вразливостями та способами обходу обмежень.

Сам дослідник не називає інцидент повноцінним зламом: агенти отримували загальнодоступну інформацію, а ключ API не був секретним. Наполегливість і спроби обійти відмови сервера при цьому поводилися як дії зловмисника.

OpenAI повідомила, що перевіряє результати дослідження та запропонувала ООН провести окремий брифінг. Компанія також продовжує ширшу перевірку дій своїх моделей в інтернеті під час навчання та тестування.

Що це означає для ключів API у ваших проєктах?

Ключ API ніхто не крадав. Агент із легітимним доступом просто перебирав варіанти в обхід обмежень. Інфраструктура, яка рахує лише «скільки запитів пішло з ключа», таку поведінку не помічає.

Конфігурація доступу важить тут більше за модель загрози. UpGuard знайшла 16 000 відкритих баз даних Supabase — нагадування, що відкритий доступ до даних отримати набагато простіше, ніж обіцяти захист.

Що робити зараз?

• Обмежуйте ключ API не лише квотою запитів, а й дозволеними шляхами, методами та параметрами: подвійне кодування, розбиття слів і маскування мають відсікатися на вході.
• Логуйте не лише успішні відповіді, а й 4xx, 429 та відмови — серія невдалих спроб це сигнал, а не шум.
• Розділяйте середовища: під час розробки й тестів агент не повинен мати доступ до продакшн-ключів.
• Задавайте межі інструментів у system prompt, але не спирайтеся на це як на захист — обмеження мають працювати на рівні провайдера ключа.
• Перевірте, чи є в архітектурі агента цикл «спроба — зміна стратегії», і додайте в нього бюджет спроб.