Адам Марковіц, генеральний директор і співзасновник Drata — серія інтерв’ю

Адам Марковіц — генеральний директор і співзасновник Drata, де він розширює діяльність компанії у сфері безперервної відповідності вимогам і довіри, поширюючи її на управління ШІ-агентами. Перш ніж у 2020 році стати співзасновником Drata, він заснував Portfolium разом із Троєм Марковіцем і Деніелом Марашляном. Його досвід роботи з опитувальниками з безпеки, аудитами та перевірками відповідності вимогам допоміг сформувати підхід Drata до автоматизації процесу, за допомогою якого організації підтверджують свою надійність.

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

Раніше ви заснували Portfolium, а згодом, у 2020 році, стали співзасновником Drata, на власному досвіді переконавшись, наскільки обтяжливим може бути дотримання вимог безпеки в міру зростання компанії. Що переконало вас, що ця проблема варта створення цілком нової компанії, і як змінювалася місія Drata зі зміною ландшафту безпеки під впливом ШІ?

Коли ми разом із моїми співзасновниками Троєм Марковіцем і Деніелом Марашляном керували Portfolium, ми засвоїли важливий урок: довіра в бізнесі здобувається процесом, а не презентацією. Через великий обсяг і чутливий характер студентської інформації університети й підприємства не хотіли співпрацювати з нами, доки ми не довели, що належно захищаємо їхні дані. Ми зрозуміли, що повільна й виснажлива ручна робота з опрацювання кожного опитувальника з безпеки, аудиту та перевірки відповідності вимогам — це спільний досвід багатьох організацій. Після придбання Portfolium ми з Троєм і Деніелом знову об’єдналися й протягом шести місяців створювали першу версію Drata, спілкуючись із десятками компаній і аудиторів, щоб перевірити, чи справді ця проблема існує, ще до того, як почали писати код. Після запуску за перші шість тижнів ми залучили 100 клієнтів, а протягом року — 1 000. Це показало нам, що ми перейшли від продажу чогось «бажаного» до того, без чого люди не могли працювати.

З появою ШІ місія Drata — забезпечувати безперервну довіру — не змінилася, але сфера її застосування розширилася. Спершу ми автоматизували виснажливі процеси дотримання вимог, а потім перейшли до агентних робочих процесів, здатних повністю виконувати оцінювання ризиків третіх сторін і опрацьовувати опитувальники з безпеки. Але справжній зсув стався тоді, коли самі агенти стали об’єктом управління. Тепер ми розширили платформу, щоб забезпечити управління ШІ-агентами: виявляти агентів, контролювати, що їм дозволено робити, і надавати докази, які витримають перевірку, коли хтось попросить їх надати.

Ви запровадили термін «внутрішня загроза з боку агента», щоб описати ризики, які створюють не зовнішні зловмисники, а власні ШІ-агенти організації. Чим така загроза відрізняється від традиційної внутрішньої загрози, до якої команди безпеки готувалися десятиліттями?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Model Context Protocol (MCP) та інші інтерфейси взаємодії агентів з інструментами відкривають системам ШІ доступ до дедалі потужніших зовнішніх можливостей. Які нові межі безпеки потрібно встановити для викликів інструментів, API, облікових даних і сервісних облікових записів, коли підприємства розширюють можливості своїх агентів?

Виклик інструмента — це новий периметр. Щоразу, коли агент звертається до облікових даних, викликає API або використовує інструмент, виникає точка ухвалення рішення, однак сьогодні в більшості підприємств саме в цій точці немає жодного бар’єра, який оцінював би, чи слід виконувати цю дію. Саме цього й бракувало. Ми бачимо ту саму сліпу зону й зовні: лише 37% керівників служб безпеки впевнені, що можуть хоча б визначити, де саме працює ШІ в постачальників, з якими вони вже співпрацюють. Якщо ви не бачите цього в продукті постачальника, то не побачите й наступного кроку власного агента. Облікові дані та службові облікові записи, на яких усе це ґрунтується, також потребують такого самого суворого контролю, як і доступ людей: відомого власника, чітко визначеної сфери дії та регулярного перегляду. Агент не повинен мати змоги використати облікові дані, надані йому не були, лише тому, що десь на його шляху такі дані існували.

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

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

І так, я вважаю, що журнали аудиту дій агентів незабаром стануть такими ж невід’ємними, як журнали доступу. Роками ми вважали обов’язковим для систем, якими користуються люди, фіксувати, хто, до чого й коли мав доступ. Немає підстав встановлювати для агентів нижчу планку лише тому, що натискала кнопки не людина. Такі нормативні рамки, як Закон ЄС про штучний інтелект, AIUC-11 та ISO 42001, уже сприяють цьому. Відстежуваність дій агентів має спиратися на ті самі засоби контролю та принципи доказовості, на яких уже ґрунтуються програми забезпечення відповідності вимогам. Якщо розглядати це як щось другорядне, воно так і залишиться поза увагою.

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

Кожна велика хвиля технологічних змін породжує власну хвилю рішень у сфері безпеки: хмарні технології дали поштовх до появи Wiz, а захист кінцевих пристроїв — CrowdStrike. Тепер таку хвилю породжують ШІ-агенти. Постачальники моделей створюють консолі й політики для власних платформ. Це корисно, але жодне підприємство не працює лише з одним постачальником моделей, одним помічником із програмування та одним набором власних агентів. Хтось має керувати всім цим на основі єдиних політик і з єдиним джерелом доказів, а жодна окрема платформа ШІ не призначена для розв’язання цієї проблеми. Це не входить до її призначення. Управління ШІ-агентами вже стало окремою категорією, хоча воно й інтегрується з системами управління, ризиків і відповідності вимогам (GRC), ідентифікації та комплаєнсу, якими компанії вже користуються.

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

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

Дякуємо за чудове інтерв’ю. Читачам, які хочуть дізнатися більше про управління ШІ-агентами, безперервну відповідність вимогам і засоби контролю загроз з боку внутрішніх агентів, варто відвідати Drata.