Безпека AI-агентів: дозволи та rollback

Безпека AI-агентів стає критичною, коли система може перетворити невпевнену інтерпретацію на зовнішню дію. Головне запитання не «наскільки розумна модель?», а «що ця система може прочитати, змінити, надіслати, витратити, розкрити або видалити, коли помиляється?»

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

Будуйте threat model навколо наслідків

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

Ранжуйте наслідки. Читання публічної сторінки не рівнозначне надсиланню публічного повідомлення. Підготовка зміни не рівнозначна її застосуванню. Контроль має відповідати наслідкам.

Розділяйте інструменти читання й запису

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

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

За замовчуванням застосовуйте least privilege

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

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

Вважайте зовнішній вміст недовіреним

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

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

Підтверджуйте дії з наслідками перед виконанням

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

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

Тримайте secrets поза контекстом reasoning

Використовуйте затверджені secret stores або активні авторизовані сесії. Не додавайте паролі, tokens, recovery codes, cookies чи private keys до prompts, logs, вихідних файлів або згенерованих матеріалів.

Редагуйте чутливі дані в logs так, щоб журнали залишалися корисними, але не перетворювалися на друге сховище secrets. Фіксуйте ідентифікатор credentials або клас дозволу, а не секретне значення.

Забезпечте можливість аудиту дій

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

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

Використовуйте ізоляцію та staging

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

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

Проєктуйте rollback як частину дії

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

Деякі дії неможливо повністю скасувати. Надісланий лист, розкритий secret, публічне розголошення чи зовнішня покупка можуть потребувати containment, а не rollback. Позначайте такі дії відповідно й вимагайте ретельнішого погодження.

Підготуйте incident response

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

Практична матриця дозволів для безпеки AI-агентів

Для кожного інструмента задокументуйте:

• дозволені операції;
• заборонені операції;
• дозволені цілі;
• класифікацію даних;
• вимоги до підтвердження;
• вимоги до логування;
• спосіб rollback або containment;
• відповідального за дозвіл;
• строк дії або умову перегляду.

Починайте з read-only доступу. Потім додавайте підготовку змін. Обмежений запис дозволяйте лише тоді, коли evaluation, погодження, логування та відновлення мають переконливі механізми контролю.

Безпека AI-агентів — не один prompt або filter. Це спільний дизайн повноважень, меж доступу до даних, розділення інструментів, підтвердження, observability та відновлення.

Першоджерела

OWASP Gen AI Security Project: Excessive Agency

Пов’язані матеріали: AI-системи, технологічні основи та «Від AI-демо до надійного workflow».