Политики утверждения

Политики утверждения — это правила уровня рабочего пространства, которые управляют тем, когда работа агента требует ручного рассмотрения перед применением. Они связывают типы действий (например pull requests или патчи) с требованиями к утверждению, с опциональной фильтрацией по путям для защиты чувствительных файлов и конфигурации.

Почему вам нужны политики утверждения

По умолчанию агенты, назначенные на задачи, работают автономно — они создают pull requests, пушат изменения и открывают новые issues без ожидания разрешения. Политики утверждения позволяют вам требовать ручную проверку для высокорискованных операций:

• Защита CI/CD конфигурации — требуют утверждение перед любым изменением агентом .github/ workflows
• Блокировка изменений секретов — запрещают все изменения .env, secrets/ или других чувствительных путей
• Production шлюзирование — требуют подпись администратора перед изменением production конфигурации
• Контроль биллинга — проверка любых изменений файлов, связанных с биллингом

Как работают политики

Каждая политика определяет:

• Типы действий — какие операции она охватывает (например pull_request, patch)
• Path globs — опциональные шаблоны файлов; пустые globs соответствуют всем файлам
• Эффект — либо require_approval (поставить в очередь на проверку), либо deny (отклонить сразу)
• Роль одобрителя — кто имеет полномочия одобрить (по умолчанию: admin)
• Приоритет — когда совпадают несколько политик, побеждает политика с наивысшим приоритетом; deny побеждает require_approval

Когда агент пытается выполнить действие, механизм политик оценивает все включённые политики вашего рабочего пространства. Совпадающие политики определяют, разрешено ли действие, поставлено ли на проверку или отклонено.

Логика совпадения

Политика совпадает, когда:

1. Её action_types включает выполняемое действие, и
2. Хотя бы один шаблон path_globs соответствует изменённому файлу (или path globs пуст)

Если политики не совпадают, действие разрешено по умолчанию. Если совпадают несколько политик, побеждает политика с наивысшим приоритетом. При равном приоритете deny побеждает require_approval.

Создание и управление политиками

Политики управляются в Параметры → Политики утверждения рабочего пространства (только администраторы). Вы можете:

• Создать новую политику — определить типы действий, шаблоны путей, эффект и роль одобрителя
• Включать или отключать политики — переключение без удаления
• Установить приоритет — управление тем, какая политика побеждает при применении нескольких правил
• Использовать шаблоны — AACWorkflow предоставляет опциональные стартовые политики для типичных случаев

Шаблоны по умолчанию

Когда вы включаете enterprise функции, два шаблона политик доступны как начальные точки:

• Защита CI/CD конфигурации: Требует утверждения для изменений .github/**
• Защита биллинга/секретов: Блокирует все изменения billing/**, secrets/** и .env* файлов

Workflow утверждения

Когда политика требует утверждения:

1. Действие агента захватывается и безопасно хранится
2. Задача появляется в очереди Inbox → Approvals рабочего пространства
3. Авторизованный рецензент (участник с ролью одобрителя) видит сводку действия и предпросмотр изменений
4. Рецензент может одобрить (действие продолжается) или отклонить (агент получает уведомление, изменения не применяются)
5. Утверждения истекают через 7 дней; истекшие запросы отмечаются как expired и должны быть переотправлены

Одобрение действия

Чтобы одобрить ожидающее действие:

1. Откройте Inbox → Approvals
2. Кликните на ожидающее действие, чтобы увидеть полный diff и контекст
3. Кликните Approve для продолжения или Reject для отклонения
4. Если одобрено, очереженный payload агента применяется немедленно
5. Если отклонено, агент получает уведомление и может изменить подход

Эффекты политик

require_approval

Когда эффект политики require_approval:

• Действие агента ставится в очередь и не применяется
• Участники рабочего пространства с ролью одобрителя получают запрос на утверждение
• Действие продолжается только после явного одобрения
• Полезно для защиты важной конфигурации или высокостакартных изменений

deny

Когда эффект политики deny:

• Действие агента отклоняется сразу
• Запрос на утверждение не создаётся
• Агент уведомляется с причиной отклонения
• Полезно для абсолютных чёрных списков (например секреты или учётные данные)

Best practices

• Начните консервативно — включите шаблоны для CI/CD и секретов, затем уточняйте по мере необходимости
• Используйте path globs осторожно — **/billing/** слишком широко; предпочтите billing/pricing.json или подобное
• Установите чёткие приоритеты — избегайте путаницы, когда могут применяться несколько политик
• Регулярно проверяйте отклонения — если агенты часто попадают в политики deny, рассмотрите необходимость корректировки правила
• Сообщите команде — убедитесь, что лидеры squads знают, какие пути требуют утверждения

Дальнейшие шаги

• Enterprise governance features — элементы управления безопасностью на уровне рабочего пространства
• Safe outputs layer — как политики утверждения интегрируются с обработкой выходов агента
• Members and roles — понимание требований к роли одобрителя