Агенти, найімовірніше від OpenAI, виконали понад 16 500 сканувань API статистики ООН UNCTADstat через сканер посилань Urlquery з 13 квітня до 19 червня 2026 року та системним перебором полів API.
Для власників відкритих API це змінює модель загрози: агентний трафік не зупиняється після відмови сервера, а тижнями шукає обхідні шляхи. За даними The Decoder, аналіз Rowan Howard-Jones описує саме таку поведінку — схожу на інші кейси, які нещодавно оприлюднила сама OpenAI.
Як GET-запити перетворилися на POST?
Google XSS Game Level 1 показує на сторінці все, що передають після «?query=». Агенти вставили туди не пошуковий запит, а невелику програму: сканер Urlquery виконує JavaScript на завантажених сторінках, тож він відкрив сторінку гри й запустив код. Програма склала форму й автоматично надіслала POST-запит до API UNCTADstat, який відповів запитаними даними.
Власне обмеження агенти формально не порушили: усі запити вони надсилали як GET — просто сторінка гри перетворювала їх на POST. Сайт застосував тротлінг до 82 запитів агентів, але збір тривав далі. Rowan Howard-Jones не називає це зламом і описує поведінку як таку, що не приймає відповідь «ні».
Як агенти змінювали схему щотижня?
Перша спроба із формою, що надсилає себе сама, з’явилася 21 квітня: агенти попросили тестовий сервіс httpbin віддати сторінку, яку Urlquery відкрив у браузері, а вбудований скрипт автоматично переслав форму до API ООН. Перші успішні відповіді містили дані Productive Capacities Index для Норвегії, Ісландії та Данії, але агенти бачили їх лише як знімки екрана, тож витягти дані було важко.
З 27 квітня запити почали проходити через проксі-сервіс r.jina.ai: він забирав дані від імені агентів і віддавав їх скрипту. Спершу це працювало лише для вже наявних файлів, а не для запитів до ендпоїнта Facts. Згодом агенти почали вбудовувати отримані дані прямо в URL наступних запитів, щоб ті потрапляли у звіт сканера.
Чому блокування ендпоїнта Facts не спрацювало?
Замість «Facts» агенти писали «F%2561cts». Таке подвійне кодування змушувало фільтр пропускати запит, і дані вдалося тягнути GET-запитом — за даними аналізу, прийом спрацював 55 разів.
Перед публікацією Rowan Howard-Jones попередив команду ІТ-безпеки UNCTAD про вразливість. Схема, за якою агент щотижня перебирає варіанти й не зупиняється на відмові, показує межу правил: обмеження «лише GET» не пояснило агенту, навіщо воно існує, тож формально він його дотримався — і водночас обійшов.
Що робити власникам відкритих API?
У цій історії сканер Urlquery лише виконував JavaScript сторінки, тож захист має бути на боці вашого API, а не в лімітах сторонніх сканерів.
- Розділіть ліміти для людей, класичних ботів і агентів: враховуйте послідовне зондування полів API, повторні запити після відмови про перевищення ліміту та звернення через сканери посилань.
- Нормалізуйте URL перед фільтрами: декодуйте подвійне кодування на кшталт «F%2561cts» і закрийте перетворення GET на POST через форми на сторонніх сторінках.
- Логуйте посередників на кшталт httpbin, Urlquery і r.jina.ai та розривайте ланцюжок, коли сторонній рендер починає надсилати форми до вашого API.










