Агенти ШІ потребують нової моделі дозволів

Дозвіл має описувати конкретну дію

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

Найменші привілеї потребують технічної підтримки

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

Ризикові кроки зупиняють перед виконанням

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

Аудит має допомагати відновити перебіг подій

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