KloudStax описала правила безпеки та контролю доступу для ШІ-агентів

Технічний директор компанії KloudStax Вінай Таккер в інтерв'ю Help Net Security описав підходи до налаштування ідентифікації, автентифікаційних даних, командних політик та мережевих обмежень для автономних ШІ-агентів.

Ідентичність та розмежування прав

Таккер виділяє два сценарії призначення ідентичності агентам:

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

Пряме використання облікових даних користувача Таккер вважає неприпустимим, оскільки це унеможливлює аудит дій у логах і надає агенту доступ до всіх ресурсів людини. Для інфраструктурних агентів запропоновано розділяти дозволи: агент може відкривати зміни та запускати план (plan), проте застосування змін (apply) має проходити окреме ревʼю та CI/CD-пайплайн.

Керування секретами та ризики проксі

Агентам заборонено надавати довгоживучі секрети. Якщо агент безпосередньо утримує короткоживучий токен, наявність refresh-токена в тому ж середовищі перетворює його на довгоживучий ризик. Токени рекомендовано прив'язувати до машини або контейнера, який їх запитував.

Проксі, що інжектує облікові дані під час виклику, захищає статичні API-ключі від потрапляння до агента. Водночас підхід несе ризики «confused deputy», якщо проксі автоматично авторизує будь-який запит агента. Також помилками є пересилання токена далі по ланцюжку (ризик витоку на кожному кроці), використання одного спільного секрету для всіх агентів та розміщення сховища секретів (vault) на тому самому хості, де працює агент.

Перші 10 пунктів командної політики для кодинг-агентів

Для агентів із доступом до термінала Таккер радить використовувати виключно білі списки (allowlists), які примусово застосовуються інфраструктурою виконання (harness), а не інструкціями для моделі:

1. Робота суворо всередині одного репозиторію в одноразовому середовищі без доступу до зовнішніх директорій.
2. Запуск лише затверджених інструментів: збірка, тести, лінтери, форматування, read-only git та редагування файлів у репозиторії. Решта команд потребує підтвердження.
3. Повна відсутність секретів у середовищі агента; взаємодія через брокер без права читання агентом.
4. Заборона відкриття файлів із секретами (.env, SSH-ключі, конфігурації хмарних провайдерів), навіть якщо вони є в робочому просторі.
5. Вимкнений мережевий доступ, окрім внутрішнього дзеркала пакетів і затверджених хостів проєкту.
6. Встановлення пакетів лише з внутрішнього репозиторію артефактів; додавання нової залежності потребує затвердження людиною.
7. Дозвіл на коміти лише у власну гілку та відкриття pull request (заборона push у захищені гілки, force-push та merge).
8. Обов'язкове підтвердження для операцій зі спільною інфраструктурою чи даними (apply, деплой, міграції, видалення).
9. Заборона ескалації привілеїв та зміни власної конфігурації, хуків чи політик.
10. Логування кожної команди з ідентифікатором агента й задачі, а також ліміти на витрати чи час роботи для примусового завершення сесії.

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

Мережеві обмеження та витік даних

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

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

Тестування безпеки та Red Team

Таккер закликає Red Team тестувати середовище навколо моделі, виходячи з припущення, що ін'єкція інструкцій (prompt injection) врешті-решт спрацює. Базові перевірки (спроби прочитати власні секрети, вийти за межі мережевого білого списку або відредагувати конфігурацію) мають бути автоматизовані й запускатися щоразу при додаванні нових інструментів чи конекторів.

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