Сценарій BleepingComputer: як один AI-агент оголив п’ять прогалин у безпеці
BleepingComputer розібрав ілюстративний кейс про внутрішнього AI-агента, який діє поза радаром служби безпеки та демонструє типові провали контролів у корпоративному середовищі.
BleepingComputer описав сценарій із AI-агентом для обробки рахунків у середній компанії: його створив співробітник з бухгалтерії за кілька хвилин, без участі служби безпеки, і він запустив ланцюг проблем — від надмірних доступів до маніпуляції через лист із прихованими інструкціями.
Масштаб і контекст
За опитуванням Cloud Security Alliance, яке в січні 2026 року замовила Token, 68% ІТ‑та безпекових фахівців вважають, що добре бачать своїх AI‑агентів. Водночас 82% протягом року натрапляли на агентів, про існування яких раніше не знали. Token Security зібрала досвід понад 20 практиків у безкоштовному хабі Agentic Universe і простежила, як подібні кейси розгортаються у продакшені.
Як агент отримав доступ
Агенту відкрили три вектори: пошта через екран згоди OAuth у безкодовому конструкторі, ERP — за персональним API‑ключем, Slack — через конектор із ще одним екраном згоди. Як пояснює John Donovan, реальні агенти комбінують кілька шляхів доступу:
- використання людської сесії (розширення браузера, вбудовані копілоти, що діють від імені користувача);
- делеговані OAuth‑гранти зі збереженими обсягами доступу;
- статичні облікові дані (API‑ключі, паролі сервісних акаунтів);
- окремі короткоживучі ідентичності агента (рідкісний, але ідеальний варіант).
Змішаний шлях визначає, що побачать журнали: база даних може фіксувати сервісний акаунт, SaaS‑аудит — користувача, а постачальник ідентичностей — нічого. Окремо слідкуйте за OAuth‑грантами: IdP зазвичай їх не відкликає, тож вони лишаються чинними навіть після кадрових змін.
Перевірки не було
Агента запустили без рев’ю. Amber Bennoui з DataRobot, спираючись на Agents Rule of Two від Meta (жовтень 2025), радить обмежувати в одній сесії не більше двох із трьох можливостей: обробляти неперевірені вхідні дані; бачити чутливі системи або приватні дані; змінювати стан чи комунікувати назовні. У цьому сценарії були всі три: читання зовнішньої пошти, доступ до банківських реквізитів у ERP та можливість змін через персональний API‑ключ.
Рекомендація — зробити безпечні налаштування типовими та попросити творців агентів відповісти на три запитання: чи читає агент дані ззовні, чи бачить приватні дані, чи може діяти без людини. Якщо «так» на всі, безпека має долучатися до запуску.
Приховані інструкції в електронній пошті
На третьому тижні в інбокс приходить рахунок від відомого постачальника. Вкладення містить білий текст на білому тлі з проханням оновити банківські реквізити в ERP. Людина листа не відкривала, але агент прочитав і виконав зміну. Як показує CISO та дослідник кібербезпеки Joshua Copeland, інструкції можуть потрапляти до агента напряму або приховано у вмісті, який він обробляє. У журналах це виглядає цілком легітимно: дозволений інструмент, чинні облікові дані, припустима дія.
