Кібербезпека
Стратегії кібербезпеки для розроблення агентів із низьким і високим рівнем програмування
Коли організації починають використовувати агентів штучного інтелекту в різних бізнес-системах, швидкість розроблення та контроль безпеки стають тісно пов’язаними. Стратегії кібербезпеки для розроблення агентів із низьким і високим рівнем програмування мають враховувати, як кожен підхід надає доступ до інформації та дає змогу виконувати дії. Цільові заходи безпеки допомагають усунути ці відмінності, а спільне управління гарантує, що в міру розширення впровадження агенти діятимуть відповідно до дозволених завдань.
Чим відрізняється розроблення агентів ШІ з низьким і високим рівнем програмування
Платформи з низьким рівнем програмування дають змогу створювати агентів за допомогою візуальних інтерфейсів і готових конекторів, що з’єднують бізнес-сервіси. Розроблення з високим рівнем програмування надає програмістам більше свободи у визначенні поведінки агентів за допомогою власного коду, інтеграції інструментів і середовищ виконання. Обидва підходи потребують контролю за інформацією, до якої агенти мають доступ, і діями, які вони можуть виконувати.
Обов’язки щодо безпеки відрізняються, оскільки контроль зосереджений у різних місцях. Розробники, які працюють із платформами з низьким рівнем програмування, використовують налаштування платформи, що регулюють спільний доступ і доступ через конектори, тому рішення щодо конфігурації особливо важливі. Команди, які працюють із високим рівнем програмування, беруть на себе більше відповідальності за програмне забезпечення та середовища, у яких виконуються інструкції агентів, зокрема за обмеження доступу до файлів і облікових даних.
Агентство з кібербезпеки та безпеки інфраструктури визначає низку ризиків, пов’язаних з агентним ШІ, які створюють корисну основу для обох підходів. Розширення поверхні атаки означає появу додаткових точок входу, а розростання привілеїв — поступове накопичення доступу. Поведінкова невідповідність полягає у відхиленні від запланованих завдань, а недостатньо докладні журнали подій ускладнюють розслідування. Широко використовуваний конектор і необмежений інструмент командного рядка можуть спричинити різні прояви тих самих проблем.
Ризики безпеки агентів ШІ з низьким рівнем програмування та способи їх усунення
Завдяки доступності інструментів із низьким рівнем програмування агенти стають досяжними для працівників поза традиційними командами розробників. Контроль безпеки має охоплювати й цих розробників, щоб зручні інтеграції відповідали дозволеним бізнес-цілям.
Недоліки безпеки середовищ із низьким рівнем програмування
Розробники без спеціальної технічної підготовки можуть під’єднати агента до спільних файлів або бізнес-застосунків, не повністю розуміючи його дозволи. Доступ, наданий через такі підключення, може призвести до розкриття конфіденційної інформації або дати змогу виконувати дії, що виходять за межі запланованого процесу. Широкий спільний доступ і нечітко визначена відповідальність можуть посилити цей ризик.
Масштаби впровадження роблять важливим послідовний контроль у всіх підрозділах. У ринковому аналізі за 2024 рік Forrester повідомляє, що 87% корпоративних розробників використовують платформи з низьким рівнем програмування для виконання певних завдань із розроблення. Це спостереження стосується розроблення загалом, тож воно свідчить про широке охоплення цих платформ, але не вимірює поширеність використання агентів ШІ зокрема.
Практичні способи посилити безпеку агентів із низьким рівнем програмування
Командам слід перевіряти дозволи конекторів з огляду на завдання, доручене кожному агенту, і надавати доступ лише в мінімально необхідному обсязі. У централізованому реєстрі варто фіксувати відповідального за кожне впровадження та підключені сервіси, а для чутливих дій запровадити вимогу отримувати схвалення. Це дасть змогу командам безпеки виявляти незареєстрованих агентів і розслідувати випадки неналежного доступу.
Підхід Microsoft до управління даними наголошує на контрольованому доступі до бізнес-інформації. Навін Джанґір, головний архітектор Microsoft Digital, рекомендує організаціям «керувати нею та захищати її за допомогою належних обмежень доступу». Ці засоби контролю дають змогу авторизованим користувачам і системам ШІ використовувати її без зайвого розкриття у межах установлених дозволів. Поєднання політик для конекторів із чітко визначеною відповідальністю допоможе зробити такі обмеження частиною повсякденного процесу розроблення.
Ризики безпеки агентів ШІ з високим рівнем програмування та способи їх усунення
Коли команди використовують агентів ШІ для програмування, щоб створювати власні системи, згенеровані зміни можуть надходити швидше, ніж люди встигають їх перевірити. Тому безпека під час розроблення з високим рівнем програмування потребує контролю як за процесом розроблення, так і за середовищами, у яких агенти виконують завдання.
Унікальні виклики безпеки під час розроблення з високим рівнем програмування
Агенти для програмування можуть зіткнутися з опосередкованою ін’єкцією запитів, коли читають зовнішні репозиторії, що містять інструкції, додані зловмисниками. Якщо агент виконає ці інструкції, маючи доступ до інструментів розроблення, він може запустити небезпечні команди або розкрити облікові дані. Потенційні наслідки частково залежать від того, до яких файлів, інструментів і зовнішніх ресурсів середовище виконання дозволяє агенту отримати доступ.
Рекомендації NVIDIA щодо ізольованих середовищ стосуються ризику розкриття облікових даних у межах такого середовища виконання. У них зазначено, що «ізольовані середовища мають покладатися на явне передавання секретів», щоб обмежити доступ до облікових даних. Відповідно, агенти не повинні успадковувати повний набір облікових даних середовища, якщо для виконання їхніх завдань потрібен лише обмежений доступ. Командам слід надавати облікові дані для конкретного завдання, а не пов’язані з ним секрети тримати поза досяжністю агента.
Стратегії посилення захисту конвеєрів агентів, створених традиційним програмуванням
Середовища з обмеженим виконанням мають обмежувати доступ до файлів і вихідні з’єднання відповідно до завдання. Командам також слід застосовувати статичне тестування безпеки застосунків до згенерованого коду. Незалежні експерти мають перевіряти рішення щодо авторизації або бізнес-логіку, які можуть залишитися поза увагою автоматизованих перевірок. Ці рівні захисту враховують межі середовища виконання та слабкі місця кінцевого програмного забезпечення.
Amazon Web Services рекомендує у своїй системі контролю агентів для написання коду відокремлювати генерування коду від його оцінювання. Там зазначається, що «окрема сесія допомагає уникнути упередженості самопідтвердження». Однак дві сесії з тією самою моделлю можуть мати ті самі глибинні сліпі зони під час перевірки. Якщо це практично можливо, використання іншої моделі для перевірки та оцінювання людиною змін, важливих для безпеки, може забезпечити додаткову ретельність.
Формування стратегії безпеки, що охоплює обидва підходи
Для безпеки ШІ під час розробки агентів із мінімальним кодуванням і традиційним програмуванням потрібне спільне уявлення про діяльність усюди, де агенти обмінюються інформацією. Наприклад, робочий процес із мінімальним кодуванням може передавати дані спеціально створеному агенту, який потім викликає іншу бізнес-службу. Якщо перевіряти кожен компонент окремо, командам із безпеки може бракувати контексту, потрібного для розуміння всієї послідовності.
Фахівці Darktrace з безпеки ШІ стверджують, що організаціям потрібно перевіряти запити й сесії поряд із відповідями в усіх корпоративних інструментах генеративного ШІ та в обох підходах до розробки. Їхній погляд також охоплює програмне забезпечення як послугу та середовища Secure Access Service Edge (SASE). Завдяки такій видимості організації отримують контекст, що дає змогу «виявляти витончені розмовні атаки із застосуванням запитів і зловмисне зв’язування запитів».
Погляд Darktrace підтримує ширшу стратегію безпеки ШІ для розробки агентів із мінімальним кодуванням і традиційним програмуванням, адже видимість запитів, моніторинг сесій і контроль ідентичностей допомагають командам розуміти, як агенти взаємодіють у пов’язаних інструментах. Командам із безпеки слід перевіряти, як змінюються інструкції в пов’язаних сесіях і чи відповідають подальші дії початковим дозволам. Також слід враховувати чутливість інформації, що зберігається для розслідування.
Управління та моніторинг для довгострокового захисту агентів ШІ
За кожним агентом має бути закріплений відповідальний власник і чітко визначена сфера дозволеної діяльності — незалежно від способу його розробки. У межах управління також слід визначити, хто може затверджувати зміни цієї сфери та хто може призупинити роботу агента в разі його непередбачуваної поведінки.
Дослідження управління агентами свідчать, що для забезпечення підзвітності агенти мають отримувати повноваження, які можна автентифікувати та аудитувати. Такий підхід пов’язує особу, яка надає дозвіл, із завданнями, які може виконувати агент. Після цього організації можуть перевіряти відповідність дії наданому дозволу.
Командам слід вести журнали активності, що пов’язують делеговані дозволи з використанням інструментів і результатами. Під час періодичних перевірок слід переглядати ці дозволи з огляду на зміни можливостей, відкликати доступ, що залишився після завершення роботи, і підтверджувати, що відповідальна особа не змінилася. Завдяки таким перевіркам команди розробки та безпеки можуть підтримувати відповідність операційних засобів контролю затвердженому призначенню агента.
Як випереджати ризики безпеки агентів ШІ
Розробка з мінімальним кодуванням потребує ретельного налаштування дозволів платформи та управління конекторами, тоді як традиційна розробка з написанням коду вимагає пильної уваги до спеціально створених середовищ виконання та перевірки коду. Централізований моніторинг і послідовний підхід до підзвітності створюють спільну основу для нагляду за тим, як агенти отримують доступ до інформації та діють у пов’язаних бізнес-системах. У міру розширення можливостей розробникам слід переглядати засоби захисту відповідно до змін інструментів і обов’язків агентів, чітко визначаючи дозволені дії для кожного розгортання впродовж усього його життєвого циклу.












