Суть патерна
Guarded-Policy Agent - це патерн, у якому перед виконанням кожної дії застосовується policy-gate: дозволити, заборонити, переписати або ескалювати згідно з формалізованими правилами.
Коли потрібен: коли дії агента мають проходити формальну перевірку правил перед виконанням.
Ідея проста: агент може пропонувати будь-що, але виконуються тільки ті кроки, що проходять перевірку політик.
Захист політик зазвичай перевіряє:
- дозволені інструменти та параметри
- межі доступу до даних
budget/timeобмеження- рівень ризику дії
Проблема
Уяви банківський сценарій: потрібно переказати 100$, але в полі помилково вводять 10,000$.
Якщо система без перевірок просто каже "виконуємо", дія піде в прод.
Навіть коли:
- у клієнта немає такого балансу
- сума перевищує ліміт ролі
- рахунок зовнішній і потребує додаткових перевірок
Без технічного шлюзу політик агент може виконати небезпечну дію навіть тоді, коли вона очевидно не повинна пройти.
У цьому й проблема: без обмежень будь-яка дія може бути виконана, навіть якщо вона:
- небезпечна
- надто дорога
- порушує правила доступу
Рішення
Guarded-Policy Agent вводить обов'язкові перевірки перед кожною дією.
Аналогія: це як турнікет з пропускною системою. Навіть якщо людина хоче пройти, спочатку перевіряються доступи й правила. Без дозволу система просто не пропускає дію далі.
Ключовий принцип: Модель може запропонувати будь-який крок, але виконуються тільки кроки, які пройшли шлюз політик.
Кожна дія проходить:
- перевірку дозволів
- перевірку бюджету/лімітів
- перевірку доступу до даних
- оцінку ризику
Після цього policy-engine повертає рішення:
- дозволити (
allow) - виконати - переписати (
rewrite) - замінити на безпечний варіант - заборонити (
deny) - заблокувати - ескалювати (
escalate) - передати людині
Це захищає від сценаріїв, де агент може:
- записати замість читання
- витягнути чутливі дані
- запустити дорогий запит
- зробити руйнівну операцію
Працює добре, якщо:
- агент не має прямого доступу до tools
- виконання йде лише через
policy-engine - кожна дія обов'язково проходить
дозволити/заборонити/переписати/ескалювати
Надійність агента - це не лише "правильні наміри", а дії, які він технічно не може виконати поза правилами.
Як працює
Policy-gate не виконує дію сам. Він вирішує, чи може вона бути виконана і в якій формі.
Опис повного флоу: Propose → Check Policy → Enforce → Execute/Block
Пропозиція дії
Агент формує намір: який tool, з якими аргументами і навіщо цей крок.
Перевірка політики
Політика перевіряє намір: allowlist/blocklist, scope доступу, ліміти бюджету, runtime state (quota, spend), чутливість даних.
Застосування рішення
Policy-engine повертає enforcement-рішення: дозволити, заборонити, переписати або ескалювати.
Виконати/Заблокувати
Система або виконує дію, або зупиняє flow з прозорим stop reason.
У коді це виглядає так
action = agent.next_action(context)
decision = policy_engine.evaluate(
action=action,
user_role=user_role,
budget_state=budget_state,
)
if decision.type == "allow":
result = execute(action)
elif decision.type == "rewrite":
context.append(decision.reason)
return agent.next_action(context) # propose again через той самий gate
elif decision.type == "escalate":
result = human_approval(action)
else:
result = stop_with_reason(decision.reason)
return result
Ключовий принцип: Agent intent і виконання - це різні шари. Policy стоїть між intent і виконанням (execution).
Модель не має прямого доступу до виконання - лише через policy-gated шар виконання (execution layer).
Як це виглядає під час виконання
Goal: "Експортуй усіх клієнтів у CSV і надішли на зовнішню пошту"
Agent action:
- tool: export_customers
- params: include_pii=true
- destination: external_email
Policy check:
- rule: PII export to external channels = deny
- decision: заблокувати (block)
- reason: policy.pii_exfiltration_guard
Result:
- дія не виконана
- повернуто контрольовану відмову
Повний приклад Guarded-Policy агента
Коли підходить — і коли ні
Підходить
| Ситуація | Чому Guarded-Policy підходить | |
|---|---|---|
| ✅ | Є ризикові tools/дані і доступ до чутливих операцій | Шлюз політик блокує небезпечні дії до їх виконання. |
| ✅ | Потрібні compliance/security межі | Правила enforce'яться технічно, а не лише через prompt-інструкції. |
| ✅ | Важлива пояснюваність рішень | Можна прозоро показати allow/deny і причину рішення. |
| ✅ | Ціна помилки висока: гроші, безпека, юридичні ризики | Превентивний контроль знижує ймовірність дорогих помилок. |
Не підходить
| Ситуація | Чому Guarded-Policy не підходить | |
|---|---|---|
| ❌ | Read-only sandbox без ризикових дій | Окремий шар політик майже не дає додаткової користі. |
| ❌ | Неформалізовані правила | Якщо правила не можна формально перевірити, enforcement не буде надійним. |
| ❌ | Немає ресурсу підтримки набору політик | Без підтримки версій і тестів шар політик швидко деградує. |
Бо шар політик додає інженерну складність: правила, тести правил і постійне оновлення під бізнес-процеси.
Чим відрізняється від Supervisor Agent
| Guarded-Policy | Supervisor Agent | |
|---|---|---|
| Головна роль | Автоматично застосовує жорсткі policy-правила до кожної дії | Контролює рішення агента ширше: ризики, якість, потребу в ескалації |
| Коли втручається | На кожному кроці перед виконанням | На ключових або сумнівних кроках процесу |
| Тип рішень | allow / deny / rewrite / escalate | approve / revise / block / escalate |
| Коли обирати | Коли потрібен технічний "шлагбаум", який не можна обійти | Коли потрібен нагляд над процесом і контроль складних рішень |
Guarded-Policy - це технічний бар'єр "за правилами".
Supervisor Agent - це наглядовий контроль "по ситуації".
Коли використовувати Guarded-Policy (vs інші патерни)
Використовуйте Guarded-Policy, коли потрібно зупиняти ризикові дії до виконання за чіткими policy-правилами.
Короткий тест:
- якщо потрібно "allow/deny перевірка перед дією" -> Guarded-Policy
- якщо потрібно "відновлюватися після вже наявної помилки" -> Fallback-Recovery Agent
Порівняння з іншими патернами та приклади
Швидка шпаргалка:
| Якщо задача виглядає так... | Використовуйте |
|---|---|
| Потрібна коротка перевірка перед фінальною відповіддю | Reflection Agent |
| Потрібна глибока критика за критеріями і переписування відповіді | Self-Critique Agent |
| Потрібно відновлювати процес після timeout, exception або падіння інструмента | Fallback-Recovery Agent |
| Потрібні жорсткі policy-перевірки перед ризиковою дією | Guarded-Policy Agent |
Приклади:
Reflection: "Перед фінальною відповіддю швидко перевір логіку, повноту і явні помилки".
Self-Critique: "Оціни відповідь за чеклістом (точність, повнота, ризики), потім перепиши".
Fallback-Recovery: "Якщо API не відповідає, зроби retry -> fallback-джерело -> ескалація".
Guarded-Policy: "Перед відправкою даних назовні перевір policy: чи дозволено це робити".
Як комбінувати з іншими патернами
- Guarded-Policy + ReAct: кожну дію в циклі агент спочатку пропускає через policy-check, а вже потім виконує.
- Guarded-Policy + Supervisor: Supervisor визначає, коли потрібна ескалація, а policy-engine автоматично застосовує жорсткі правила.
- Guarded-Policy + Fallback-Recovery: якщо дію заборонено або крок упав, агент переходить на дозволений і безпечний fallback.
Коротко
Guarded-Policy Agent:
- Перевіряє кожну дію до виконання
- Примусово застосовує правила політик
- Блокує або ескалує небезпечні кроки
- Знижує ризик збоїв і порушень комплаєнсу
Переваги та Недоліки
Переваги
блокує небезпечні дії до виконання
краще захищає дані та доступи
правила легко перевіряти й аудіювати
простіше дотримуватись вимог безпеки
Недоліки
політики треба постійно підтримувати
занадто жорсткі правила гальмують роботу
помилки в правилах можуть блокувати зайве
FAQ
Q: Чи можна замінити перевірку політик лише prompt-інструкцією?
A: Ні. Prompt працює на рівні наміру, але не контролює виконання. Політика має застосовуватись у runtime-шарі.
Q: Що краще: allowlist чи blocklist?
A: Для систем із високим ризиком безпечніше починати з allowlist: дозволені тільки явно описані дії.
Q: Що робити, коли правило надто жорстке і блокує корисну дію?
A: Додавати керовані винятки: scope, рольові умови або шлях із підтвердженням людиною замість повного deny.
Що далі
Guarded-Policy підхід захищає агента від небезпечних дій до виконання.
А що робити, коли агенту потрібно безпечне виконання коду в ізольованому середовищі?