# Агентний ШІ зміщує периметр безпеки на рівень інфраструктури > Агентний AI отримує дедалі ширші привілеї виконання дій у хмарній інфраструктурі — і security-стек часто не бачить, що саме він робить у продакшні. - Опубліковано: 1 вересня 2026 р. (2026-08-31T22:35:25.715883+00:00) - Розділ: Безпека AI - На основі публікації: [SiliconANGLE AI](https://siliconangle.com/2026/08/31/cloud-infrastructure-becomes-security-front-line-agentic-ai-vmwareexplore/) - Видання: AiiN (https://aiin.news) - URL: https://aiin.news/article?slug=%D0%B0%D0%B3%D0%B5%D0%BD%D1%82%D0%BD%D0%B8%D0%B9-%D1%88%D1%96-%D0%B7%D0%BC%D1%96%D1%89%D1%83%D1%94-%D0%BF%D0%B5%D1%80%D0%B8%D0%BC%D0%B5%D1%82%D1%80-%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B8-%D0%BD%D0%B0-%D1%80%D1%96%D0%B2%D0%B5%D0%BD%D1%8C-%D1%96%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B8 --- 31 серпня 2026 року видання SiliconANGLE AI зафіксувало зсув, який ще рік тому звучав би як гіпотеза для конференційної панелі: периметр корпоративної безпеки більше не проходить по мережевому фаєрволу, а йде слідом за агентом — туди, куди той отримав право виконувати дії. Причина проста: агентний AI дедалі частіше має привілеї не читати дані, а діяти з ними — розгортати сервіси, змінювати конфігурації, викликати API продакшн-систем. Це не абстрактна теза для інвесторської презентації. Кожен агент, якому дали ключ доступу до хмарного облікового запису чи CI/CD-пайплайна, — це, по суті, нова ідентичність з правами виконання, яку більшість security-команд ще не веде в жодному реєстрі. Класичний SOC налаштований ловити аномальний вхід людини о третій ночі; агент, що постійно звертається до API як частина нормальної роботи, для такого моніторингу виглядає як шум, а не як сигнал. Наш погляд простий: питання вже не «чи безпечний конкретний AI-агент», а «чи взагалі бачить наш security-стек, що агенти роблять в інфраструктурі». Якщо відповіді немає — це і є розрив, про який пише джерело. ## Що саме змінилося в моделі загроз? Головна зміна — у типі привілеїв, які отримують нелюдські актори. [За даними SiliconANGLE AI](https://siliconangle.com/2026/08/31/cloud-infrastructure-becomes-security-front-line-agentic-ai-vmwareexplore/), поширення агентного AI зсуває фронт безпеки саме на рівень хмарної інфраструктури, бо агенти дедалі частіше отримують дедалі ширші привілеї виконання дій, а не лише читання. Раніше найбільшим ризиком AI-систем вважали витік даних через промпт чи неохайну відповідь моделі. Тепер до цього додається інший клас ризику: агент із доступом на запис чи виконання може сам стати вектором — не тому що він «зламаний» ззовні, а тому що його легітимні права виявляються ширшими, ніж потрібно для конкретної задачі. Це класична проблема надлишкових привілеїв (over-permissioning), знайома з часів сервісних акаунтів і DevOps-автоматизації. Різниця в тому, що агент приймає рішення про те, які саме дії викликати, динамічно — на основі промпту чи контексту, а не за жорстко прописаним сценарієм. Тому передбачити повний набір дій наперед складніше, ніж для звичайного скрипта. ## Чому мережевий периметр більше не встигає за агентом? Бо агент діє на рівні API-викликів усередині хмари, а не на рівні мережевих пакетів на кордоні периметра. Традиційний security-стек — фаєрволи, IDS, VPN-гейтвеї — будувався для контролю того, хто заходить іззовні. Агентний AI найчастіше вже перебуває всередині: у CI/CD, у хмарному обліковому записі, в оркестраторі контейнерів. Його активність виглядає як внутрішній, довірений трафік. Практично це означає, що периметр варто перевіряти не за мережевою топологією, а за трьома питаннями: - Які саме дії агент може виконати — і чи хтось формально це затвердив? - Чи логуються виклики агента окремо від людських сесій, з окремою ідентичністю? - Чи є межа (rate limit, approval gate) на дії з високим бласт-радіусом — видалення, розгортання, зміна прав доступу? ## Що бачить security-стек сьогодні — і чого не бачить? Більшість існуючих SIEM- і CSPM-інструментів бачать хмарну активність, але не розрізняють, чи це людина, сервісний акаунт чи автономний агент за тим самим API-ключем. Це головна прогалина: без окремої ідентичності для агента будь-яке розслідування інциденту зводиться до «хтось із командного ключа зробив X» — без розуміння, чи це було рішення людини, чи автономна дія моделі у відповідь на промпт. Ми вже писали, як подібна прогалина виглядає на рівні платформ: [AWS запустив Agent Registry для керування AI-агентами в компаніях](https://aiin.news/article?slug=aws-запустив-agent-registry-для-керування-ai-агентами-в-компаніях) — по суті, спробу дати агентам окрему, керовану ідентичність замість спільного сервісного ключа. Але реєстр на рівні хмарного провайдера не замінює власний моніторинг компанії: якщо SOC не підписаний на ці логи й не має правил для аномальної поведінки саме агентів, реєстр існує, а видимості немає. ## Що робити з цим зараз? Погляд AiiN Наша теза: компанії, які вже пустили агентів у продакшн, здебільшого захищають вхід (автентифікацію агента), але не дії (авторизацію на конкретну операцію) — і саме в цьому розриві сидить реальний ризик. Перше, з чого варто почати, — не купівля нового security-продукту, а інвентаризація: список усіх агентів з доступом до продакшн-ресурсів, права кожного та те, чи логуються їхні дії окремо від людських. Це можна зробити за тиждень без нових бюджетів. Далі — принцип найменших привілеїв, застосований до агентів так само суворо, як до людських акаунтів: агент, що має писати код, не повинен мати права видаляти бази даних. І нарешті — approval gate для дій з високим бласт-радіусом, навіть якщо це сповільнює автономність на кілька секунд. Швидкість агента цінна, поки вона не коштує компанії продакшн-інциденту, який ніхто не побачив у логах вчасно. Схожі прогалини в захисті самих агентних систем ми розбирали тут: [OpenClaw 2.0 не закрив старі діри в безпеці AI-агентів](https://aiin.news/article?slug=openclaw-2-0-не-закрив-старі-діри-в-безпеці-ai-агентів). ## FAQ: Чи це стосується лише великих хмарних компаній? Ні. Будь-яка команда, що дала AI-агенту ключ доступу до хмарного акаунта, CI/CD чи внутрішнього API, вже має цю поверхню атаки — незалежно від розміру компанії. Ризик масштабується з кількістю прав агента, а не з розміром бюджету на безпеку. ## FAQ: З чого почати перевірку за один робочий день? Складіть список усіх AI-агентів із доступом до продакшну, звірте їхні права з тим, що їм реально потрібно для задачі, і перевірте, чи дії агента логуються з окремою ідентичністю, а не під спільним сервісним ключем. Це базовий аудит, який не потребує нових інструментів. --- Теги: AI, агентнийШІ, кібербезпека, CloudSecurity, AgenticAI, VMwareExplore Джерело: AiiN — https://aiin.news/article?slug=%D0%B0%D0%B3%D0%B5%D0%BD%D1%82%D0%BD%D0%B8%D0%B9-%D1%88%D1%96-%D0%B7%D0%BC%D1%96%D1%89%D1%83%D1%94-%D0%BF%D0%B5%D1%80%D0%B8%D0%BC%D0%B5%D1%82%D1%80-%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B8-%D0%BD%D0%B0-%D1%80%D1%96%D0%B2%D0%B5%D0%BD%D1%8C-%D1%96%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B8. Цитуючи, посилайтесь на канонічний URL.