Micha Rave, CEO та співзасновник Hush Security — серія інтерв’ю

Micha Rave, CEO та співзасновник Hush Security, є досвідченим керівником у сфері кібербезпеки та технологій, чия кар’єра охоплює розробку програмного забезпечення, управління продуктами, корпоративні мережі, хмарну безпеку та ідентифікацію. До того як у 2024 році співзаснував Hush Security, він провів понад п’ять років у Proofpoint на посаді старшого директора з управління продуктами у сфері хмарної безпеки, де відповідав за лінійки продуктів Zero Trust Network Access (ZTNA) та Secure Web Gateway (SWG). Раніше він працював віце‑президентом з управління продуктами у Meta Networks, зосереджуючись на корпоративних мережах та безпеці, а також займав керівні посади у сфері продуктів і інженерії в HARMAN International, Redbend, SanDisk, Hola, Jungo та Elbit Systems. Його досвід поєднує практичну розробку програмного забезпечення з більш ніж двадцятирічним досвідом створення та комерціалізації продуктів у галузях безпеки, мереж, віртуалізації та вбудованих технологій.

Hush Security — це компанія з кібербезпеки, орієнтована на захист AI‑агентів та інших не‑людських ідентичностей шляхом заміни довготривалих облікових даних і статичних секретів ідентифікаційно‑орієнтованим, політично‑контрольованим доступом. Її платформа виявляє AI‑агенти, включаючи тіньові та внутрішньо розроблені агенти, призначає їм перевірні ідентичності та керує їх взаємодією з корпоративними системами за допомогою обмежених, «just‑in‑time» дозволів, централізованих політик та аудиторських записів дій. Компанію заснували ветерани безпеки з команди, що стояла за Meta Networks, яку Proofpoint придбав у 2019 році. У липні 2026 року Hush залучила інвестиції у розмірі 30 млн доларів у рамках Series A, при цьому Akamai Technologies приєдналася як стратегічний інвестор разом з Battery Ventures та YL Ventures, підвищивши загальний обсяг фінансування до 41 млн доларів, оскільки компанія розширює технології управління корпоративними AI‑агентами та не‑людською інфраструктурою.

До заснування Hush Security ви провели роки, розробляючи та керуючи продуктами безпеки, зокрема хмарною безпекою в Proofpoint. Що ви помітили на ринку, що переконало вас у необхідності створити Hush, і як ця початкова теза еволюціонувала у зв’язку зі швидким зростанням агентної AI?

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

Засновницька теза полягала у переході не‑людського доступу від секретів до ідентичності. Перевірна ідентичність робочих навантажень, короткоживучі облікові дані, що видаються «just‑in‑time», політика, що застосовується в режимі inline. Без переписування коду.

Агентна AI зробила це нагальним. Агент — це NHI, який у режимі виконання розмірковує та вирішує, які інструменти викликати. Якщо надати йому статичний ключ, ви даєте автономному програмному забезпеченню постійний доступ до продакшну, і агенти розгортаються поза будь‑яким процесом змін: розробник підключає сервер MCP у вівторок, а вже в п’ятницю він працює з даними клієнтів.

Теза не змінилася. Змінився обсяг. Доступ, орієнтований на ідентичність, був правильним рішенням для робочих навантажень. Для агентів це єдине життєздатне рішення: знати кожного існуючого агента, за замовчуванням надавати йому мінімальну «агентність», і аудитути кожну дію. Люди отримали IdP. Агенти теж його потребують, і це Hush.

Hush стверджує, що корпоративні AI‑агенти повинні мати власні ідентичності та делеговані дозволи, а не просто успадковувати права доступу людей, які їх використовують. Чому традиційні системи управління ідентифікацією та доступом (IAM) мають труднощі з автономними агентами, і що потрібно змінити?

Очевидний випадок — агент, який діє від імені користувача. Складніший випадок — агент без жодного користувача: запланована задача, автономний реагент SOC, конвеєр, який самостійно розмірковує та діє. Немає кого‑небудь, від кого можна делегувати, тому команди вдаються до єдиного інструменту, яким вони володіють — статичного сервісного облікового запису з широкими дозволами та ключа, що ніколи не закінчується. Це той самий модель спільного секрету, яка розпадається протягом десятиліття, тепер прив’язана до програмного забезпечення, що імпровізує.

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

Що потрібно змінити: кожен агент отримує власну ідентичність, видану криптографічно, незалежно від того, чи стоїть за ним людина. Доступ надається за дією, короткоживучий і обмежений, з політикою, що застосовується inline, а не довіряється цільовій системі. Коли є користувач, дозволи агента — це перетин того, що може робити користувач, і того, що агент дозволено робити для конкретного завдання. Коли користувача немає, ідентичність та політика самого агента становлять всю історію. Люди отримали принцип найменших привілеїв. Агенти потребують принципу найменшої «агентності».

Ви використовуєте концепцію “least agency” під час обговорення безпеки AI. Чим “least agency” відрізняється від традиційного принципу кібербезпеки “least privilege”, і як організації можуть точно визначити, що саме AI‑агент повинен мати можливість робити для конкретного завдання?

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

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

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

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

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

Hush нещодавно залучив $30 million Серія A, підвищивши загальне фінансування до $41 мільйона, при цьому Akamai приєднався як стратегічний інвестор разом з Battery Ventures та YL Ventures. Що принесе участь Akamai, окрім капіталу, і як ви очікуєте, що це партнерство вплине на розширення Hush у сфері безпеки корпоративних AI‑агентів?

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

Окрім капіталу, вони приносять три речі: розповсюдження серед CISO, які вже запитують, як контролювати агентів та трафік MCP; підтвердження того, що ідентичність агента є реальною категорією, а не лише функцією; та десятиліття досвіду забезпечення безпеки машинного трафіку у глобальному масштабі, що саме й стане трафіком агент‑до‑інструменту.

Model Context Protocol (MCP) швидко стає важливим шаром для з’єднання AI‑агентів з інструментами та корпоративними даними. З точки зору безпеки, які нові ризики вводить MCP і як організації мають розглядати ідентичність та авторизацію між агентом, сервером MCP та базовим ресурсом?

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

Зараз існує три нові проблеми:

1. Тіньовий MCP — ніхто не знає, скільки серверів працює і до чого вони підключаються.
2. Розповсюдження облікових даних — більшість серверів автентифікуються статичним токеном, який надає доступ до всього поверху, тому агент отримує все, що може токен.
3. Зруйнований ланцюжок — ресурс бачить лише облікові дані сервера MCP, тому не може визначити, який агент, діючи від імені якого користувача, здійснив виклик. Ідентичність повинна бути в основі кожної взаємодії, доступ має бути тимчасовим, обмеженим і базуватись на дозволах агента та користувача.

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

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

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

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

Той самий підхід охоплює п’ятнадцятирічний Java‑сервіс і сервер MCP, запущений минулого тижня. Починайте там, де ризик, доведіть його, і продовжуйте.

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

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

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

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

Системи з багатьма агентами буде важче аналізувати. Ланцюжок зберігання доказів для кожної дії не обов’язковий.

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

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

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

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

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

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

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

Ми використовуємо його там, де він виправдовує себе.

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

У Hush агентне програмування змінило наші часові рамки. Функції, які займали спринт, тепер займають дні, і ми випускаємо інтеграції з темпом, який команда Series A не могла б собі дозволити. LLM триажують запити підтримки, групують кореневі причини та виводять запити клієнтів для обговорення дорожньої карти. Наш власний шлюз MCP стоїть перед усім цим, допомагаючи нашим клієнтам розмірковувати та споживати NHI і агентний ризик.

Hush стверджує, що кілька компаній Fortune 500 вже використовують його технологію, а Kyndryl розгорнув Hush внутрішньо і почав перепродавати його корпоративним клієнтам. Чого ви дізнаєтеся з цих масштабних впроваджень про реальні проблеми управління, з якими стикаються компанії, коли AI‑агенти переходять від експерименту до виробництва?

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

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

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

А покупець змінився. Це була проблема команди платформи. Тепер CISO відповідає, бо правління вимагає. Це перевело нас від пілотних проектів до корпоративних розгортань, і саме тому Kyndryl спочатку розгорнув технологію внутрішньо, а потім почав її перепродавати.

Агенти не створили нових проблем управління. Вони лише погіршили ті, які підприємства ігнорували протягом десятиліття через сервісні облікові записи.

Дякуємо за чудове інтерв’ю, читачі, які хочуть дізнатися більше, повинні відвідати Hush Security.