Policy as Code for Agents в 2026: когда правила должны жить в коде, а не только в prompt

Короткая версия

Policy as code в 2026 особенно нужна для:

1. Tool permissions
2. Approval requirements
3. Routing restrictions
4. Output/schema validation
5. Tenant and data access boundaries

Что особенно важно

• policy должна жить рядом с runtime checks;
• high-risk rules должны быть deny-by-default;
• policy changes должны быть versioned и observable;
• prompt policy и enforced policy должны быть согласованы, но не подменять друг друга.

Где лучше задавать правило `refund > $100 требует approval`: в prompt или в code?

1. Prompt policy и runtime policy решают разные задачи

Полезно развести:

Prompt policy

• направляет reasoning;
• объясняет intent системы;
• помогает модели выбирать корректное поведение.

Runtime policy

• блокирует нежелательные действия;
• проверяет контракты;
• требует approval;
• ограничивает доступ;
• пишет audit trail.

Они должны дополнять друг друга, но authoritative layer для risky behavior почти всегда должен быть runtime.

2. Что особенно хорошо ложится в policy as code

Tool permissions

Можно ли вызывать конкретный tool в этом route/tenant/run.

Approval gates

Какие действия требуют human token.

Output handling

Можно ли принять этот JSON, отправить email, отдать ответ пользователю.

Data access

Какие документы, tenants и секреты доступны агенту.

Routing restrictions

Какие модели, lanes и fallbacks допустимы.

3. Policy должна быть проверяемой и наблюдаемой

Хороший policy layer отвечает на вопросы:

• какая версия правила сейчас активна;
• какой rule triggered;
• почему action был заблокирован или разрешён;
• как policy менялась со временем.

Без этого policy-as-code быстро превращается в скрытый набор if/else без governance.

4. Deny-by-default особенно полезен для risky classes

Для dangerous actions полезно строить политику так:

• по умолчанию запрещено;
• разрешение выдаётся явно;
• exception paths журналируются;
• approval подтверждает override.

Так команда лучше контролирует blast radius и change risk.

5. Policy changes сами по себе являются production changes

Даже без деплоя новой модели policy change может:

• расширить tool access;
• снять approval;
• изменить routing;
• повысить exposure к данным;
• увеличить false refusals.

Поэтому policy changes полезно сопровождать:

• versioning;
• staged rollout;
• audit sample;
• rollback path.

6. Что особенно часто ломают команды

Prompt-only governance

Правила существуют только в prose.

Hidden policy rules in business code

Никто не понимает, где именно enforced logic живёт.

No versioning

После incident непонятно, какое правило уже действовало.

No explainability

Оператор не видит, почему action был blocked.

Policy drift from prompt

Модельу говорится одно, а runtime разрешает другое.

7. Какие метрики полезны

Минимальный policy dashboard обычно включает:

• policy block rate;
• approval-trigger rate;
• false block / false allow audits;
• policy version rollout metrics;
• incidents correlated with policy changes;
• percent of critical actions covered by enforced rules.

Пример policy rule

rules:
  - id: refund_requires_approval
    when:
      action: issue_refund
      amount_gt: 100
    decision: require_approval

  - id: external_email_blocked_for_demo_tenant
    when:
      action: send_external_email
      tenant: demo
    decision: deny

Простой enforcement hook

def enforce_policy(action, context):
    if action.name == "issue_refund" and action.amount > 100 and not context.approval_token:
        return "deny"
    if action.name == "send_external_email" and context.tenant == "demo":
        return "deny"
    return "allow"

Практический совет: policy as code полезнее всего там, где она ограничивает не модель как таковую, а реальные последствия её решений. Именно этот слой превращает agent stack из "умного демо" в управляемую production-систему.