Broadcom представив на конференції VMware Explore 2026 runtime із deny-default доступом для приватних AI-агентів — модель, за якою агент від старту не має жодних прав, а кожен дозвіл на дію чи звернення до системи потрібно видати окремо і явно. За даними SiliconANGLE AI, це один із перших випадків, коли постачальник інфраструктурного рівня вбудовує permission-модель для агентів прямо у платформу, а не залишає її на відкуп командам, які будують агентів поверх готових хмарних сервісів.

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

Deny-default сам по собі не новий принцип — це базовий підхід найменших привілеїв в інформаційній безпеці. Але його застосування саме до автономних агентів на рівні runtime, а не окремого мідлвера чи внутрішньої політики компанії, — сигнал, куди рухається індустрія.

Що саме змінює deny-default модель Broadcom?

Ключова відмінність — де проходить межа «дозволено / заборонено». У більшості чинних агентних систем дозволи додають реактивно: агента випускають у продакшн зі широким доступом, а обмеження накручують уже після того, як хтось помітив проблему або стався інцидент. Deny-default runtime інвертує цю логіку на рівні платформи: без явного правила агент не отримує доступ до ресурсу, незалежно від того, наскільки переконливо він «аргументує» потребу в ньому під час виконання задачі.

Для enterprise-команд це означає зміщення роботи на етап проєктування: перш ніж агент почне діяти, хтось має описати, до яких систем, даних і дій йому дозволено звертатися. Це повільніше на старті, зате знімає клас інцидентів, коли агент «про всяк випадок» отримав широкі права ще на етапі пілоту — і ніхто їх потім не відкликав.

Чим це відрізняється від звичного enterprise IAM?

Класичні IAM-системи (Identity and Access Management) теж уміють працювати за принципом deny-by-default, але їхні політики зазвичай прив'язані до людини-користувача, ролі чи сервісного акаунта — статичних сутностей, чиї права переглядають раз на квартал. Агент — сутність іншого порядку: він може створювати підзадачі, викликати інших агентів, а його «намір» у конкретний момент часу непередбачуваний навіть для розробника, який його написав.

Тому permission-модель для агентів має відповідати на інші питання, ніж класичний IAM:

Наскільки гостра ця проблема вже сьогодні?

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

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

Що з цим робити командам, які будують агентів зараз?

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

За нашою оцінкою, deny-default на рівні runtime, а не лише на рівні окремої політики компанії, найближчим часом стане очікуваним мінімумом для будь-якої платформи, що продає «корпоративних агентів», — так само, як HTTPS свого часу перестав бути опцією.

Що таке deny-default доступ для AI-агента?

Це модель контролю доступу, за якою агент не отримує жодного дозволу, поки хтось явно його не надав, — на відміну від allow-by-default, де агент має широкий доступ, доки конкретну дію не заборонять окремо.

Чи сповільнить deny-default роботу агентів?

На етапі налаштування — так, бо команди мають заздалегідь описати кожен потрібний дозвіл. У продакшні деny-default модель не додає затримки до самого виконання дії — вона лише перевіряє право на неї.