Agent Governance: контроль і управління AI-агентами в production

Ідея за 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 = 3
• max_usd = 100 → агент зупиниться після досягнення ліміту, а не після втрати грошей.

Governance зупиняє інцидент на рівні виконання, а не покладається на те, що модель поводитиметься правильно.

Рівні контролю (governance layers)

Ці рівні працюють разом на кожному кроці агента.

Приклад 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:

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 для агентів — як відновлювати ланцюг подій і розбирати інциденти.