Policy Boundaries в Архітектурі: Які дії дозволено агентам

Ідея за 30 секунд

Шар Policy Boundaries — це системні межі, які визначають, що агент може робити, а що ні.

Агент може пропонувати дії, але фінальне рішення завжди за системою: allow, deny або require_approval.

Коли потрібно: коли агент має доступ до інструментів, даних або операцій, які можуть змінювати стан, витрачати бюджет або створювати ризик.

LLM не має самостійно керувати side effects (змінами стану). Шар Policy Boundaries примусово контролює це на рівні архітектури.

Проблема

Без чітких Policy Boundaries агент починає діяти "занадто вільно".

Це створює типові ризики:

• агент виконує дію без потрібних прав;
• читає або передає чутливі дані;
• агент перевищує бюджет, квоти або кількість дозволених кроків;
• запускає незворотні операції без погодження;
• різні сервіси застосовують різні правила, і поведінка стає непередбачуваною.

У результаті зростають ризики інцидентів, складніше проходити аудит, а помилки коштують дорожче.

Рішення

Додати Policy Boundaries як окремий керований шар у системі: він перевіряє кожну ризикову дію перед виконанням.

Такий шар працює за принципом "заборонено за замовчуванням" (deny by default): дозволяється лише те, що явно входить в allowlist і відповідає контексту.

Аналогія: як пропускна система в офісному центрі.

Людина може хотіти зайти в серверну, але двері відкриються лише якщо є правильний рівень доступу.

Шар Policy Boundaries так само перевіряє доступ до дій і ресурсів перед виконанням.

Як працюють Policy Boundaries

Policy Boundaries — це керований шар між Agent Runtime і шарами виконання/даних, який вирішує: пропустити дію, заблокувати або відправити на погодження.

Цей цикл застосовується до кожної ризикової дії і дає передбачувану поведінку навіть при помилках моделі.

У коді це виглядає так

class PolicyBoundaryLayer:
    def __init__(self, policy_engine, approval_queue):
        self.policy_engine = policy_engine
        self.approval_queue = approval_queue

    def authorize(self, action, context):
        request = {
            "actor_role": context["role"],
            "tenant_id": context["tenant_id"],
            "action": action["name"],
            "resource": action.get("resource"),
            "risk_level": action.get("risk_level", "medium"),
        }

        decision = self.policy_engine.evaluate(request)
        mode = decision.get("mode")

        if mode == "allow":
            return {"ok": True, "mode": "allow", "scopes": decision.get("scopes", [])}

        if mode == "require_approval":
            ticket_id = self.approval_queue.create(request=request, reason=decision["reason_code"])
            return {"ok": False, "mode": "pending_approval", "ticket_id": ticket_id}

        # Fail-closed for deny and for unexpected/unavailable policy modes.
        return {
            "ok": False,
            "mode": "deny",
            "reason_code": decision.get("reason_code", "policy_unavailable_or_invalid"),
        }

Як це виглядає під час виконання

Запит: "Видали рахунок INV-991 і надішли дані клієнта у зовнішній CRM"

Step 1
Agent Runtime: формує action -> delete_invoice + export_customer_data
Runtime: передає дії в Policy Boundaries

Step 2
Policy Boundaries: Check -> роль support_agent, ризик high
Policy Engine: delete_invoice -> require_approval
Policy Engine: export_customer_data -> deny (reason_code: cross_system_export_blocked)

Step 3
Runtime: створює approval ticket для видалення
Runtime: блокує експорт і повертає безпечну відповідь з причиною

Policy Boundaries не лише "радять", а реально зупиняють небезпечні дії.

Коли підходить — і коли ні

Policy Boundaries потрібні там, де є реальні ризики доступу, змін стану або витрат. Для локального read-only прототипу це може бути зайвою складністю.

Підходить

Не підходить

У таких випадках інколи достатньо базової перевірки в коді:

if role != "admin":
    raise PermissionError("denied")

Типові проблеми та відмови

Більшість таких проблем вирішуються через єдину policy-точку контролю, fail-closed підхід і якісний аудит.

Як поєднується з іншими патернами

Policy Boundaries не замінюють Agent Runtime чи Tool Execution Layer. Це системний контроль доступу поверх них.

• Agent Runtime — Runtime керує кроками, а Policy Boundaries перевіряють, які дії дозволені на цих кроках.
• Tool Execution Layer — execution layer виконує дію, а Policy Boundaries вирішують, чи можна її запускати.
• Human-in-the-Loop Architecture — ризикові дії можна переводити в require_approval.
• Multi-Tenant — Policy Boundaries примусово відділяють доступи між tenant.

Інакше кажучи:

• Agent Runtime визначає коли агент робить крок
• Policy Boundaries визначають які дії в цьому кроці взагалі дозволені

Чим це відрізняється від Guarded-Policy Agent

Guarded-Policy Agent робить поведінку агента обережнішою.

Policy Boundaries роблять виконання дій контрольованим навіть якщо агент помиляється.

Коротко

FAQ

Q: Якщо є Guarded-Policy Agent, Policy Boundaries ще потрібні?
A: Так. Guarded-Policy Agent покращує поведінку, але саме Policy Boundaries дають примусове виконання правил на рівні системи.

Q: Де краще зберігати policy rules (правила політик)?
A: Найчастіше в окремому policy engine або policy-as-code шарі з версіями і тестами.

Q: Що робити, якщо policy engine недоступний?
A: Для ризикових write-операцій застосовують fail-closed: заборонити виконання, доки перевірка недоступна.

Q: Чи можуть Policy Boundaries залежати від середовища (dev, staging, prod)?
A: Так. Часто ті самі дії мають різні policy rules залежно від середовища, рівня ризику і типу даних.

Що далі

Policy Boundaries задають правила гри. Далі корисно подивитися, де саме ці правила виконуються в системі:

• Tool Execution Layer — як policy застосовується під час реальних tool calls.
• Human-in-the-Loop Architecture — як оформити approval для критичних дій.
• Agent Runtime — як runtime зупиняє або продовжує цикл за правилами.
• Production Stack — як policy стає частиною операційної дисципліни.