Люди, яких компанії ставлять «в контур» перевірки дій AI-агентів для написання коду, пропускають до третини явно небезпечних команд ще до того, як ті встигають виконатися. Це не гіпотетичний сценарій з презентації про AI-safety, а результат дослідження практики human-in-the-loop — підходу, який індустрія роками називає головним запобіжником проти автономних агентів, здатних видалити продакшн-базу, злити креденшели чи запустити довільний shell-скрипт.

Проблема в тому, що human-in-the-loop продають як «останню лінію оборони», а насправді це часто плацебо-контроль: людина бачить довгий diff або команду термінала, звикла тиснути «дозволити» і не встигає — чи не вміє — розпізнати, що серед десятків нормальних дій ховається одна деструктивна. За даними The Register AI, саме цей розрив між формальним контролем і реальною увагою стає точкою відмови в багатьох агентних пайплайнах.

Для AI-білдерів, які зараз впроваджують агентів на кшталт Claude Code, Cursor чи власних кодогенераторів у CI/CD, це не абстрактна цифра — це пряма вказівка переробити дизайн permission-запиту, а не просто додати ще одну кнопку «Approve».

Що саме зафіксувало дослідження?

Дослідники поставили учасників у роль оператора, який має схвалювати чи відхиляти запити AI-агента-кодера перед їх виконанням — так само, як це відбувається в реальних агентних інтерфейсах для розробки. Частина запитів була навмисно небезпечною: команди, здатні видалити дані, змінити права доступу або відправити інформацію назовні. Результат — приблизно кожен третій такий запит люди пропускали й дозволяли до виконання.

Ключовий висновок не в самій цифрі, а в тому, що вона тримається навіть тоді, коли учасники заздалегідь знають: серед запитів є пастки. Тобто йдеться не про разову неуважність, а про системне обмеження людини як фільтра для потоку агентних дій.

Чому «людина в контурі» пропускає небезпечні команди?

Головна причина — асиметрія швидкості: агент генерує запити швидше, ніж людина здатна їх осмислено прочитати, тож контроль зводиться до побіжного сканування замість аналізу. Додає ризику й те, що небезпечна команда рідко виглядає як очевидно руйнівна — найчастіше це технічно коректна дія (виклик API, зміна конфігурації, git push --force), небезпечна лише в конкретному контексті, який людина за секунди оцінити не встигає.

Які запити найчастіше проскакують повз контроль?

Найризикованіша категорія — дії, замасковані під рутинні операції: масові видалення файлів під виглядом «очищення», зміна прав доступу під виглядом «фіксу бага», мережеві запити до зовнішніх адрес під виглядом «завантаження залежності». Подібну логіку ми вже розбирали в контексті ширшої проблеми — коли сам механізм перевірки безпеки перетворюється на вектор атаки, як описано в матеріалі про тест безпеки AI, що сам став вектором атаки на моделі. Логіка та сама: чим більше автоматичної довіри отримує проміжна ланка — тест, огляд, апрув, — тим привабливіша вона для експлуатації, навмисної чи випадкової.

Висновок AiiN: що це означає для розробників агентів?

Наша теза проста: human-in-the-loop у нинішньому вигляді — це радше UX-проблема, яку індустрія видає за розв'язану проблему безпеки. Поки апрув команди виглядає як один клік у діалоговому вікні, людина фізично не може бути надійним фільтром, скільки б застережень не додали в документацію. Рішення не в «уважнішому операторі», а в іншій архітектурі контролю: агент сам класифікує ризик дії до показу людині (низький, середній, критичний); для категорії «незворотні дії» — видалення, force push, зовнішні мережеві виклики, зміна прав доступу — вмикається примусова пауза й окреме підтвердження; усе, що не позначено явно безпечним, за замовчуванням виконується в sandbox. Командам, які будують агентних кодерів, варто рахувати перевірку дозволів не за галочку для маркетингу, а за окремий продуктовий компонент із власною метрикою false-negative rate.

Чи означає це, що human-in-the-loop — марна практика?

Ні, але як єдиний рубіж захисту вона недостатня. Дослідження показує межу можливостей людини-контролера, а не непотрібність контролю взагалі. Правильний висновок — комбінувати людину з автоматичними бар'єрами: allowlist дозволених дій, rate limits на деструктивні операції, обов'язковий sandbox за замовчуванням, а не покладатися лише на те, що «людина побачить і зупинить».

Як AI-агенти для коду вже намагаються знизити цей ризик?

Частина інструментів впроваджує рівні дозволів — окремий режим для файлових операцій і окремий для мережевих чи shell-команд — і явно маркує деструктивні дії перед виконанням, а не постфактум у логах. Це знижує навантаження на увагу оператора, бо звужує коло дій, які взагалі потребують ручного апруву, до справді критичних.

Що конкретно можна зробити вже цього тижня?

Перевірити, чи має ваш агентний пайплайн окрему категорію «незворотні дії» з примусовим другим фактором підтвердження і чи логуються всі відхилені та схвалені запити для подальшого аудиту. Без цих двох речей будь-яка людина в контурі рано чи пізно пропустить саме той запит, який мав значення.