Гарольд Бьон, генеральний директор BlueRock – Серія інтерв’ю

Гарольд Бьон, генеральний директор BlueRock, – ветеран корпоративних технологій з глибокими знаннями в галузі кібербезпеки, платформ SaaS, безпеки хмарних обчислень та корпоративного керівництва продуктом. До того, як стати генеральним директором у квітні 2026 року, він обіймав посаду головного офіцера з продукту компанії, де допоміг сформувати напрямок BlueRock щодо безпеки агентських ІІ та спостереження. Перед вступом на посаду в BlueRock Бьон обіймав керівні посади в AppOmni, ServiceNow (NOW ), Skyhigh Networks, Symantec та Citrix після придбання Zenprise. На цих посадах він заслужив репутацію фахівця, який допомагає підприємствам забезпечувати безпеку все більш складних хмарних та даних середовищ, досвід, який тепер безпосередньо відповідає новим безпековим викликам, пов’язаним з автономними агентами ІІ та екосистемами Протоколу контексту моделі (MCP).

BlueRock зосереджується на забезпеченні безпеки шару виконання агентських систем ІІ, галузі, яка стає все більш критичною, оскільки підприємства розгортають автономні агенти ІІ, здатні взаємодіяти з інструментами, API, кодовими базами та чутливими корпоративними даними. Компанія розробляє технології безпеки та спостереження, призначені для моніторингу, sandbox та забезпечення охорони поведінки агентів ІІ, особливо в середовищах, заснованих на MCP. Платформа BlueRock підкреслює видимість часу виконання та захист шару виконання, а не спирається виключно на заходи безпеки на рівні промпта, що відображає більш широкий промисловий зсув у напрямку забезпечення безпеки того, як агенти ІІ діють, а не тільки того, що вони кажуть. Коли організації переходять від експериментів з ІІ до автономних робочих процесів у виробництві, компанії, подібні до BlueRock, позиціонують себе в центрі того, що може стати великою новою категорією в галузі корпоративної кібербезпеки.

Ви провели роки в галузі хмарних обчислень, SaaS, запобігання втраті даних (DLP) та корпоративної безпеки в компаніях, таких як AppOmni, Symantec, ServiceNow та Skyhigh Networks. Що переконало вас, що безпека часу виконання для агентів ІІ стане наступною великою категорією безпеки?

Що стало очевидним для мене, це те, що ІІ змінює місце, де відбувається значимий операційний ризик та складність. У традиційному програмному забезпеченні більшість поведінки визначається до розгортання. У агентських системах поведінка все частіше виникає під час виконання через промпти, контекст, інструменти, API, сервери MCP та подальші взаємодії.

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

Я бачив подібні зміни платформи раніше в галузі безпеки хмарних обчислень та SaaS, де інфраструктура розвивалася швидше, ніж системи, які використовувалися для її управління. ІІ створює ще один такий момент. Довгостроковим викликом є не тільки безпека моделі. Це забезпечення організації для безпечної роботи агентських систем у масштабі.

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

BlueRock говорить про “агентський розрив виконання”, де організації втрачають видимість, коли агенти починають діяти автономно під час виконання. Чому традиційні інструменти спостереження та безпеки не справляються в цих середовищах?

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

Агентські системи порушують це припущення.

Агенти можуть динамічно виявляти інструменти, викликати сервери MCP, ланцюжкові робочі процеси, взаємодіяти з API та приймати рішення в реальному часі. Шлях виконання часто виникає під час виконання.

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

Це і є агентський розрив виконання. Виконання стало динамічним, але моделі видимості та контролю не еволюціонували поряд з ним.

Розростання кількості підприємств, які експериментують з архітектурами, заснованими на Протоколі контексту моделі (MCP), та автономними робочими процесами ІІ. Які найбільші безпекові міфи організації все ще мають щодо серверів MCP та агентських систем?

MCP швидко стає фундаментальною інфраструктурою для того, як агенти ІІ виявляють, підключаються та взаємодіють з інструментами, системами та корпоративними даними.

Що робить MCP важливим, це те, що воно значно знижує тертя між системами ІІ та операційними середовищами. Воно збільшує швидкість розробки та розблоковує потужні робочі процеси, але воно також масово розширює кількість шляхів виконання, які агенти можуть пройти в корпоративних системах.

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

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

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

Дослідження BlueRock виявило серйозні уразливості на публічних серверах MCP, включаючи виявлення запитів на стороні сервера (SSRF) та вразливість ін’єкції команд. Чи недооцінюють підприємства, як швидко екосистеми MCP можуть стати новою поверхнею атаки ланцюга постачання програмного забезпечення?

Так. Я думаю, що галузь ще на початку розуміння того, наскільки важливим може стати екосистема MCP з точки зору ланцюга постачання та операційного довіри. Наприклад, понад 36% з 11 000 серверів MCP, які ми проаналізували, мають уразливості SSRF без обмежень. Більшість людей у галузі не розуміють, що це фактично відкриває всю їхню мережу з точки зору доступу до даних. Це ніколи не буде дозволено в几乎 кожному підприємстві світу сьогодні.

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

Це створює зовсім іншу проблему довіри.

Організації тепер не тільки керують статичними залежностями. Вони все частіше керують динамічними залежностями виконання, які виникають під час виконання систем. Агенти можуть викликати інструменти, ланцюжкові робочі процеси або доступ до подальших систем способами, яких оператори не повністю передбачають чи спостерігають.

Наше дослідження щодо SSRF, ін’єкції команд та інших уразливостей відображає, наскільки недозрілої частини екосистеми ще є. Але більша проблема ширша, ніж окремі уразливості. Коли采用 MCP прискорюється, організації будуть потребувати набагато глибшої видимості того, як автономні системи взаємодіють з зовнішніми сервісами під час виконання.

Ваша платформа підкреслює “агентську спостережність” замість простого моніторингу промптів або виводу. Що таке справжня видимість часу виконання, коли агенти приймають динамічні рішення через інструменти, API та інфраструктуру?

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

Організації повинні бачити, як рішення моделі перетворюється на дії через інструменти, сервери MCP, API, інфраструктуру та подальші системи. Це означає розуміння, чому агент вибрав інструмент, який контекст вплинув на рішення, які дозволи були використані, які подальші дії були спровоковані та який операційний результат був створений.

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

Моніторинг промптів сам по собі недостатній, оскільки промпти не пояснюють операційну поведінку. Вивід недостатній, оскільки він не розкриває, які системи були торкнуті вниз по потоку.

Майбутнє спостережності в агентських системах є виконання-інформованим. Це про розуміння поведінки від рішення до дії до результату в реальному часі.

Двигун довіри BlueRock, як здається, прикріплює дані ідентифікації, довіри та можливостей безпосередньо до потоків виконання в реальному часі. Наскільки важливим стане контекстне довіра, коли агенти ІІ все частіше взаємодіятимуть з зовнішніми інструментами та системами автономно?

Контекстне довіра стає фундаментальною в агентських системах, оскільки агенти приймають рішення динамічно під час виконання.

Традиційні системи сильно покладалися на статичні припущення довіри. Але агенти все частіше діють у зміняних контекстах, зовнішніх інструментах, API, серверах MCP, ідентифікаторах та дозволах.

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

Це саме тому ми вважаємо, що контекст довіри стає критичною інфраструктурою для наступного покоління систем ІІ.

Ми бачимо швидке采用 агентів кодування ІІ та автономних розробчих робочих процесів. Які найбільш тривожні ризики, коли агенти отримують можливість змінювати інфраструктуру, розгортати код або взаємодіяти з виробничими системами без людської перевірки?

Найбільший зсув полягає в тому, що організації намагаються драматично збільшити швидкість розробки, дозволяючи багатьом людям будувати з ІІ, а не тільки традиційним інженерам-програмістам.

Агенти кодування ІІ можуть вже генерувати код, змінювати інфраструктуру, взаємодіяти з конвеєрами CI/CD, викликати сервіси хмари та отримувати доступ до чутливих систем. Продуктивність вище величезна, оскільки підприємства тепер можуть розблокувати як досвідчених розробників, так і нове покоління розробників, родуських для ІІ та громадянських розробників.

Виклик полягає в тому, що операційна складність зростає так само швидко. Обеспокоєння полягає не тільки у злонаміреній поведінці. Це несприятливий вплив, який агент може здійснити, що викликає виходи з ладу продукції та впливає на доступність даних та інфраструктури для організації. Цей тип поведінки, що виходить з-під контролю, схожий на проблему публічних бакетів S3 десять років тому. Ми очікуємо, що агенти будуть поводитися. Ми очікуємо, що будуть встановлені перила та перевірки. Але є шляхи до ненавмисної поведінки, надмірних дозволів, прихованих залежностей, небезпечного використання інструментів або шляхів виконання, яких ніхто не передбачав. І це призведе до більшої кількості виходів з ладу або субоптимальних розгортань, де люди стають кнопочними натисками, а ROI не реалізується повністю.

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

Багато організацій все ще думають про безпеку ІІ в першу чергу через призму безпеки моделі та ін’єкції промпта. Чому ви вважаєте, що галузь тепер повинна перейти до забезпечення безпеки дій та шляхів виконання?

Безпека моделі та ін’єкція промпта абсолютно важливі, але вони представляють тільки частину виклику.

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

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

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

Деякі дослідники порівнювали采用 MCP з наданням системам ІІ “універсального порту USB” до корпоративної інфраструктури. Як компанії повинні балансувати величезну продуктивну перевагу зв’язаних агентів з операційними ризиками, які вони вводять?

Продуктивна перевага реальна. MCP значно спрощує, як агенти підключаються до інструментів, систем та робочих процесів, що є однією з причин, чому采用 прискорюється так швидко.

Але організації повинні уникати думки про MCP як про чистий шар підключення. Воно фактично стає частиною операційної тканини підприємства.

Баланс полягає в тому, щоб дозволити розробникам та будівельникам, родуським для ІІ, рухатися швидко, зберігаючи видимість виконання та контроль.

Це означає розуміння безпеки реалізації сервера MCP самої по собі, чому ми створили реєстр mcp-trust.com. І це означає розуміння, з якими серверами MCP агенти взаємодіють, які інструменти ці сервери розкривають, які дозволи надаються та як дії поширюються під час виконання.

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

Оглядаючи вперед, як виглядатиме зріла корпоративна безпека ІІ в світі, де автономні агенти регулярно співпрацюють, приймають рішення та виконують завдання в декількох системах у виробництві?

Я думаю, що зріла корпоративна безпека ІІ стане ще більш виконання-орієнтованою.

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

Когда агенти все частіше співпрацюють, приймають рішення та здійснюють дії через інструменти, інфраструктуру та бізнес-робочі процеси, організації будуть потребувати безперервної видимості того, як системи ІІ фактично поводяться під час виконання.

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

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

і(runtime security) та безпеку виконання в єдиний операційний шар для агентських систем. Організації, які успішно справляються, будуть тими, які можуть безперервно розуміти та оперціоналізувати автономне виконання без сповільнення інновацій. Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати BlueRock.