Ідея за 30 секунд
Agent governance — це шар контролю поверх runtime, який перевіряє кожен крок агента: доступ до інструментів, ліміти, бюджети і policy-рішення перед виконанням дій.
Коли це потрібно: коли агент має доступ до інструментів, API або виконує реальні дії в production.
Проблема
Без governance агент у production часто виглядає "майже нормальним", поки не стається збій. Він може багато разів викликати інструменти, витрачати бюджет без прогресу і виконувати дії, які ніхто явно не дозволяв.
Найгірше, що це видно не одразу: зовні run "йде", а всередині вже ростуть ризики, витрати і шум у логах. Без governance агент — це неконтрольований цикл з доступом до інструментів.
Аналогія: це як автопілот у машині без обмеження швидкості, гальм і журналу подій. Поки дорога пряма, все ніби добре. Коли щось іде не так, зупинити і розібратися набагато складніше.
Саме для цього потрібен governance: щоб система мала межі до інциденту, а не після нього.
Рішення
Рішення — додати в runtime окремий policy layer, який перед кожною дією приймає технічне рішення.
Policy layer приймає одне з рішень: allow, deny або approval_required.
Це окремий рівень системи, а не частина промпта чи логіки моделі.
Як і RBAC, ці перевірки виконуються перед кожною дією агента.
Governance — це те, що стоїть між агентом і реальними діями. Іншими словами, це control plane для AI-агентів.
👉 Governance не змушує агента поводитись правильно — він обмежує, що агент взагалі може зробити.
Реалізується як middleware / policy layer (наприклад, у LangGraph або кастомному tool gateway). У цій статті policy layer (tool gateway) — це компонент, який перевіряє і контролює всі виклики інструментів.
Governance ≠ Safety
Це два різні рівні контролю:
- Safety: чи правильне рішення пропонує агент.
- Governance: чи дозволено агенту цю дію виконати в runtime.
Якщо safety помилилась, governance все одно обмежує збиток на рівні runtime.
Приклад
Агент підтримки без governance може через галюцинацію викликати refund API десятки разів.
З governance:
max_tool_calls = 3max_usd = 100→ агент зупиниться після досягнення ліміту, а не після втрати грошей.
Governance зупиняє інцидент на рівні виконання, а не покладається на те, що модель поводитиметься правильно.
Рівні контролю (governance layers)
Ці рівні працюють разом на кожному кроці агента.
| Рівень | Що контролює | Ключові механіки | Навіщо |
|---|---|---|---|
| Access control | Доступ до дій та інструментів | RBAC allowlist / denylist | Перевіряється перед кожним tool call і блокує недозволені дії |
| Execution control | Хід виконання run | max_steps rate limiting ліміти на tool calls | Зупиняє зациклення і спам інструментами |
| Cost control | Витрати | max_tokens max_tool_calls max_usd | Обмежує бюджет і runaway-витрати |
| Human control | Втручання людини | human approval kill switch | Дозволяє підтвердити або аварійно зупинити дію |
| Observability | Видимість подій | audit logs traces метрики alerts (Slack / PagerDuty) | Дозволяє швидко виявляти і розбирати інциденти |
| Lifecycle control | Оновлення агента | versioning rollback | Дозволяє безпечно релізити зміни і відкотити версію |
Приклад alert:
Slack alert: 🛑 Agent Support-Bot hit max_usd limit ($100). Run stopped at step 12.
У production це зазвичай виглядає як dashboard з метриками: runs, tool calls, cost, errors.
Як це виглядає в архітектурі
Agent governance вбудовується між runtime агента і зовнішнім світом:
Жоден tool call не виконується без проходження через policy layer.
Policy layer (tool gateway) виступає як gateway / middleware між runtime і tools.
Кожен виклик інструмента проходить:
- Policy layer → перевірка доступу і лімітів
- Execution → виконання тільки якщо allow
- Logs → запис у audit / trace
Мінімальний stack governance
- allowlist (default deny) — обмежує доступ до інструментів
- max_steps — зупиняє зациклення
- бюджети — обмежують витрати
- retry policy — запобігає retry-хаосу
- audit logs — дозволяють розібрати інциденти
- stop reasons — пояснюють, чому агент зупинився
- kill switch — дозволяє аварійно зупинити агента під час інциденту
Це мінімум, без якого агент не є production-системою.
Приклад
Агент викликає tool:
- перевіряється allowlist
- перевіряється RBAC
- перевіряється budget
- перевіряється approval
→ тільки після цього виконується дія.
Мінімальний policy flow:
if not policy.allow(tool, args):
return deny("tool_not_allowed")
if not limits.steps_ok():
return stop("max_steps_exceeded")
if not budget.ok():
return stop("budget_exceeded")
result = tool.execute(args)
audit.log(tool, args, result)
return result
Типові помилки
- покладатися тільки на prompt замість runtime-контролю
- відсутність централізованого policy layer
- відсутність default-deny allowlist
- відсутність бюджетів і лімітів
- retry-логіка розмазана по різних шарах
- відсутні audit logs
- немає способу зупинити агента
У результаті система виглядає контрольованою, але насправді такою не є.
Самоперевірка
Швидка перевірка перед запуском у production:
Прогрес: 0/8
⚠ Бракує базового governance-контролю
Перед production потрібні мінімум: контроль доступу, ліміти, audit logs і аварійна зупинка.
FAQ
Q: Чому governance не можна замінити одним системним prompt?
A: Prompt описує бажану поведінку. Governance примусово обмежує реальні дії агента в runtime.
Q: Який мінімум governance потрібен перед production?
A: Мінімум: default-deny allowlist, ліміти (max_steps, бюджети), stop reason, audit logs і kill switch. Без цього агент лишається неконтрольованим під навантаженням.
Q: Що впроваджувати першим: approval чи budgets?
A: Спочатку став runtime-ліміти й бюджети, щоб одразу обмежити базовий ризик на кожному run. Потім додавай approval для ризикових і незворотних дій (write-операції, фінансові зміни, видалення даних).
Q: Чи достатньо kill switch для безпеки?
A: Ні. Kill switch потрібен як аварійне гальмо, але він не заміняє постійний контроль доступу, бюджети, rate limits і аудит дій.
Q: Як технічно реалізується kill switch?
A: Зазвичай це простий глобальний прапорець (наприклад, у Redis), який policy layer перевіряє перед кожним кроком і зупиняє виконання.
Пов'язані сторінки
Далі за темою:
- Контроль доступу (RBAC) — як обмежити, що агенту дозволено робити.
- Контроль бюджетів — як стримувати витрати токенів, tool calls і $.
- Rate limiting для агентів — як захиститися від спаму інструментами і пікових навантажень.
- Human approval — де потрібне підтвердження людини перед критичними діями.
- Audit logs для агентів — як відновлювати ланцюг подій і розбирати інциденти.