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

Це не абстрактна теза для інвесторської презентації. Кожен агент, якому дали ключ доступу до хмарного облікового запису чи CI/CD-пайплайна, — це, по суті, нова ідентичність з правами виконання, яку більшість security-команд ще не веде в жодному реєстрі. Класичний SOC налаштований ловити аномальний вхід людини о третій ночі; агент, що постійно звертається до API як частина нормальної роботи, для такого моніторингу виглядає як шум, а не як сигнал.

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

Що саме змінилося в моделі загроз?

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

Це класична проблема надлишкових привілеїв (over-permissioning), знайома з часів сервісних акаунтів і DevOps-автоматизації. Різниця в тому, що агент приймає рішення про те, які саме дії викликати, динамічно — на основі промпту чи контексту, а не за жорстко прописаним сценарієм. Тому передбачити повний набір дій наперед складніше, ніж для звичайного скрипта.

Чому мережевий периметр більше не встигає за агентом?

Бо агент діє на рівні API-викликів усередині хмари, а не на рівні мережевих пакетів на кордоні периметра. Традиційний security-стек — фаєрволи, IDS, VPN-гейтвеї — будувався для контролю того, хто заходить іззовні. Агентний AI найчастіше вже перебуває всередині: у CI/CD, у хмарному обліковому записі, в оркестраторі контейнерів. Його активність виглядає як внутрішній, довірений трафік.

Практично це означає, що периметр варто перевіряти не за мережевою топологією, а за трьома питаннями:

Що бачить security-стек сьогодні — і чого не бачить?

Більшість існуючих SIEM- і CSPM-інструментів бачать хмарну активність, але не розрізняють, чи це людина, сервісний акаунт чи автономний агент за тим самим API-ключем. Це головна прогалина: без окремої ідентичності для агента будь-яке розслідування інциденту зводиться до «хтось із командного ключа зробив X» — без розуміння, чи це було рішення людини, чи автономна дія моделі у відповідь на промпт.

Ми вже писали, як подібна прогалина виглядає на рівні платформ: AWS запустив Agent Registry для керування AI-агентами в компаніях — по суті, спробу дати агентам окрему, керовану ідентичність замість спільного сервісного ключа. Але реєстр на рівні хмарного провайдера не замінює власний моніторинг компанії: якщо SOC не підписаний на ці логи й не має правил для аномальної поведінки саме агентів, реєстр існує, а видимості немає.

Що робити з цим зараз? Погляд AiiN

Наша теза: компанії, які вже пустили агентів у продакшн, здебільшого захищають вхід (автентифікацію агента), але не дії (авторизацію на конкретну операцію) — і саме в цьому розриві сидить реальний ризик. Перше, з чого варто почати, — не купівля нового security-продукту, а інвентаризація: список усіх агентів з доступом до продакшн-ресурсів, права кожного та те, чи логуються їхні дії окремо від людських. Це можна зробити за тиждень без нових бюджетів.

Далі — принцип найменших привілеїв, застосований до агентів так само суворо, як до людських акаунтів: агент, що має писати код, не повинен мати права видаляти бази даних. І нарешті — approval gate для дій з високим бласт-радіусом, навіть якщо це сповільнює автономність на кілька секунд. Швидкість агента цінна, поки вона не коштує компанії продакшн-інциденту, який ніхто не побачив у логах вчасно. Схожі прогалини в захисті самих агентних систем ми розбирали тут: OpenClaw 2.0 не закрив старі діри в безпеці AI-агентів.

FAQ: Чи це стосується лише великих хмарних компаній?

Ні. Будь-яка команда, що дала AI-агенту ключ доступу до хмарного акаунта, CI/CD чи внутрішнього API, вже має цю поверхню атаки — незалежно від розміру компанії. Ризик масштабується з кількістю прав агента, а не з розміром бюджету на безпеку.

FAQ: З чого почати перевірку за один робочий день?

Складіть список усіх AI-агентів із доступом до продакшну, звірте їхні права з тим, що їм реально потрібно для задачі, і перевірте, чи дії агента логуються з окремою ідентичністю, а не під спільним сервісним ключем. Це базовий аудит, який не потребує нових інструментів.