Агенти й MCP
Проєктування драбини дозволів та обмеження радіуса ураження автономних агентів
Покладання на системні промти на кшталт будь обережним не працює через імовірнісну природу моделей. Надійні агентні системи відокремлюють наміри моделі від права виконання за допомогою детермінованих рушіїв політик. Низькоризикові зворотні операції мають виконуватися автономно, тоді як незворотні дії вимагають схвалення людини.
10 вересня 2026 р. 5 хв читання
Куратор Oleksandr Kuzmenko, AI Product EngineerОновлено 10 вересня 2026 р.Джерела вказані в кожному матеріалі
За участі AI · перевірено редакторомЯк ми використовуємо AI
Вплив: Високий
Чому це важливо
Ви зможете запобігти витоку конфіденційних даних та випадковим деструктивним мутаціям у продакшені, перенісши авторизацію з промтів у шар прикладних політик.
TL;DR
- 01Впроваджуйте обмеження на запуск інструментів у коді бекенду, а не через системні промти для LLM.
- 02Автоматично дозволяйте створення чернеток та читання реплік, щоб людина не ставала вузьким місцем процесу.
- 03Маскуйте ключі доступу та персональні дані до їх потрапляння в контекстне вікно моделі.
Чому системні промти не замінюють контроль доступу. Інструкція в промті 'діяти обережно' не є безпековим механізмом. Імовірнісна генерація токенів рано чи пізно призведе до виклику деструктивного інструменту на кшталт delete_repository, якщо він доступний моделі. Будь-який намір агента повинен проходити через детермінований шар авторизації на рівні бекенду, де перевіряються політики доступу, ліміти бюджету та квоти викликів. ### Концепція драбини ризиків. Замість пласких списків дозволених функцій використовуйте ієрархію впливу: спостереження, аналіз, пропозиція, чернетка, виконання, публікація та знищення. Дії, що створюють локальні або зворотні артефакти (наприклад, відкриття чорнового PR чи запис у локальну гілку), мають відбуватися без запиту. Це відокремлює рутинну роботу агента від остаточного внесення змін. ### Захист від витоків через операції читання. Навіть статус 'тільки для читання' несе ризики, якщо агент має доступ до ключів або конфіденційних баз даних і може ретранслювати їх у зовнішні канали. Фільтрація та знеособлення полів мають виконуватися на етапі запиту до бази до того, як дані надійдуть у контекст LLM.
Спробуй за 2 хвилини
const policy = await policyStore.forUserAndAgent(req.userId, req.agentId); if (!policy.isAllowed(req)) { return { allow: false, reason: 'Denied by policy' }; } if (policy.requiresApproval(req)) { return { allow: false, approvalRequired: true }; } return { allow: true };typescript
✓ Коли використовувати
- Розробка автономних агентів для написання коду, інтегрованих з GitHub, базами даних або хмарою.
- Створення серверів Model Context Protocol, які надають мовним моделям доступ до внутрішніх систем.
✕ Коли НЕ варто
- Прості одноразові запити без виклику зовнішніх API чи системних інструментів.
- Повністю автономні скрипти, запущені в одноразових ізольованих контейнерах Docker.
Що зробити сьогодні
- Проведіть аудит інструментів агента та переведіть операції запису в режим створення чернеток за замовчуванням.
- Створіть проміжне програмне забезпечення для маскування ключів та конфіденційних даних перед подачею в пам'ять агента.
- Винесіть незворотні та деструктивні дії за зовнішній шлюз авторизації, що вимагає підтвердження користувача.
Джерела